Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • From an IT perspective, enterprise logic can be divided into two perspectives– business logic and application logic Business logic is a documented implementation of the business requirements Application logic is an automated implementation of the business logic organized into various technology solutions
  • notes1.ppt

    1. 1. Ace104 Lecture 1 Introduction Distributed Architectures SOA Concepts
    2. 2. “ Traditional” programming models
    3. 3. Distributed programming models: Classic Web-based <ul><li>Easy to deploy but slow, not great user experience </li></ul>html browser Web Server http Dynamically Generated html <ul><li>Many programming models </li></ul><ul><li>JSP </li></ul><ul><li>ASP </li></ul><ul><li>Servlets </li></ul><ul><li>PHP </li></ul><ul><li>CGI (python, perl, C) </li></ul><ul><li>Cold Fusion </li></ul>html plus optionally JavaScript to jazz up html database Lacks full support of apps server -- no transactions, rpc, etc.
    4. 4. Distributed programming models Typical Web-based <ul><li>Better user experience. Heavier, less portable, requires socket programming to stream to server. </li></ul>Web Server http Dynamically Generated html html + applet database applet html socket
    5. 5. Direct Connections <ul><li>Direct socket and rpc-style </li></ul>Application client App1 Remote Procedures App2 App3 NDS Examples: Java’s rmi, CORBA, DCOM Application client App1 sockets App2 App3 ports
    6. 6. Application Servers
    7. 7. RPC-style Web service
    8. 8. General role of XML <ul><li>Most modern languages have method of representing structured data. </li></ul><ul><li>Typical flow of events in application </li></ul>Read data (file, db, socket) Marshal objects Manipulate in program Unmarshal (file, db, socket) <ul><li>Many language-specific technologies to reduce these steps: RMI, object </li></ul><ul><li>serialization in any language, CORBA (actually somewhat language neutral), </li></ul><ul><li>MPI, etc. </li></ul><ul><li>XML provides a very appealing alternative that hits the sweet spot for </li></ul><ul><li>many applications </li></ul>
    9. 9. Simple XML-based architecture web browser Web Server http “ hand-rolled” XML XML python CGI “ hand-rolled” XML File system
    10. 10. Motivating Example1 Mortgage Calculator
    11. 11. Example: mortgage calculator <ul><li>Start very simple to motivate role of XML </li></ul><ul><li>All we need is a web server that supports a server-side programming model </li></ul><ul><li>We will build up this example to include first web service and then SOA concepts (as we gain experience) </li></ul>
    12. 12. Functional requirements <ul><li>Design a simple application which does the following: </li></ul><ul><ul><li>Accepts user input </li></ul></ul><ul><ul><ul><li>Loan amount </li></ul></ul></ul><ul><ul><ul><li>Loan term </li></ul></ul></ul><ul><ul><ul><li>Interest rate </li></ul></ul></ul><ul><ul><ul><li>Extras (assessments + taxes) </li></ul></ul></ul><ul><ul><li>Returns per-month table of </li></ul></ul><ul><ul><ul><li>total payment </li></ul></ul></ul><ul><ul><ul><li>interest </li></ul></ul></ul><ul><ul><ul><li>principal </li></ul></ul></ul><ul><ul><ul><li>some other fun stuff </li></ul></ul></ul>
    13. 13. Design requirements <ul><li>Must be </li></ul><ul><ul><li>Clean simple interface (easy) </li></ul></ul><ul><ul><li>Remotely accessible with security </li></ul></ul><ul><ul><li>Portable to different machine architectures </li></ul></ul><ul><ul><li>Not require heavyweight or sophisticated installation on the part of the user </li></ul></ul><ul><ul><li>Sufficiently fast not to be embarrassing given 10 hits/minute maximum usage </li></ul></ul>
    14. 14. Some possible architectures <ul><li>Things I tried </li></ul><ul><ul><li>what are (dis) advantages of each? </li></ul></ul><ul><li>Web server </li></ul><ul><ul><li>Server-side scripting with pure (dynamic) html </li></ul></ul><ul><ul><li>Server-side scripting with html+javascript </li></ul></ul><ul><ul><li>Server-side scripting with html+applet </li></ul></ul><ul><li>Direct connection </li></ul><ul><ul><li>Raw sockets </li></ul></ul><ul><ul><li>Distributed objects </li></ul></ul>
    15. 15. Initial choice <ul><li>Front-end: html form </li></ul><ul><li>Back end: python cgi </li></ul><ul><ul><li>Python generates web page dynamically after making calculations </li></ul></ul><ul><ul><li>No use of higher-level web generation libraries at this point </li></ul></ul><ul><li>What are advantages/disadvantages of this architecture? </li></ul><ul><li>Run application: </li></ul><ul><ul><li> </li></ul></ul>
    16. 18. Disadvantages <ul><li>Two obvious disadvantages are: </li></ul><ul><ul><li>Formatted web content in print statements low-level, ugly error prone </li></ul></ul><ul><ul><li>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? </li></ul></ul><ul><li>Several strategies can help with both of these (higher-level htmlgen libraries, server-side scripting model, beans, etc.) and XML </li></ul><ul><li>We will look at how XML fits in </li></ul>
    17. 19. Key Questions <ul><li>What does browser do with XML? </li></ul><ul><ul><li>Can it display? </li></ul></ul><ul><ul><li>Does it even understand XML? </li></ul></ul><ul><ul><ul><li>If not, what good is this? </li></ul></ul></ul><ul><li>Do we have to hand roll our programming language objects from XML? </li></ul>
    18. 20. Some answers <ul><li>Regarding first point, try this with your web browser </li></ul><ul><ul><li>Note that XML is displayed/formatted nicely, but not nearly to the same level of utility as the html table </li></ul></ul><ul><ul><li>To transform to html, we must associate a separate .xsl file (e.g.) with the XML file. We will study XSL soon. </li></ul></ul><ul><li>Regarding XML-language conversion, we will study language binding for various high-level ways of doing this. For now, we will hand-roll ourselves! </li></ul>
    19. 21. Lottery application
    20. 22. Functional requirements <ul><li>Given a list of student members of a dormitory, perform an ordered randomized sort of the students to determine a room draft order. </li></ul>
    21. 23. Functional requirements, cont. <ul><li>Students are defined by </li></ul><ul><ul><li>Last name </li></ul></ul><ul><ul><li>First name </li></ul></ul><ul><ul><li>Seniority </li></ul></ul><ul><ul><ul><li>Quarters in the House </li></ul></ul></ul><ul><ul><ul><li>Quarters in the College </li></ul></ul></ul><ul><li>The sort keys are </li></ul><ul><ul><li>Quarters in House </li></ul></ul><ul><ul><li>Quarters in College </li></ul></ul><ul><ul><li>Random </li></ul></ul>
    22. 24. Software requirements <ul><li>Secure login </li></ul><ul><ul><li>House name </li></ul></ul><ul><ul><li>Password </li></ul></ul><ul><li>Remotely accessible to single small company </li></ul><ul><ul><li>Several hits per hour maximum </li></ul></ul><ul><li>All Windows Users </li></ul><ul><li>What I tried </li></ul><ul><ul><li>Excel embedded in IE6 </li></ul></ul><ul><ul><li>Web-based with java servlets, XML, XSLT </li></ul></ul>
    23. 25. Sketch of XML/Servlet solution XML Login Info XML Student Data filesystem Web Server login lottery Web Client XML XSLT
    24. 26. Exercise 1
    25. 27. An exercise1 solution Travel Service Internal Rules Engine Security manager Web Client html Web Client xml xml ? html http Complexity of marshaling/unmarshaling XML How to represent state Ease of integration -- no proprietary issues Ability to use Schema for validation http
    26. 28. SOA Concepts A Very Brief Introduction
    27. 29. Standards Organizations Basic Profile, Basic Security Profile UDDI, ebXML, SAML, XACML, WS-BPEL, WS-Security XML, XML Schema, Xquery, XML Encryption, XML Signature, Xpath, XSLT, WSDL, SOAP, WS-CDL, WS-Addressing Prominent SOA-specific deliverables To foster standardized interoperability using Web services standards To promote online trade and commerce via specialized Web services standards To further the evolution of web via standards that improve info sharing Overall SOA-specific goals 200 600 400 membership WS-I (2002) OASIS (1998) W3C (1994)
    28. 30. This is all a work in progress <ul><li>Reading too much gives the impression that these are turnkey solutions. </li></ul><ul><li>In fact, remember that MANY of these standards are very immature and are at various stages of implementation by different vendors. </li></ul><ul><li>They also tend to change quickly in the early years. Be very careful when applying to real problems! </li></ul><ul><li>Question: are open standards worthwhile? If so, who do they benefit and how? </li></ul>
    29. 31. SOA Definitions <ul><li>What is a SOA? </li></ul><ul><ul><li>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 .” </li></ul></ul>
    30. 32. SOA definitions, cont. <ul><ul><li>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. </li></ul></ul><ul><ul><li>SOA can establish an abstraction of business logic and technology, resulting in a loose coupling between these domains. </li></ul></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>SOA is ideally standardized throughout an enterprise, but chieving this state requires a planned transition and the support of a still evolving technology set.” </li></ul></ul>
    31. 33. SOA Definitions, cont. <ul><li>OMG : “ Service Oriented Architecture is an architectural style for a community of providers and consumers of services to achieve mutual value, that: </li></ul><ul><ul><li>Allows participants in the communities to work together with minimal co-dependence or technology dependence </li></ul></ul><ul><ul><li>Specifies the contracts to which organizations, people and technologies must adhere in order to participate in the community </li></ul></ul><ul><ul><li>Provides for business value and business processes to be realized by the community </li></ul></ul><ul><ul><li>Allows for a variety of technologies to be used to facilitate interactions within the community ” </li></ul></ul>
    32. 34. SOA definitions, cont. <ul><li>W3C: “ A form of distributed systems architecture that is typically characterized by the following properties: </li></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>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 &quot;wrapped&quot; in message handling code that allows it to adhere to the formal service definition. </li></ul></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>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. “ </li></ul></ul>
    33. 35. SOA definition, cont. <ul><li>Open Group : “An architectural style that supports service orientation … </li></ul><ul><li>Service orientation </li></ul><ul><li>A way of a way of thinking in terms of services and service based development and the outcomes that services bring Service </li></ul><ul><li>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 </li></ul><ul><li>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 </li></ul><ul><li>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 L itmus Test, which determined a g ood services” </li></ul>
    34. 36. SOA: the basics What it is. What it is not.
    35. 37. Real SOA <ul><li>Changed mindset: service-oriented context for business logic. </li></ul><ul><li>Changed automation logic: service-oriented applications. </li></ul><ul><li>Changed infrastructure: service-oriented technologies. </li></ul><ul><li>A top-down organization transformation requiring real commitment. </li></ul>
    36. 38. SOA Characteristics <ul><li>Loosely coupled: minimizes dependencies between services. </li></ul><ul><li>Contractual: adhere to agreement on service descriptions. </li></ul><ul><li>Autonomous: control the business logic they encapsulate. </li></ul><ul><li>Abstract: hide the business logic from the service consumers. </li></ul>
    37. 39. SOA Characteristics <ul><li>Reusable: divide business logic into reusable services. </li></ul><ul><li>Composable: facilitate the assembly of composite services. </li></ul><ul><li>Stateless: minimize retained information specific to an activity. </li></ul><ul><li>Discoverable: self-described so that they can be found and assessed. </li></ul>
    38. 40. Potential Benefits <ul><li>Based on open standards. </li></ul><ul><li>Supports vendor diversity. </li></ul><ul><li>Fosters intrinsic interoperability. </li></ul><ul><li>Promotes discovery. </li></ul><ul><li>Promotes federation. </li></ul><ul><li>Fosters inherent reusability. </li></ul><ul><li>Emphasizes extensibility. </li></ul>
    39. 41. Potential Benefits <ul><li>Promotes organizational agility. </li></ul><ul><li>Supports incremental implementation. </li></ul><ul><li>Technical architecture that adheres to and supports the principles of service orientation. </li></ul>
    40. 42. Focus on the Business– Process and Services Application a Application c Application b Application logic Source: Service-Oriented Architecture, Thomas Erl Business logic
    41. 43. Focus on the Business– Process and Services Application layer Services interface layer Business process layer Application-oriented services Business-oriented services .NET J2EE Legacy Source: Service-Oriented Architecture, Thomas Erl
    42. 44. Focus on the Business– Process and Services Application layer Services interface layer Business process layer .NET J2EE Legacy Source: Service-Oriented Architecture, Thomas Erl orchestration service layer business service layer application service layer
    43. 45. SOA hype <ul><li>Beware that SOA is used in many different ways within the IT community (“most despised buzzword according to several surveys”) </li></ul><ul><li>Erl-1 does a good job of sorting through a lot of this -- should read ch. 1-3 carefully. </li></ul><ul><li>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? </li></ul>
    44. 46. BPEL <ul><li>BPEL is a key part of the Web Services activities </li></ul><ul><ul><li>BPEL 2.0 called WS-BPEL </li></ul></ul><ul><ul><li>BPEL is a programming language specialized for creating/executing a workflow of assembled web services (think driver language). </li></ul></ul><ul><ul><li>BPEL is built on top of a number of XML-related specifications </li></ul></ul><ul><ul><ul><li>XML is used as the syntax for BPEL </li></ul></ul></ul><ul><ul><ul><li>WSDL is used as the interface description of Web Services </li></ul></ul></ul><ul><ul><ul><li>XML Schema is used to describe the types used by BPEL processes </li></ul></ul></ul><ul><ul><ul><li>XPath is used to extract parts of data in a BPEL process </li></ul></ul></ul>
    45. 47. SOA vs. Web services <ul><li>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. </li></ul><ul><li>By the same token, using web services does not necessarily imply SOA design </li></ul><ul><li>That said, in real world modern SOA the two technologies are tightly linked and go hand in hand </li></ul>
    46. 48. BPEL and BPMN <ul><li>There is no standardized graphical notation for BPEL </li></ul><ul><ul><li>XML is used as the standardized syntax </li></ul></ul><ul><ul><li>the BPEL syntax is defined by an XML Schema </li></ul></ul><ul><ul><li>most BPEL tools provide graphical notations </li></ul></ul><ul><ul><li>different products use different notations </li></ul></ul><ul><ul><li>Business Process Modeling Notation (BPMN) has been proposed as a graphical notation standard </li></ul></ul>
    47. 49. Some perspective <ul><li>Think about and try to articulate the relationship between SOA and other common programming models </li></ul><ul><ul><li>Structured </li></ul></ul><ul><ul><li>OO </li></ul></ul><ul><ul><li>Component-based </li></ul></ul><ul><ul><li>Distributed </li></ul></ul><ul><ul><li>Client-server programming </li></ul></ul><ul><li>Confluence of many existing ideas, but SOA is definitely a shift in perspective (if not a radically new paradigm). </li></ul>
    48. 50. Exercise 2
    49. 51. Organization of Book <ul><li>Web Services and “Primitive SOA” </li></ul><ul><ul><li>Services (as web services) </li></ul></ul><ul><ul><li>Service descriptions (WSDL) </li></ul></ul><ul><ul><li>Messaging (SOAP) </li></ul></ul><ul><li>Web Services and “Contemporary SOA” </li></ul><ul><ul><li>Part I: MEPs, service activity, atomicity, business activities, orchestration, choreography </li></ul></ul><ul><ul><li>Part II: Advanced messaging, metadata, and security </li></ul></ul><ul><li>We will roughly follow this ordering but precede it with a deep understanding of XML, Schema … </li></ul><ul><li>This will be topic of next lecture </li></ul>
    50. 52. Quiz