Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Erl's SOA Chapter 4

2,738 views

Published on

  • DOWNLOAD FULL BOOKS, INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

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>

×