1. 28 October 2008CIS 340 # 1 Topics (continuing) To develop the concepts guiding SOA To define SOA components

2. From Components to Web services Software components Reusable components –Same languages, platforms Making sure your components play nicely together –Standards 28 October 2008CIS 340 # 2

3. From Components to Web services If every function of the order-processing application is a Web service, other programs can use those functions instead of reinventing the wheel. –As long as WS use standard web interfaces; 28 October 2008CIS 340 # 3

4. 28 October 2008CIS 340 # 4 SOA vs. Web services [DEF. Addendum] (p. 37).. does not imply web services.. web services does not imply SOA “Business logic must be separated from the plumbing... web services technology is what allows us to make this separation....” and “... business service components [of SOA] bring to the business the same efficiencies of reuse, ease of change, and consistency of results as Web services do on the programming level...” Def : definition of services is a top- down vision

5. SOA vs. Web services The difference is a big deal –The business services layer ensures business can respond quickly to new opportunities by making changes to business services without having to change the plumbing. –Business can change without rewriting the world because business components, like stereo components, can be swapped in and out as needed. The creation of a service oriented architecture involves –identifying the key business services a major, major deal different for different companies. –working top-down making key business services into black boxes business can reorganize itself as needed 28 October 2008CIS 340 # 5

6. 28 October 2008CIS 340 # 6

7. 28 October 2008CIS 340 # 7 Making SOA Happen: Foundational Concepts For components to be Reusable ∆ Must be standardized ∆ Must be built with standard interfaces ∆ Must express a focused functionality ∆ Must be loosely coupled

8. 28 October 2008CIS 340 # 8 Making SOA Happen: Foundational Concepts When components are Loosely coupled ∆ Control can be federated / shared ∆ Change can be incremental ∆ Rigid application-silos can become more flexible Software licenses Software as a service (SaaS) Siloed applications are those applications/components built specifically for immediate and exclusive use by one specific set of users with no intention or preparation for their use by others.

9. 28 October 2008CIS 340 # 9 Making SOA Happen: Foundational Concepts When application-silos are removed definitions ∆ Inconsistent data definitions are impossible maintaining ∆ Duplication of software processes maintaining silos is unnecessary

10. SOA - Loose coupling Two aspects –If component services come together and come apart easily, –Component services and the plumbing (the basic instructions for how the pieces interact with each other) are deliberately separated so that the service itself has no code related to managing the computing environment. Loose coupling is possible because of all the support provided by various service oriented architecture components Benefits –Create new applications quickly –Replace one service with another without rewriting the whole application: by using existing services –Create secure business applications quickly –Isolate problems easily –Turn software services into cash 28 October 2008CIS 340 # 10

11. 28 October 2008CIS 340 # 11 Basic SOA Components

12. Components enterprise service bus (ESB) –makes sure that messages get passed back and forth between the components of a SOA implementation SOA registry –Contains important reference information about where the components are workflow engine –provides the technology to connect people to people, to connect people to processes and processes to processes Service broker –connects services to services, which in the end enables the flow of business process SOA supervisor –make sure that the platform underneath the SOA environment works in a consistent and predictable way 28 October 2008CIS 340 # 12

13. Just one more look 28 October 2008CIS 340 # 13

14. 28 October 2008CIS 340 # 14

15. XML

16. Reference Slides

17. 28 October 2008CIS 340 # 17 Service Models for Application Integration Proxy services –LegApp accesses capability as though as though a native interface –Easy to create –Inefficient, but gets the job done –RPC-centric Wrapper services –Expose specific parts of LegApp through a service interface –Custom-developed –Amount of “exposure” depends on the degree of legacy logic being relied upon by the adapter –Adapter is the specialized software realizing the “wrapping” –RPC-centric or document-centric

18. 28 October 2008CIS 340 # 18 Service Models for Application Integration: Wrappers vs. Proxies WR custom-developed PR auto-generated code, mark-up WR encapsulated functionality via an adapter PR mirror (mock-up) application interface WR designed to expose a select target of logic of the LegApp PR duplicate a LegApp interface WR use RPC & document messaging PR relies on RPC messaging BOTH do not introduce new business logic

19. 28 October 2008CIS 340 # 19 Service Models for Application Integration Coordination services / Coordinators –Center on ACID requirements –Grouping of three sub-services 1.Context creation – A query!! 2.Registration of coordination contexts 3.Protocol selection –Document-centric messaging –“The” –“The” option for WS deployment