OpenCSA Member Section – Service Component Architecture 1 1 SCA Overview Sanjay Patil – SAP Mike Edwards - IBM

OpenCSA Member Section – Service Component Architecture 2 2 Agenda n A little history n SCA and SOA n SCA scenarios n SCA specifications n OASIS SCA TCs l major challenges n Related & future work

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

OpenCSA Member Section – Service Component Architecture 4 4

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

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

OpenCSA Member Section – Service Component Architecture 7 7 Agenda n A little history n SCA and SOA n SCA scenarios n SCA specifications n OASIS SCA TCs l major challenges n Related & future work

OpenCSA Member Section – Service Component Architecture 8 8 SOA Programming Model (1) n SOA Programming Model derives from the basic concept of a service: n A service is an abstraction that encapsulates a software function. n Developers build services, use services and develop solutions that aggregate services. n Composition of services into integrated solutions is a key activity

OpenCSA Member Section – Service Component Architecture 9 9 SOA Programming Model (2) n Core Elements: l Service Assembly technology- and language- independent representation of composition of services l Service Components technology- and language-independent representation of composable service implementation l Service Data Objects technology- and language-Independent representation of service data entity

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

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

OpenCSA Member Section – Service Component Architecture 12 OpenCSA Member Section – Service Component Architecture 12 Key benefits of SCA n Loose Coupling : components integrate without need to know how others are implemented n Flexibility : c omponents can easily be replaced by other components n Services can be easily invoked either synchronously or asynchronously n Composition of solutions: clearly described n Productivity: easier to integrate components to form composite application n Heterogeneity: multiple implementation languages, communication mechanisms n Declarative application of infrastructure services n Simplification for all developers, integrators and application deployers

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

OpenCSA Member Section – Service Component Architecture 14 OpenCSA Member Section – Service Component Architecture 14 Agenda n A little history n SCA and SOA n SCA scenarios n SCA specifications n OASIS SCA TCs l major challenges n Related & future work

OpenCSA Member Section – Service Component Architecture 15 OpenCSA Member Section – Service Component Architecture 15 Bottom-up Composition Select a set of existing component implementations for building the new composite services references properties Configure the component properties Hand off the composite to Deployer Composite Draw internal wires properties Wrap the components in a composite and configure external services/references

OpenCSA Member Section – Service Component Architecture 16 OpenCSA Member Section – Service Component Architecture 16 Top-down Composition Start with gathering requirements for the top-level composite Define the services/references and properties for the composite Composite Service Ref Properties 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 Ref

OpenCSA Member Section – Service Component Architecture 17 OpenCSA Member Section – Service Component Architecture 17 Heterogeneous Assembly Components in the same composite share a common context for many aspects such as installation, deployment, security settings, logging behavior, etc. Java BPEL Legacy PHP C++

OpenCSA Member Section – Service Component Architecture 18 OpenCSA Member Section – Service Component Architecture 18 Implementation Reuse – By Configuration Select an existing component implementation 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. Component …… Services References Properties Implementation - Java - BPEL - Composite Deploy the component implementation - Multiple instances of the same implementation may be running simultaneously

OpenCSA Member Section – Service Component Architecture 19 OpenCSA Member Section – Service Component Architecture 19 Deployment Flexibility Services References Properties SOAP/HTTP WS Binding JMS Binding JCA Binding WS Clients WS Clients JMS Clients JMS Clients ERP Service ERP Service Deployer chooses and configures communication mechanisms for services/references without having to modify the component implementation

OpenCSA Member Section – Service Component Architecture 20 OpenCSA Member Section – Service Component Architecture 20 Abstract policy decleration 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 Repository Registry SCA policySets Developer SCA Runtime Deployer SCA Assembly 1 2 SCA Assembly Policy Administrator

OpenCSA Member Section – Service Component Architecture 21 OpenCSA Member Section – Service Component Architecture 21 Agenda n A little history n SCA and SOA n SCA scenarios n SCA specifications n OASIS SCA TCs l major challenges n Related & future work

OpenCSA Member Section – Service Component Architecture 22 OpenCSA Member Section – Service Component Architecture 22 SCA Technology How do I define, configure and assemble components to create composites?  SCA Assembly Spec SOAP/ HTTP 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, … How do I define, use and administer policies for non- functional aspects (QoS, etc)?  SCA Policy Framework Spec Composite Component

OpenCSA Member Section – Service Component Architecture 23 OpenCSA Member Section – Service Component Architecture 23 The SCA Specifications Assembly Implementation Languages Policy FrameworkBindings JavaJEE Spring C++ BPEL Security RM Transactions Web services JMS JCA

OpenCSA Member Section – Service Component Architecture 24 OpenCSA Member Section – Service Component Architecture 24 Agenda n A little history n SCA and SOA n SCA scenarios n SCA specifications n OASIS SCA TCs l major challenges n Related & future work

OpenCSA Member Section – Service Component Architecture 25 OpenCSA Member Section – Service Component Architecture 25 OASIS SCA Technical Committees n OpenSCA Member Section l SCA Assembly TC l SCA Bindings TC l SCA Policy TC l SCA J TC l SCA C-C++ TC l SCA BPEL

OpenCSA Member Section – Service Component Architecture 26 OpenCSA Member Section – Service Component Architecture 26 Work of the SCA TCs n Produce OASIS standard versions of SCA specifications l conformance statements l mandatory vs optional l portability, interoperability n Test suites l define test suites to check conformance

OpenCSA Member Section – Service Component Architecture 27 OpenCSA Member Section – Service Component Architecture 27 Challenges n What is a good test suite for SCA? n Coordination between TCs

OpenCSA Member Section – Service Component Architecture 28 OpenCSA Member Section – Service Component Architecture 28 Agenda n A little history n SCA and SOA n SCA scenarios n SCA specifications n OASIS SCA TCs l major challenges n Related & future work

OpenCSA Member Section – Service Component Architecture 29 OpenCSA Member Section – Service Component Architecture 29 Possible Future work n C specification n COBOL specification n REST binding(s) l JSON, ATOM,…

OpenCSA Member Section – Service Component Architecture 30 OpenCSA Member Section – Service Component Architecture 30 Related Work n OASIS SDD n Management l WSDM, SML, … n WS-* specifications n OASIS SOA RM l other RM’s

OpenCSA Member Section – Service Component Architecture 31 OpenCSA Member Section – Service Component Architecture 31 Summary n OASIS SCA l an exciting challenge l major effort over the next year l aim to appeal to a very wide audience n 6 SCA TCs to run & coordinate!

OpenCSA Member Section – Service Component Architecture 32 OpenCSA Member Section – Service Component Architecture 32 Useful links… n OASIS Open CSA n OASIS SCA Technical Committees n Open SOA Collaboration n V1 level of SCA specs found here: n Useful papers and interesting SCA information: n OASIS Webinar downloads: