Implementation of SOA

1. Implementation of SOA Juanzi Li Department of Computer Science and Technology Tsinghua University March 2007

2. Outline • Programming Model • SCA (Service Component Architecture) • SDO (Service Data Object) • Use Case (Simplified Bigbank)

3. Programming Model

4. What? • A pattern for building and deploying software applications and solutions. • Define and represent the structure and operation of the software application.

5. SOA Model • Define the structure and operation of composite applications • how to use services • how to aggregate services together • Define the key elements • how elements are created • how elements are linked together • how the solution is deployed

6. SOA Model • Derives from basic concept of service: “A service is merely an abstraction that encapsulates a software function.” “Developers build services, use services and develop solutions that aggregate services.” “Composition of services into integrated solutions is a key activity”

7. SOA Model—Conceptual View

8. SOA Model—Elements

9. SOA Model—Elements Development • SDO - Service Data Object • Makes it easy to manage data exchange across services with heterogeneous data formats. • SCA Client & Implementation Model • Simplify implementation of business services by focusing on business logic not on infrastructure Integration Governance • SCA Binding & Policy Model • Expose components as Services regardless of underlying technology Business Process Modeling & Management Simplified Composition and Implementation for Services and Data Interoperability across Heterogeneous Environments Assembly • SCA Assembly Model • Assemble heterogeneous components into service networks

10. SCA & SDO in SOA Model • What? • New technology that allows solutions to be built based on SOA model • To separate the SOA solution into its appropriate elements • To simplify the representation of service-oriented business logic and associated data

11. SCA & SDO in SOA Model • SCA--Service Component Architecture • Provide the ability to represent business logic as a reusable component • Can be easily integrated • Strictly separate the defining of component implementations from usages of services • With SCA…

12. SCA & SDO in SOA Model • SDO--Service Data Object • Simplify data access • Simplify data representation • Provide a consistent and uniform way to access data regardless of how the data is physically accessed

13. SCA & SDO in SOA Model • SDO--Service Data Object • With SDO…

14. SCA & SDO in SOA Model • SCA & SDO can be used separately • SCA & SDO used together provide a powerful and flexible way in SOA • Business Components are represented as SCA components • Data used between components are represented as SDOs

15. Business Value of SCA & SDO • Improved Flexibility • Technology Neutral • Reuse • Composition • Adaptability to change

16. Business Value of SCA & SDO • Improved Flexibility

17. Business Value of SCA & SDO • Increased Programmer Productivity • Separation of concerns • Service Reuse • Top-Down Development • Improved Organization • Technology Neutral

18. Business Value of SCA & SDO J2EE Solution SCA Solution • Increased Programmer Productivity

19. Summary of SOA Model • Help improve business agility • Allow IT to build composite applications • Focus on business objectives, business goals, and business processes • Coarse grained, loosely coupled services of a composite application

20. SCA--Service Component Architecture

21. SCA in a Nutshell • SCA models the “A” in SOA for systems composed of reusable services • A programming model for service-based system: • construction • assembly • deployment • Heterogeneity • Metadata driven • Multiple languages • Multiple container technologies

22. What?... the “A” in SOA • A set of specifications • Describes a model for building applications and systems using a Service-Oriented Architecture • Extends and complements prior approaches to implementing services • Builds on open standards such as Web services

23. What?... the “A” in SOA • SCA divides up the steps in building a service-oriented application into two major parts • Implementation of components • provide services • consume other services • Assembly of sets of components • wiring of service references to services

24. What?... the “A” in SOA • SCA emphasizes the decoupling of service implementation and of service assembly from • details of infrastructure capabilities • details of the access methods used to invoke services • SCA components • operate at a business level • use a minimum of middleware APIs

25. What?... the “A” in SOA

26. What?... the “A” in SOA • Supports many programming languages • object-oriented and procedural languages • Java, PHP, C++, COBOL • XML-centric languages • BPEL and XSLT • declarative languages • SQL and XQuery

27. What?... the “A” in SOA • Supports a range of programming styles • asynchronous and message-oriented styles • synchronous call-and-return style • static programming styles • dynamic programming styles • connected styles • disconnected styles

28. What?... the “A” in SOA • Supports many access mechanisms • Web services • Messaging systems • CORBA IIOP • Declarative handling, independent of the implementation code • Bindings • Infrastructure capabilities

29. SCA and SOA infrastructure Composition, Visualization and Management Assembly Model Client Model Operations Architectural Design Development SCA ESB QoS Container Transports Policy Security Clustering Transactions SCA Java Spring EJB Service Registry Routing

30. Family of SCA specifications • A number of documents • Assembly Model • linking of components through wiring • independent of implementation language • Client and Implementation specification • implementation of service components and of service clients • Java & C++ specifications • BEPL

