Erl's SOA Chapter 4


Published on

  • Be the first to comment

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

No notes for slide

Erl's SOA Chapter 4

  1. 1. SOA Chapter 4 The Evolution of SOA
  2. 2. An SOA Timeline XML to Web Services to SOA <ul><li>XML was a creation of W3C </li></ul><ul><li>Derived from SGML </li></ul><ul><li>Designed to expose the structure of a document for processing </li></ul><ul><li>Adds “intelligence” to ordinary documents </li></ul><ul><li>XML gained in popularity in the eBusiness movement of the 90’s </li></ul><ul><li>Server side scripting made conducting business via the internet possible </li></ul>
  3. 3. SOA Timeline <ul><li>XML allowed developers to attach meaning and context to a document that was transmitted across internet protocols </li></ul><ul><li>XML was used as the basis for additional standards including XSD (schema definition) and XSLT (transformation language) </li></ul>
  4. 4. XML <ul><li>XML data representation is the foundation layer of SOA </li></ul><ul><li>XML establishes the structure of messages traveling between services </li></ul><ul><li>XSD schemas preserve the integrity and validity of message data </li></ul><ul><li>XSLT is used to enable communication between disparate data representations by schema mapping </li></ul>
  5. 5. Web Services <ul><li>W3C recieves Simple Object Access Protocol (SOAP) in 2003 </li></ul><ul><li>SOAP messages now represent the communications layer for SOA </li></ul><ul><li>This provided a proprietary-free Internet communications layer </li></ul><ul><li>This led to the idea of creating a pure, Web-based, distributed technology – Web services </li></ul><ul><li>This helped bridge the enormous disparity between and within organizations </li></ul>
  6. 6. Web Services <ul><li>The most important part of a Web service is its public interface </li></ul><ul><li>This is the central piece of information that assigns a service an identity and enables its invocation </li></ul><ul><li>WSDL (Web Services Description Language) was one of the first initiatives in support of Web services </li></ul><ul><li>WSDL was submitted to W3C in 2001 </li></ul>
  7. 7. Web Services <ul><li>Web services required an Internet-friendly and XML-compliant communications format </li></ul><ul><li>Other alternatives were considered (XML-RPC), but SOAP was the winning technology </li></ul><ul><li>W3C responded by releasing newer versions of SOAP that allow RPC-style and document-style messages </li></ul><ul><li>SOAP became a standalone term as the acronym no longer matched the purpose </li></ul>
  8. 8. UDDI <ul><li>Universal Description, Discovery and Integration </li></ul><ul><li>Submitted to OASIS </li></ul><ul><li>Allows for the creation of standardized service description registries </li></ul><ul><li>Services can be registered in a central location and discovered by service requestors </li></ul><ul><li>Unlike WSDL and SOAP, UDDI hasn’t yet attained industry-wide acceptance </li></ul><ul><li>Remains an optional extension to SOA </li></ul>
  9. 9. Custom Web Services <ul><li>Custom services were developed to accommodate specialized business requirements </li></ul><ul><li>Existing messaging platforms (Message Oriented MiddleWare – MOM) incorporated services to support SOAP </li></ul><ul><li>Some organizations incorporated Web services for B2B data exchange – replacing EDI (Electronic Data Interchange) </li></ul>
  10. 10. Brief History of SOA <ul><li>It became clear that Web services could be the basis for a separate architectural platform </li></ul><ul><li>Early SOA is modeled around three basic components: </li></ul>Service Registry Service Requestor Service Provider Service Provider Publish WSDL Discover and Retrieve WSDL Exchange Soap Messages
  11. 11. SOA Extensions <ul><li>This early model has been extended by WS-* specifications </li></ul><ul><li>The goal was to elevate Web services technology to an enterprise level </li></ul><ul><li>There was also an interest in applying service-oriented concepts to business analysis </li></ul><ul><li>This vision was supported by the rise of business process definition languages – WS-BPEL </li></ul>
  12. 12. SOA History <ul><li>Business Process Management models (BPM) can now be expressed in a concrete executable format </li></ul><ul><li>SOA is still evolving </li></ul><ul><li>New standards are still be developed and adopted </li></ul>
  13. 13. SOA Affects XML and Web Services <ul><li>XML and Web services platforms have had to change in order to adapt to SOA architectures </li></ul><ul><li>Older distributed applications using XML and Web services have to be modified </li></ul>
  14. 14. Retrofitting Issues <ul><li>Data Representation and Service Modeling standards must be aligned </li></ul><ul><li>SOAP is used for all inter-service communication. XML documents and XSD schemas are modeled with SOAP in mind </li></ul><ul><li>Document-style messaging is standard. Changing from RPC-style imposes changing on services </li></ul>
  15. 15. Retrofitting Issues <ul><li>SOAP promotes a content and intelligence-heavy message model. This supports statelessness, autonomy and minimizes message sending </li></ul><ul><li>RPC-style messaging supported granular XML documents with targeted data </li></ul><ul><li>Transition models for applications may be needed until advance messaging with WS-* is available </li></ul>
  16. 16. Continuing SOA Evolution <ul><li>The evolution of WS-* standards will affect any SOA solution you build </li></ul><ul><li>Standard – an excepted industry technology. All first generation Web services, XML and its related standards </li></ul><ul><li>Specification – A proposed or accepted standard, described within a specification. XML, Web services and all WS-* extensions exist within specifications </li></ul><ul><li>Extension – a WS-* specification or feature </li></ul>
  17. 17. Standard Organizations <ul><li>Internet standards organizations have agendas that overlap and are not always distinct </li></ul><ul><li>The primary contributors to vendor-neutral standards are the vendors themselves </li></ul>
  18. 18. Standard Organizations <ul><li>The World Wide Web Consortium (W3C) </li></ul><ul><ul><li>Founded by Tm Berners-Lee in 1994 </li></ul></ul><ul><ul><li>Began with HTML </li></ul></ul><ul><ul><li>XML, XML Schema, XSLT, SOAP, WSDL, and Web Services </li></ul></ul><ul><ul><li>Formal and rigorous with many public reviews </li></ul></ul><ul><ul><li>Two to three years for standards to be adopted </li></ul></ul>
  19. 19. Standard Organizations <ul><li>Organization for the Advancement of Structured Information Standards (OASIS) </li></ul><ul><ul><li>Created in 1993 as SGML Open </li></ul></ul><ul><ul><li>Renamed when their scope changed from SGML to XML standards </li></ul></ul><ul><ul><li>Over 600 organizations </li></ul></ul><ul><ul><li>WS-BPEL, ebXML, contributions to UDDI, SAML (security), XACML </li></ul></ul><ul><ul><li>Focuses on core, industry-agonostic standards, leveraging standards to support vertical industries </li></ul></ul><ul><ul><li>Shorter development times than W3C </li></ul></ul>
  20. 20. Standard Organizations <ul><li>The Web Services Interoperability Organization (WS-I) </li></ul><ul><ul><li>Does not create new standards but ensures the goal of open interoperability </li></ul></ul><ul><ul><li>200 organizations, all major SOA vendors </li></ul></ul><ul><ul><li>Basic Profile – a recommendation-based document that establishes which available standards form the most desirable interoperability architecture </li></ul></ul><ul><ul><li>Positions specific versions of WSDL, SOAP, UDDI, XML, XML Schema </li></ul></ul><ul><ul><li>Basic Security Profile </li></ul></ul>
  21. 21. Some Major Vendors <ul><li>Microsoft, IBM, BEA Systems, Sun Microsystems, Oracle, Tibco, Hewlett-Packard, Canon, Commerce One, Fujitsu, Software AG, Nortel, Verisign, WebMethods </li></ul>
  22. 22. Vendor Influence <ul><li>Each vendor has its own vision for SOA </li></ul><ul><li>IBM uses WebSphere </li></ul><ul><li>Microsoft supports .NET and its operating system </li></ul><ul><li>Vendors try to influence decisions using proprietary designs </li></ul>
  23. 23. Vendor Alliances <ul><li>Vendors form loose alliances for common goals </li></ul><ul><li>IBM, Microsoft and BEA have collaborated on several WS-* extentions </li></ul><ul><li>OASIS supported WS-ReliableMessaging. Microsoft and IBM announced their own specification – WS-Reliability, which has become the contender </li></ul>
  24. 24. Why You Should Care <ul><li>When migrating to SOA, the maturation process of the standards must be considered </li></ul><ul><li>Watching standards allows you to gage which ones will succeed </li></ul><ul><li>Watching standards clues you into trends </li></ul><ul><li>Maintaining a vendor-neutral perspective is wise </li></ul>
  25. 25. Roots of SOA <ul><li>With the rise of multi-tier applications, the variations with which applications could be delivered began to increase </li></ul><ul><li>A definition of a baseline definition application becomes important </li></ul><ul><li>The definition is abstract but describes the technology, boundaries, rules, limitations and design characteristics that apply to all solutions – an application architecture </li></ul>
  26. 26. Application Architecture <ul><li>An application architecture is a blueprint </li></ul><ul><li>Different levels can be specified, depending on the organization </li></ul><ul><li>Might include physical and logical representations, data models, communication flow diagrams, security requirements </li></ul><ul><li>Several application architectures may exist in an enterprise and kept in alignment by an enterprise architecture </li></ul>
  27. 27. Enterprise Architecture <ul><li>Enterprise architectures provide high-level views of all forms of heterogenity </li></ul><ul><li>“ Urban plan for a city” </li></ul><ul><li>Contain a long-term vision of how an organization will evolve its technologies </li></ul>
  28. 28. Service Oriented Architecture <ul><li>Spans both enterprise and application architecture domains </li></ul><ul><li>Benefits of SOA are realized when applied across multiple solution environements </li></ul><ul><li>Because SOA is a composable architecture, a company may have multiple SOAs </li></ul>
  29. 29. SOA vs Client Server <ul><li>Mainframes provided the first “client-server” computing with synchronous and asynchronous communication </li></ul><ul><li>CICS – conversational and nonconversational mode </li></ul><ul><li>1980s – two-tier client server with fat clients, GUI, database. Dominated the 90s </li></ul>
  30. 30. Client Server Characteristics <ul><li>Bulk of the application logic resides with the client </li></ul><ul><li>Monolithic executable on client </li></ul><ul><li>Business rules were maintained in stored procedures and triggers on the database </li></ul><ul><li>This abstracted a set of business logic from the client and simplified data access programming </li></ul><ul><li>Overall, the client ran the show </li></ul>
  31. 31. SOA Characteristics <ul><li>Presentation layer can be any software capable of exchanging SOAP messages </li></ul><ul><li>SOA principles dictate partitioning logic into autonomous units </li></ul><ul><li>SOA units of logic are solution agnostic </li></ul>
  32. 32. Client-Server Application Processing <ul><li>80% - workstation, 20% server </li></ul><ul><li>Even so, the database is often the bottleneck </li></ul><ul><li>Two-tier solutions usually mean each client has a database connection </li></ul><ul><li>Connections are often synchronous and persistent </li></ul><ul><li>80% processing on client may mean client programs run exclusively </li></ul>
  33. 33. SOA Characteristics <ul><li>Processing with SOA is highly distributed </li></ul><ul><li>Each service has explicit functional boundaries and resource requirements </li></ul><ul><li>SOA allows many options for deploying services </li></ul><ul><li>Enterprise solutions consist of multiple servers with sets of Web services and supporting middleware </li></ul><ul><li>With SOA there is no fixed processing ratio </li></ul>
  34. 34. SOA Characteristics <ul><li>Supports synchronous and asynchronous communication between service and requestors </li></ul><ul><li>Messages are loaded with intelligence to support message-level context management </li></ul><ul><li>Smart messaging promotes stateless and autonomous services </li></ul>
  35. 35. Client-Server Application Technology <ul><li>The technology set for client-server applications included 4GLs like VB and PowerBuilder, RDBMSs </li></ul><ul><li>The SOA technology set has expanded to include Web technologies (HTML, CSS, HTTP, etc) </li></ul><ul><li>SOA requires the use of XML data representation architecture along with a SOAP messaging framework </li></ul>
  36. 36. Client-Server Application Security <ul><li>Centralized at the Server level </li></ul><ul><li>Databases manage user accounts and groups </li></ul><ul><li>Also controlled within the client executable </li></ul><ul><li>Security for SOA is much more complex </li></ul><ul><li>Security complexity is directly related to the degree of security measures required </li></ul><ul><li>Multiple technologies are required, many in WS-Security framework </li></ul>
  37. 37. Client-Server Application Administration <ul><li>Significant maintenance costs associated with client-server </li></ul><ul><li>Each client housed application code </li></ul><ul><li>Each update required redistribution </li></ul><ul><li>Client stations were subject to environment-specific problems </li></ul><ul><li>Increased server-side demands on databases </li></ul>
  38. 38. Client-Server Application Administration <ul><li>SOA solutions are not immune to client-side maintenance challenges </li></ul><ul><li>Distributed back-end supports scalability, but new admin demands are introduced </li></ul><ul><li>Management of server resources and service interfaces may require new admin tools and even a private registry </li></ul><ul><li>Commitment to services and their maintenance may require cultural change in an organization </li></ul>
  39. 39. RailCo Case Study <ul><li>Accounting system is class two-tier </li></ul><ul><li>GUI front-end is a single executable, deployed on old Windows workstations </li></ul><ul><li>Only two or three users at a time </li></ul><ul><li>Outmoded RDBMS </li></ul><ul><li>OS upgrades produce erratic behavior on some pages </li></ul><ul><li>Workstations rarely upgraded and are underpowered </li></ul><ul><li>New Records management policy requires supplementary forms not supported by system </li></ul>
  40. 40. RailCo Case Study <ul><li>SOA solutions eliminate dependency on user workstations by delegating all processing to server-side </li></ul><ul><li>SOA establishes extensible architecture model that allows solutions to be enhanced with minimal impact </li></ul><ul><li>Services can encapsulate existing legacy logic providing a standardized API for larger integrated solutions </li></ul>
  41. 41. SOA vs Traditional Distributed Internet Architecture <ul><li>Muliple client-server architectures have appeared </li></ul><ul><li>Client-server DB connections have been replaced with Remote Procedure Call connections (RPC) using CORBA or DCOM </li></ul><ul><li>Middleware application servers and transaction monitors require significant attention </li></ul><ul><li>Multi-tiered client-server environments began incorporating internet technology in 90s. </li></ul>
  42. 42. SOA vs Traditional Distributed Internet Architecture <ul><li>The browser shifted 100% of application logic to the server </li></ul><ul><li>Distributed Internet architecture introduced the Web server as a new physical tier </li></ul><ul><li>HTTP replaced RPC protocols </li></ul>
  43. 43. SOA vs Traditional Distributed Internet Architecture <ul><li>Distributed Internet application put all the application logic on the server side </li></ul><ul><li>Even client-side scripts are downloaded from the server </li></ul><ul><li>Entire solution is centralized </li></ul><ul><li>Emphasis is on: </li></ul><ul><ul><li>How application logic is partitioned </li></ul></ul><ul><ul><li>Where partitioned units reside </li></ul></ul><ul><ul><li>How units of logic should interact </li></ul></ul>
  44. 44. SOA vs Traditional Distributed Internet Architecture <ul><li>Difference lies in the principles used to determine the three primary design considerations </li></ul><ul><li>Traditional systems create components that reside on one or more application servers </li></ul><ul><li>Components have varying degrees of functional granularity </li></ul><ul><li>Components on the same server communicate via proprietary APIs. </li></ul><ul><li>RPC protocols are used across servers via proxy stubs </li></ul>
  45. 45. SOA vs Traditional Distributed Internet Architecture <ul><li>Actual references to other physical components can be embedded in programming code (tight coupling) </li></ul><ul><li>SOAs also rely on components </li></ul><ul><li>Services encapsulate components </li></ul><ul><li>Services expose specific sets of functionality </li></ul><ul><li>Functionality can originate from legacy systems or other sources </li></ul>
  46. 46. SOA vs Traditional Distributed Internet Architecture <ul><li>Functionality is wrapped in services </li></ul><ul><li>Functionality is exposed via open, standardized interface, irrespective of technology providing the solution </li></ul><ul><li>Services exchange information via SOAP messages. SOAP supports RPC-style and document-style messages </li></ul><ul><li>Most applications rely on document-style </li></ul>
  47. 47. SOA vs Traditional Distributed Internet Architecture <ul><li>Messages are structured to be self-sufficient </li></ul><ul><li>Messages contain meta information, processing instructions, policy rules </li></ul><ul><li>SOA fosters reuse on a deep level by promoting solution-agnostic services </li></ul>
  48. 48. Application Processing <ul><li>Distributed Internet architecture promotes the use of proprietary communication protocols (DCOM, CORBA) </li></ul><ul><li>SOA relies on message-based communication </li></ul><ul><li>Messages use serialization, transmission, de-serialization of SOAP messages containing XML payloads </li></ul><ul><li>RPC communication is faster than SOAP and SOAP processing overhead is a significant design issue </li></ul>
  49. 49. Application Processing <ul><li>Messaging framework supports a wide range message exchange patterns </li></ul><ul><li>Asynchronous patterns encouraged </li></ul><ul><li>Support for stateless services is supported by context management options (WS-Coordination, WS-BPEL </li></ul>
  50. 50. Technology <ul><li>Distributed Internet architecture now includes XML data representation </li></ul><ul><li>XML and Web services are optional for distributed Internet architecture but not for SOA </li></ul>
  51. 51. Security <ul><li>When application logic crosses physical boundaries, security becomes more difficult </li></ul><ul><li>Traditional security architectures incorporate delegation and impersonation as well as encryption </li></ul><ul><li>SOAs depart from this model by relying heavily on WS-Security to provide security logic on the messaging level </li></ul><ul><li>SOAP messages carry headers where security logic can be stored </li></ul>
  52. 52. Administration <ul><li>Maintaining component-base applications involves: </li></ul><ul><ul><li>keeping track of individual components </li></ul></ul><ul><ul><li>tracing local and remote communication problems </li></ul></ul><ul><ul><li>Monitoring server resource demands </li></ul></ul><ul><ul><li>Standard database administrative tasks </li></ul></ul><ul><li>Distributed Internet Architecture introduces the Web server and its physical environment </li></ul>
  53. 53. Administration <ul><li>SOA requires additional runtime administration: </li></ul><ul><ul><li>Problems with messaging frameworks </li></ul></ul><ul><ul><li>Additional administration of a private or public registry of services </li></ul></ul>
  54. 54. TLS Case Study <ul><li>TLS Accounting system is a large, distributed component-based solution </li></ul><ul><li>Components exist on separate application servers: </li></ul><ul><ul><li>Web server hosting server-side scripts that relay HTTP requests to components on application servers and process responses </li></ul></ul><ul><ul><li>An application server hosting a controller component that generates transaction context and manages specialized components </li></ul></ul>
  55. 55. TLS Case Study <ul><li>Components exist on separate application servers: </li></ul><ul><ul><li>A possible second application server hosting two or more business components that enforce specific business rules. This server may host components that encapsulate data access logic </li></ul></ul><ul><ul><li>A database server hosting a complete RDBMS </li></ul></ul>
  56. 56. TLS Case Study <ul><li>Issues with the accounting system: </li></ul><ul><ul><li>Many components were customed developed to alter existing functionality. Each redevelopment project is increasingly expensive (lots of testing and redeployment) </li></ul></ul><ul><ul><li>State management was never standardized. Some components manage state by caching data in memory, others use application server-deployed databases </li></ul></ul><ul><ul><li>XML was introduced and Permanent state management designs already had a relational storage format (not XML) </li></ul></ul>
  57. 57. TLS Case Study <ul><li>SOA establishes a loosely coupled relationship between units of processing logic. This allows services to be updated and evolved independently of existing service requestors </li></ul><ul><li>SOA promotes the standardization of XML throughout solution requirements. Service statelessness is emphasized by deferring state management to the message level </li></ul>
  58. 58. Service Orientation and Object Orientation <ul><li>SO emphasizes loose coupling between units of processing logic (services) </li></ul><ul><li>OO supports reusability of loosely coupled programming routines, much of it is based on predefined class dependencies, resulting in tightly bound processing logic (objects) </li></ul><ul><li>SO encourages coarse-grained interfaces (service descriptions) with information loaded messages </li></ul><ul><li>OO supports fine-grained interfaces (APIs) so units of communication (RPC or local API calls) can perform various tasks </li></ul>
  59. 59. Service Orientation and Object Orientation <ul><li>SO expects the scope of a service to vary significantly </li></ul><ul><li>OO objects tend to be smaller and more specific in scope </li></ul><ul><li>SO promotes activity-agnostic units of processing logic (services) that are driven into action by intelligent messages </li></ul><ul><li>OO encourages the binding of processing logic with data into objects </li></ul>
  60. 60. Service Orientation and Object Orientation <ul><li>SO prefers services be designed to remain as stateless as possible </li></ul><ul><li>OO promotes binding data and logic into stateful objects </li></ul><ul><li>SO supports loosely coupled services </li></ul><ul><li>OO supports composition but also inheritance among classes which leads to tightly coupled class dependencies </li></ul>