1 / 29

SCA Overview

www.oasis-open.org. SCA Overview. Sanjay Patil – SAP Mike Edwards - IBM. Agenda. A little history SCA and SOA SCA scenarios SCA specifications OASIS SCA TCs major challenges Related & future work. A little history.

kagami
Download Presentation

SCA Overview

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. www.oasis-open.org SCA Overview Sanjay Patil – SAP Mike Edwards - IBM

  2. Agenda • A little history • SCA and SOA • SCA scenarios • SCA specifications • OASIS SCA TCs • major challenges • Related & future work

  3. A little history • “…once upon a time, some programmers thought it would be good to have a programming model to support Service Oriented Architecture…” • That model is SCA • Industry collaboration grew from just 2 companies to 18 today • published 1.0 SCA specifications, March 2007 • SCA specifications now ready for standardization in OASIS

  4. Other Standards Bodies 2007 + 1Q07 2Q07 2Q06 4Q04 Time Line Summary 3Q05 Finalization of further SCA Specs Further complementary incubation SCA V0.95 SCA V1.0 SCA V0.9 SDO V1 SDO V2.01 SDO V2 SDO V2.1 Nov 2005 July 2006 Press Announcementof Project Launch New Partners Announced March 2007 SDO TC Specs 1.0 Submission for Standardization SCA TC’s Early Adopters System Vendors Adoption ISVs Customer Value

  5. Standardization • OASIS to guide the standardization of Specifications from the collaboration in the OpenCSA Member Section • Member Section Structure • 6 Technical Committees (TCs) to address one or more Specifications from the collaboration • SDO V2.1 for Java will be completed in the JCP as JSR235 • Specification development to continue within OSOA collaboration for technologies not yet ready for standardization

  6. Agenda • A little history • SCA and SOA • SCA scenarios • SCA specifications • OASIS SCA TCs • major challenges • Related & future work

  7. What are SCA and SDO? • Service Component Architecture • an executable model for building service-oriented applications as composed networks of service components • “how to build composite service applications” • Service Data Objects • a unified model for the handling of (service) data irrespective of its source or target • “how to handle data in a services environment”

  8. Service Component Architecture (SCA): Simplified Programming Model for SOA • model for: • building service components • assembling components into applications • deploying to (distributed) runtime environments • Service components built fromnew or existing code using SOA principles • vendor-neutral– supported across the industry • language-neutral– components written using any language • technology-neutral– use any communication protocols and infrastructure to link components

  9. Key benefits of SCA • Loose Coupling: components integrate without need to know how others are implemented • Flexibility: components can easily be replaced by other components • Servicescan be easily invoked either synchronously or asynchronously • Compositionof solutions: clearly described • Productivity: easier to integrate components to form composite application • Heterogeneity: multiple implementation languages, communication mechanisms • Declarativeapplication of infrastructure services • Simplification for all developers, integrators and application deployers

  10. SCA assembly RMI/IIOP AccountsComposite External Banking Reference Payments Component Payment Service OrderProcessing Component Order Processing Service Java EE Accounts Ledger Component BPEL SOAP/HTTP Multi-level composition WarehouseComposite External Warehouse Reference Warehouse Broker Component Mixed: - technologies - app locations Warehouse Component Warehouse Service JMS Shipping Reference C++

  11. Agenda • A little history • SCA and SOA • SCA scenarios • SCA specifications • OASIS SCA TCs • major challenges • Related & future work

  12. Bottom-up Composition Select a set of existing component implementations for building the new composite Configure the component properties Composite Draw internal wires properties properties Wrap the components in a composite and configure external services/references Hand off the composite to Deployer services references

  13. Properties Composite Top-down Composition Ref Start with gathering requirements for the top-level composite Service Ref Define the services/references and properties for the composite Break down the composite into individual components and wires between them Recursively break down each component Hand off the individual component contracts to developers for implementation

  14. Heterogeneous Assembly PHP BPEL Java C++ Legacy • Components in the same composite share a common context for many aspects such as installation, deployment, security settings, logging behavior, etc.

  15. Implementation Reuse – By Configuration Select an existing component implementation Properties • Configure its behavior (via setting props, refs) to match the current requirements • E.g. Configure multiple instances of product pricing component, each with different currency, tax rate, discount charts, etc. Services … … References Component • Deploy the component implementation • - Multiple instances of the same implementation may be running simultaneously Implementation - Java - BPEL - Composite

  16. Deployment Flexibility Deployer chooses and configures communication mechanisms for services/references without having to modify the component implementation WS Clients SOAP/HTTP WS Binding Properties References Services ERP Service JMS Clients JMS Binding JCA Binding

  17. Abstract policy decleration Developer Deployer SCA Assembly SCA Assembly 2 1 Policy Administrator 3 4 5 Repository 0 SCA Runtime SCA policySets Registry 0. Policy Administrator authors SCA policySets with concrete policies 1. Developer specifies intents on SCA assembly 2. Developer hands over SCA assembly to Deployer 3. Deployer configures SCA assembly by assigning SCA policySets (could be automated) 4. Deployer deploys configured SCA Assembly to SCA Runtime 5. Deployer updates Registry

  18. Agenda • A little history • SCA and SOA • SCA scenarios • SCA specifications • OASIS SCA TCs • major challenges • Related & future work

  19. SCA Technology How do I define, use and administer policies for non-functional aspects (QoS, etc)?  SCA Policy Framework Spec How do I define, configure and assemble components to create composites?  SCA Assembly Spec Composite SOAP/ HTTP Component JMS JCA How do I develop SCA components in BPEL? Or in Java? Or C++, PHP,…  SCA BPEL Client & Impl Spec, … How do I configure SCA services/references to use SOAP/HTTP or JMS or JCA, … SCA WS Binding Spec, …

  20. The SCA Specifications Assembly Policy Framework Implementation Languages Bindings Security Java JEE Web services RM Spring BPEL JMS Transactions C++ JCA

  21. Agenda • A little history • SCA and SOA • SCA scenarios • SCA specifications • OASIS SCA TCs • major challenges • Related & future work

  22. OASIS SCA Technical Committees • OpenSCA Member Section • SCA Assembly TC • SCA Bindings TC • SCA Policy TC • SCA J TC • SCA C-C++ TC • SCA BPEL

  23. Work of the SCA TCs • Produce OASIS standard versions of SCA specifications • conformance statements • mandatory vs optional • portability, interoperability • Test suites • define test suites to check conformance

  24. Challenges • What is a good test suite for SCA? • Coordination between TCs

  25. Agenda • A little history • SCA and SOA • SCA scenarios • SCA specifications • OASIS SCA TCs • major challenges • Related & future work

  26. Possible Future work • C specification • COBOL specification • REST binding(s) • JSON, ATOM,…

  27. Related Work • OASIS SDD • Management • WSDM, SML, … • WS-* specifications • OASIS SOA RM • other RM’s

  28. Summary • OASIS SCA • an exciting challenge • major effort over the next year • aim to appeal to a very wide audience • 6 SCA TCs to run & coordinate!

More Related