31. Family of SCA specifications • Current white papers • Changes in the SCA Assembly specification since the 0.9 release • The Recursive Assembly Model • WS-BPEL and SCA White Paper • EJB Integration White Paper • JAX-WS Services Integration • PHP and SCA White Paper • SCA Bindings for Web Services, JMS and EIS/JCA

32. Family of SCA specifications • Current draft specifications • SCA Assembly Model V0.96 • SCA Client and Implementation Model for Java (V0.95) • SCA Client & Implementation for BPEL (V0.95) • SCA Client & Implementation for Spring (V0.95) • SCA Client & Implementation for C++ (V0.95) • SCA Policy Framework • SCA Web Service bindings • SCA JMS Binding • SCA EIS/JCA Bindings

33. Developers & Supporters • Developers • OSOA (Open SOA Collaboration) • http://www.osoa.org

34. Developers & Supporters • Supporters

35. SCA vs. WS-* Specifications

36. SCA vs. J2EE • Scenario 1: • Integrate 2 EJBs, 1 JavaBean, and two Web Services into a JSP based web application: With SCA • Developer wires EJB access, JavaBean, and Web Services together using a Visual Tool. • Developer uses one wiring editor for all components (developer does not need to use specific APIs) – no low level APIs at all • Loose Coupling: New components can be wired into existing applications easily • No additional coding needed to invoke a component asynchronously • Structure of the solution captured in assembly model Without SCA • Developer hardcodes EJB access, JavaBean, and Web Service invocation in their web application • Specific low-level APIs must be used for each technology (EJB, JavaBean, Web Service) • Tight Coupling: Additional coding required to replace one EJB with another EJB • If one component needs to be invoked asynchronously, low level coding is necessary • Structure of the composite application is hard to visualize

37. SCA vs. J2EE • Scenario 2: • Integrate 1 Rule, 1 Web Service, 1 EJB, and 1 CICS Transaction into a BPEL Business Process: Without SCA • Developer uses wizards to generate WSDL for each component • Tight Coupling: Business process must be modified if a service is replaced by another service • If one component needs to be invoked asynchronously, a complex set of steps are required to build an asynchronous service. • Integration Developer = Highly skilled component developer With SCA • Developer assembles components developed by other developers or creates business components using Wizards/Tools. The assembler doesn’t care how each component is implemented • Loose Coupling: Business process does not need to be modified if a new service replaces another service (the new service is simply rewired into the application) • Simple to invoke a component asynchronously • Integration Developer = A developer who can build a composite application without low-level component development Skills

38. Roles/Tools/Runtime SCA Roles Uses Tasks Runtime uses this tool… This Person... …and deploys it to this runtime to perform this task … … to build this type of application Task: Build/Assemble J2EE Components Java Application Developer Tools Application Server (w/SCA) POJO JSF1 EJB1 Web Service Web Container EJB Container Service Component Developer SCA Composite Task: Build/Assemble Business Processes Process Server State Machine I/F or BO Transform Business Process Business Rule Adapter Process & Integration Developer Tools Process Container SCA Composite Task: Build Mediations ESB / Connection Server Integration Developer Mediation 1 Mediation 2 Mediation Container SCA Composite = SCA Component

39. SCA application architecture

40. Service Composition with SCA SCA components may be implemented using a variety of technologies including POJOs, BPEL, Spring Beans, EJBs, etc. System Composite A Composite C Refe- rence Service A SDO Service Component A Component B Refe- rence SDO Composite B Component C Component D Service Refe- rence Service B Services are assembled and “wired” together. SCA allows wiring to be done using a diverse bindings such as WS-* and JMS • Flexible, powerful service construction • Flexible, powerful assembly • Flexible, powerful binding

41. Service Assembly Model • Contents: • Assembly Model • Introduction, Overview, Composite , System, Binding, Extension Model • Appendix 1: • Packaging and Deployment, XML Schemas, UML Model, SCA Concepts • Appendix 2: • Policy, Security, Transactions, Reliable Messaging

42. Service Assembly Model • provides: • A unified, language-independent way to expose implementations as services • Java and C++ available now • BPEL and interpretive languages (e.g. XSLT, XQuery) • other languages via extensibility (including .NET) • Technology independent modelling and composition of service networks • Service dependencies • Resolution through wiring • Facilities for dynamic service configuration • Properties • Protocols • Qualities of service

43. Assembly Model Overview • Diagrams used to Represent SCA Artifacts

46. Assembly Model Composite • An SCA composite is used to assemble SCA elements in logical groupings. • Contains a set of components, services, references and the wires • Plus a set of properties which can be used to configure components • Composites may form component implementations in higher-level composites

47. Assembly Model Composite • Inclusion • A unit of deployment • Defined in an xxx.composite file • Represented by a composite element

48. A sample

49. Assembly Model Composite • Composite element has attributes: • name • Composites contain: zero or more • services • components • references • wires • included composites

50. Assembly Model Composite • component Components are configured instances of implementations. Components provide and consume services. Components are defined as subelements of a composite in an xxx.composite file.