Ace104 Lecture 1

1. Ace104Lecture 1 Introduction Distributed Architectures SOA Concepts

2. “Traditional” programming models

3. Distributed programming models:Classic Web-based Easy to deploy but slow, not great user experience Lacks full support of apps server -- no transactions, rpc, etc. database html browser WebServer http • Many programming models • JSP • ASP • Servlets • PHP • CGI (python, perl, C) • Cold Fusion Dynamically Generated html html plus optionally JavaScript to jazz up html

4. Distributed programming modelsTypical Web-based Better user experience. Heavier, less portable, requires socket programming to stream to server. html database WebServer http applet socket Dynamically Generated html html + applet

5. ports App1 sockets Application client App2 App3 Direct Connections • Direct socket and rpc-style App1 Application client Remote Procedures NDS App2 App3 Examples: Java’s rmi, CORBA, DCOM

6. Application Servers

7. RPC-style Web service

8. General role of XML • Most modern languages have method of representing structured data. • Typical flow of events in application Read data (file, db, socket) Marshal objects Manipulate in program Unmarshal (file, db, socket) • Many language-specific technologies to reduce these steps: RMI, object • serialization in any language, CORBA (actually somewhat language neutral), • MPI, etc. • XML provides a very appealing alternative that hits the sweet spot for • many applications

9. Simple XML-based architecture web browser “hand-rolled” XML WebServer http File system python CGI “hand-rolled” XML XML

10. Motivating Example1 Mortgage Calculator

11. Example: mortgage calculator • Start very simple to motivate role of XML • All we need is a web server that supports a server-side programming model • We will build up this example to include first web service and then SOA concepts (as we gain experience)

12. Functional requirements • Design a simple application which does the following: • Accepts user input • Loan amount • Loan term • Interest rate • Extras (assessments + taxes) • Returns per-month table of • total payment • interest • principal • some other fun stuff

13. Design requirements • Must be • Clean simple interface (easy) • Remotely accessible with security • Portable to different machine architectures • Not require heavyweight or sophisticated installation on the part of the user • Sufficiently fast not to be embarrassing given 10 hits/minute maximum usage

14. Some possible architectures • Things I tried • what are (dis) advantages of each? • Web server • Server-side scripting with pure (dynamic) html • Server-side scripting with html+javascript • Server-side scripting with html+applet • Direct connection • Raw sockets • Distributed objects

15. Initial choice • Front-end: html form • Back end: python cgi • Python generates web page dynamically after making calculations • No use of higher-level web generation libraries at this point • What are advantages/disadvantages of this architecture? • Run application: • http://people.cs.uchicago.edu/~asiegel/courses/ace104/lesson1/examples/mortgage/

18. Disadvantages • Two obvious disadvantages are: • Formatted web content in print statements low-level, ugly error prone • Data is not decoupled from formatting. What if we want to switch to an application client? What if we want to allow further processing by the client? • Several strategies can help with both of these (higher-level htmlgen libraries, server-side scripting model, beans, etc.) and XML • We will look at how XML fits in

19. Key Questions • What does browser do with XML? • Can it display? • Does it even understand XML? • If not, what good is this? • Do we have to hand roll our programming language objects from XML?

20. Some answers • Regarding first point, try this with your web browser • Note that XML is displayed/formatted nicely, but not nearly to the same level of utility as the html table • To transform to html, we must associate a separate .xsl file (e.g.) with the XML file. We will study XSL soon. • Regarding XML-language conversion, we will study language binding for various high-level ways of doing this. For now, we will hand-roll ourselves!

21. Lottery application

22. Functional requirements • Given a list of student members of a dormitory, perform an ordered randomized sort of the students to determine a room draft order.

23. Functional requirements, cont. • Students are defined by • Last name • First name • Seniority • Quarters in the House • Quarters in the College • The sort keys are • Quarters in House • Quarters in College • Random

24. Software requirements • Secure login • House name • Password • Remotely accessible to single small company • Several hits per hour maximum • All Windows Users • What I tried • Excel embedded in IE6 • Web-based with java servlets, XML, XSLT

25. Sketch of XML/Servlet solution filesystem XML Login Info login Web Client Web Server XML XML Student Data XSLT lottery

26. Exercise 1

27. An exercise1 solution Travel Service Web Client Internal Rules Engine ? html xml Security manager xml http html Web Client http Complexity of marshaling/unmarshaling XML How to represent state Ease of integration -- no proprietary issues Ability to use Schema for validation

28. SOA Concepts A Very Brief Introduction

29. Standards Organizations

30. This is all a work in progress • Reading too much gives the impression that these are turnkey solutions. • In fact, remember that MANY of these standards are very immature and are at various stages of implementation by different vendors. • They also tend to change quickly in the early years. Be very careful when applying to real problems! • Question: are open standards worthwhile? If so, who do they benefit and how?

31. SOA Definitions • What is a SOA? • OASIS: “paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.”

32. SOA definitions, cont. • Erl: “Contemporary SOA represents an open, agile, extensible, federated, composable architecture comprised of autonomous, QoS-capable, vendor diverse, interoperable, discoverable, and potentially reusable services, implemented as Web services. • SOA can establish an abstraction of business logic and technology, resulting in a loose coupling between these domains. • SOA is an evolution of past platforms, preserving successful characteristics of traditional architectures, and bringing with it distinct principles that foster service-orientation in support of a service-oriented enterprise. • SOA is ideally standardized throughout an enterprise, but chieving this state requires a planned transition and the support of a still evolving technology set.”

