1 / 103

Implementation of SOA

Implementation of SOA. Juanzi Li Department of Computer Science and Technology Tsinghua University March 2007. Outline. Programming Model SCA (Service Component Architecture) SDO (Service Data Object) Use Case (Simplified Bigbank). Programming Model. What?.

yama
Download Presentation

Implementation of SOA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

  44. 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

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

  46. A sample

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

  48. 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.

More Related