33. SOA Definitions, cont. • OMG: “Service Oriented Architecture is an architectural style for a community of providers and consumers of services to achieve mutual value, that: • Allows participants in the communities to work together with minimal co-dependence or technology dependence • Specifies the contracts to which organizations, people and technologies must adhere in order to participate in the community • Provides for business value and business processes to be realized by the community • Allows for a variety of technologies to be used to facilitate interactions within the community”

34. SOA definitions, cont. W3C: “A form of distributed systems architecture that is typically characterized by the following properties: • Logical view: The service is an abstracted, logical view of actual programs, databases, business processes, etc., defined in terms of what it does, typically carrying out a business-level operation. • Message orientation: The service is formally defined in terms of the messages exchanged between provider agents and requester agents, and not the properties of the agents themselves. The internal structure of an agent, including features such as its implementation language, process structure and even database structure, are deliberately abstracted away in the SOA: using the SOA discipline one does not and should not need to know how an agent implementing a service is constructed. A key benefit of this concerns so-called legacy systems. By avoiding any knowledge of the internal structure of an agent, one can incorporate any software component or application that can be "wrapped" in message handling code that allows it to adhere to the formal service definition. • Description orientation: A service is described by machine-processable meta data. The description supports the public nature of the SOA: only those details that are exposed to the public and important for the use of the service should be included in the description. The semantics of a service should be documented, either directly or indirectly, by its description. • Granularity: Services tend to use a small number of operations with relatively large and complex messages. Network orientation: Services tend to be oriented toward use over a network, though this is not an absolute requirement. Platform neutral: Messages are sent in a platform-neutral, standardized format delivered through the interfaces. XML is the most obvious format that meets this constraint. “

35. SOA definition, cont. Open Group: “An architectural style that supports service orientation … Service orientation • A way of a way of thinking in terms of services and service based development and the outcomes that services bring Service • A logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data, consolidate drilling reports), is self-contained and maybe composed of other Services. It is a black box to consumers of the Service Architectural Style • The combination of distinctive features in which Enterprise Architecture is done, or expressed The SOA Architectural styleﾕs distinctive features: Based on the design of the services comprising an enterprise’s (or inter-enterprise) business processes. Services mirror real-world business activity Service representation utilizes business descriptions. Service representation requires providing its context (including business process, goal, rule, policy, service interface and service component) and service orchestration to implement service Has unique requirements on infrastructure. Implementations are recommended to use open standards, realize interoperability and location transparency. Implementations are environment specific, they are constrained or enabled by context and must be described within their context. Requires strong governance of service representation and implementation Requires a Litmus Test, which determined a good services”

36. SOA: the basics What it is. What it is not.

37. Real SOA • Changed mindset: service-oriented context for business logic. • Changed automation logic: service-oriented applications. • Changed infrastructure: service-oriented technologies. • A top-down organization transformation requiring real commitment.

38. SOA Characteristics • Loosely coupled: minimizes dependencies between services. • Contractual: adhere to agreement on service descriptions. • Autonomous: control the business logic they encapsulate. • Abstract: hide the business logic from the service consumers.

39. SOA Characteristics • Reusable: divide business logic into reusable services. • Composable: facilitate the assembly of composite services. • Stateless: minimize retained information specific to an activity. • Discoverable: self-described so that they can be found and assessed.

40. Potential Benefits • Based on open standards. • Supports vendor diversity. • Fosters intrinsic interoperability. • Promotes discovery. • Promotes federation. • Fosters inherent reusability. • Emphasizes extensibility.

41. Potential Benefits • Promotes organizational agility. • Supports incremental implementation. Technical architecture that adheres to and supports the principles of service orientation.

42. Business logic Focus on the Business– Process and Services Application a Application b Application c Application logic Source: Service-Oriented Architecture, Thomas Erl

43. Focus on the Business– Process and Services Business process layer Business-oriented services Services interface layer Application-oriented services Application layer .NET J2EE Legacy Source: Service-Oriented Architecture, Thomas Erl

44. orchestration service layer business service layer application service layer Focus on the Business– Process and Services Business process layer Services interface layer Application layer .NET J2EE Legacy Source: Service-Oriented Architecture, Thomas Erl

45. SOA hype • Beware that SOA is used in many different ways within the IT community (“most despised buzzword according to several surveys”) • Erl-1 does a good job of sorting through a lot of this -- should read ch. 1-3 carefully. • Still, many attributes ascribed to SOA are carryovers from the “old days” -- encapsulation of business logic, language interoperability, network transparency, loose coupling, etc. etc. What is new?

46. BPEL • BPEL is a key part of the Web Services activities • BPEL 2.0 called WS-BPEL • BPEL is a programming language specialized for creating/executing a workflow of assembled web services (think driver language). • BPEL is built on top of a number of XML-related specifications • XML is used as the syntax for BPEL • WSDL is used as the interface description of Web Services • XML Schema is used to describe the types used by BPEL processes • XPath is used to extract parts of data in a BPEL process

47. SOA vs. Web services • SOA design concepts exist independently of web services -- web services are one (and currently the only) standard upon which SOA designs can be built and deployed. This is a pretty uniformly accepted view. • By the same token, using web services does not necessarily imply SOA design • That said, in real world modern SOA the two technologies are tightly linked and go hand in hand

48. BPEL and BPMN • There is no standardized graphical notation for BPEL • XML is used as the standardized syntax • the BPEL syntax is defined by an XML Schema • most BPEL tools provide graphical notations • different products use different notations • Business Process Modeling Notation (BPMN) has been proposed as a graphical notation standard

49. Some perspective • Think about and try to articulate the relationship between SOA and other common programming models • Structured • OO • Component-based • Distributed • Client-server programming • Confluence of many existing ideas, but SOA is definitely a shift in perspective (if not a radically new paradigm).

50. Exercise 2