Service Component Architecture A reference architecture for SOA

Service Component Architecture “A reference architecture for SOA” Cadec 2006 Håkan Dahl, Johan Eltes Copyright 2006, Callista Enterprise AB

Agenda o The evolution of SOA infrastructure ù from SOAP to ESB o Service Component Architecture (SCA) ù Takes SOA from infrastructure to service modelling o SCA in practice ù Large-scale SOA within manufacturing o Tooling ù Demo of high-end SCA tooling (Web. Sphere Integration Developer) o Standardization ù Status of SCA standardization efforts o Conclusions ù Lego re-use and composition has finally arrived! Copyright 2006, Callista Enterprise AB

The Evolution of SOA infrastructure Dry and boring: Definition of a SOA and Service… o SOA is an architectural style of loose coupling among interacting software agents o …which requires… ù A small set of simple and ubiquitous interfaces to all participating software agents. • The interfaces should be universally available for all providers and consumers. ù Descriptive messages constrained by an extensible schema delivered through the interfaces • An extensible schema allows new versions of services to be introduced without breaking existing services Copyright 2006, Callista Enterprise AB

The Evolution of SOA infrastructure 2001: SOA is distributed computing… Distributed computing… Complexity Too complex Ideal Oversimplified 3270 screenscraping Time APPC Copyright 2006, Callista Enterprise AB ODBC CORBA SOAP 2005

The Evolution of SOA infrastructure 2001: SOAP (Simple Object Access Protocol) - The Holy Grail Describe Distribute XML C/S SOAP EAI Web Access Orchestrate Copyright 2006, Callista Enterprise AB

The Evolution of SOA infrastructure 2005: Web Services - Not so simple any more Distributed computing… Complexity Web Services Too complex Specmania. . SOAP + Ideal -WS-Security, -WS transaction, - WS-Authenication, - WS-Atachment, - WSRP, - WS-Addressing etc. Oversimplified 3270 screenscraping Time APPC Copyright 2006, Callista Enterprise AB ODBC CORBA SOAP 2005

The Evolution of SOA infrastructure 2005: Web Services - Not so simple any more… Copyright 2006, Callista Enterprise AB

The Evolution of SOA infrastructure SOA on Web. Services - Were would it take us? SOA Process A S s Domain Copyright 2006, Callista Enterprise AB A A s s Domain

The Evolution of SOA infrastructure The Enterprise Service Bus: SOA has learned from EAI (hub, mix of new and legacy protocols) S A S S A Enterprise Service Bus Color = Message Format (different XML schemas, legacy formats…) Shape = Protocol (FTP, JMS, Native MQSeries, SOAP…) Copyright 2006, Callista Enterprise AB

The Evolution of SOA infrastructure EAI Message Broker = Central Infrastructure ESB Architecture = Distributed infrastructure Copyright 2006, Callista Enterprise AB

The Evolution of SOA infrastructure ESB: Everything is a service - business functionality, formatting services, process orchestration… Application function FTP poller Message mapper S SAP adapter S Enterprise Service Bus Copyright 2006, Callista Enterprise AB S BPEL engine

The Evolution of SOA infrastructure Service characteristics o A service participates in a message exchange ù A service consumes ONE message and may return ONE message ù A service exports its functionality on a protocol • Not necessarily networked o A service is identified by a infrastructure-dependent endpoint URI ù With WSDL, A method name is part of the URI ù With queuing, the queue and eventually a message selector is the endpoint o A service MAY be aware of quality-of-service contracts ù Transaction scope ù Security Copyright 2006, Callista Enterprise AB

The Evolution of SOA infrastructure So, how does the new world of SOA look? o Application development and integration are two aspects of the same thing ù They depends on the same infrastructure ù The ESB infrastructure is a container for applications (as services) and integration glue (as services) o The ESB infrastructure supports transparent, distributed deployment ù Application services can execute anywhere ù Integration glue services can execute anywhere o Same tooling for application development and integration glue ù Some integration glue requires full-scale Java development ù Some application services are best realized through code generation from process models (e. g. BPEL) Copyright 2006, Callista Enterprise AB

The Evolution of SOA infrastructure ESB standardization JBI - Java Business Integration o JBI defines a container for service implementation containers and protocol bindings o May replace J 2 EE as SOA infrastructure standard o Limited support - All vendors implement an ESB, but differently Copyright 2006, Callista Enterprise AB

The Evolution of SOA infrastructure ESB - what are we missing? S S S Enterprise Service Bus Decommissioning of middleware Copyright 2006, Callista Enterprise AB Interoperate with new services through new protocols

The Evolution of SOA infrastructure The ESB is here. Where does that leave us? o Plumbing, plumbing… ù We have tooling and concepts to get interoperability across existing platforms and systems ù We know the platform and infrastructure landscape will continue to change o What would the next step be? ù To model, develop and compose services independent of SOA infrastructure ù What does it take to make the vision of “software Lego” become a reality? Copyright 2006, Callista Enterprise AB

>Service Component Architecture (SCA) o The evolution of SOA infrastructure ù from SOAP to ESB o Service Component Architecture (SCA) ù Takes SOA from infrastructure to service modelling o SCA in practice ù Large-scale SOA within manufacturing o Tooling ù Demo of high-end SCA tooling (Web. Sphere Integration Developer) o Standardization ù Status of SCA standardization efforts o Conclusions ù Lego re-use and composition has finally arrived! Copyright 2006, Callista Enterprise AB

Service Component Architecture (SCA) o SCA is a reference architecture for building a SOA, covering new development and integrating existing applications o Architectural style of recursive composition of services out of services into a SOA (-system) o …without building any assumptions of protocols or deployment topology into the service implementations o Dependency Injection is the implied mechanism for bridging the gap between SCA services and SOA infrastructure Copyright 2006, Callista Enterprise AB

SCA Core concepts Interface Copyright 2006, Callista Enterprise AB reference

> SCA in practice o The evolution of SOA infrastructure ù from SOAP to ESB o Service Component Architecture (SCA) ù Takes SOA from infrastructure to service modelling o SCA in practice ù Large-scale SOA within manufacturing o Tooling ù Demo of high-end SCA tooling (Web. Sphere Integration Developer) o Standardization ù Status of SCA standardization efforts o Conclusions ù Lego re-use and composition has finally arrived Copyright 2006, Callista Enterprise AB

Large-scale SCA within automotive o Mission ù Replace a large number of plant-specific systems (20 plants) with a common (global) portfolio of systems o Business case ù Disarm the legacy bomb ù Reduce cost of maintenance and operations ù Improve business agility and business process support o Business areas ù Part manufacturing ù Vehicle Assembly o System domains ù Material ordering ù Quality control ù Material Distribution ù Customer order slotting ù Production control ù Production planning ù Device communication Copyright 2006, Callista Enterprise AB Integration of Packaged Solutions New development

Architectural non-functional goals o Minimize impact on plant operations o Avoid redundant implementation of business logic o SOA without trading performance o Investment in business logic must sustain 20 years of technology evolution o Quality (automated server-side build, test, integration, deploy) o Support light-weight (low-cost) deployment (20 plants) ù Support deployment virtualization (run multiple plants in a single deployment) Copyright 2006, Callista Enterprise AB

Minimize impact on plant operations The system architecture need to be comprised of small, asynchronously integrated services. Only services that depends on a new feature should need to be stopped and re-installed. Xml schema upgrades must be possible without upgrading every consumer and provider of a service built on previous version of a schema. o SCA contributions ù Support for asynchronous service invocations (business events) ù Separation of service implementation and service modules ù Mediation service module may be introduced to resolve versioning issues o Gaps ù Versioning strategy for backwards / forwards compatibility of XML schemas / service interfaces. ù Binary versioning of service modules • Dependency management of versioned modules Copyright 2006, Callista Enterprise AB

Avoid redundant implementation of business logic Each piece of business logic should only be coded once. o SCA contribution ù Remote / service deployment not required for re-use ù A component can be wired into multiple modules ù A module can be wired into multiple subsystems o Gaps ù None identified Copyright 2006, Callista Enterprise AB

SOA without trading performance The goals of a SOA need to be achieved without depending on networked deployment of individual services. o SCA contribution ù Dependency injection allows service modules to be deployed “in process” within each consuming subsystem, instead of independent networked agents. o Gaps ù None identified Copyright 2006, Callista Enterprise AB

Investment in business logic should sustain 20 years of technology evolution Protocols, technologies, middleware has and will change over time. Minimal platform footprint: J 2 SE (->Java SE). Unlike. Net, J 2 SE has a proven track record of platform stability (backwards compatibility). Not a guarantee, but we need some platform. o SCA contribution ù Infrastructure abstractions through Dependency injection ù Standard simplifies container/vendor migration ù SCA itself *can* have zero footprint in business logic o Gaps ù SCA introduces APIs that may be tempting to use, which creates binding to SCA itself Copyright 2006, Callista Enterprise AB

Quality Upgrade deployment in with minimal impact on shop floor activities. High quality essential. Even with global maintenance team (change code you didn’t code your self) o SCA contribution ù Dependency injection makes component-, module- and subsystem test scripting efficient ù Lightweight infrastructure can be “injected” to minimize time for running tests (1000: ths of tests are run for each build) o Gaps ù Excuses need to be sought elsewhere… Copyright 2006, Callista Enterprise AB

Applied SCA best-practice o Corporate module repository o Business modules internally structured / wired in layers o Modules within a subsystem are wired at build-time o Subsystems (SOA services) within an SCA system are wired at- or after deploy-time via a system-internal ESB mediator o SCA systems are wired at- or after deploy time by connecting system-internal ESB: s o Integration object model (“business objects) represented as XML schemas, re-used in multiple WSDL files through “import” Copyright 2006, Callista Enterprise AB

Module repository o Corporate repository of versioned modules (jar files) ù Unit of re-use and version base-lining o Three types of modules: ù Business modules, binding modules and schema modules o Business modules ù Business logic ù Jar files with spring config files o Binding modules ù Protocol binding (WS, JMS etc), data binding (message payload -> java classes) and service activation (invoke referenced services in various business modules) ù WAR archives (for WS binding) and EJB-JAR archives (MDB: s for JMS binding) o Schema modules ù XML Schemas defining business objects ù Generated binding classes (we use JAXB - not SDO) ù (WID: “Library module”) Copyright 2006, Callista Enterprise AB

Module Repository example o The Maven build system is used to manage a repository of versioned binary modules including runtime dependencies between modules o Module names are unique across the business production_object_svc-2. 1. 0. jar production_object_ws-2. 1. 0. war production_object_svc-1. 5. 2. jar plantstructure_svc-1. 0. 1. jar process_equipment_event_svc-3. 0. 0. jar process_equipment_event_mdb-1. 0. 0. jar equipment_event_schema-1. 1. 0. jar Business module binding module schema module Copyright 2006, Callista Enterprise AB

Business module composition (Layered model) services Another business module Integration tier services (e. g. DAO: s) are local to module A business module Dependency injection (wiring) is conducted by the Spring framework. businessmodel persistence Copyright 2006, Callista Enterprise AB connservices Simplified migration to SCA spec, by standardizing on map able spring features.

Binding module composition o Publishes a service to the ESB ù Explicitly defines a networked coarsegrained service (in the sense of SOA) o Wiring of service components: ù Entry point binding (generic component per protocol) ù (Operation binding: WSDL -> Java stub) ù Data binding (generic component for JAXB) ù Service activator (custom component) o Binding module ù Listens to an ESB protocol ù Conducts data binding ù Invokes service activator o Archive depends on type of binding ù WS binding: WAR ù JMS binding: EJB-JAR with MDB: s only Copyright 2006, Callista Enterprise AB A binding module Entry point binding Data binding Operation binding* Service Activator * Only needed for WS binding

Binding module example - JMS entry point o Generic JMS binding A binding module Entry point binding Data binding Operation binding* Service Activator Properties: -retry. Policy -error. Destination Copyright 2006, Callista Enterprise AB

Binding module example - JAXB data binding o Data Binding service interfaces o Generic component (implementation) for JAXB ù Injected with generated JAXB-factory A binding module Entry point binding Data binding Operation binding* Service Activator Copyright 2006, Callista Enterprise AB

Binding module example - Service Activator o Custom Service. Activator component ù Processes inbound JAXB message ù Uses data from message to invoke wired business module services ù Declares transaction boundary (“requires new”) or uses User. Transaction to conduct “batch processing” A binding module Entry point binding Data binding Operation binding* Service Activator Service. Activator (from serviceactivator) process. Message(message : Object) : Object Copyright 2006, Callista Enterprise AB

Schema module o Models business object types ù XML schema Complex. Type ù E. g. Production order, Production Object Event o Used to compose messages ù Root element for JMS payload ù WSDL message for WS / SOAP (document/literal) o Applies versioning strategy ù Backwards- and forwards interface compatibility through the “any”strategy ù Schema + generated JAXB classes in versioned jar-file • E. g. production_object_schema-1. 1. 0. jar • Build system automatically generates JAXB classes and builds snapshot jar when schema file is updated o A schema of a schema module may import schemas from other schema modules ù Integrated into build system! Copyright 2006, Callista Enterprise AB

Example subsystem assembly System X Subsystem A Service activator defines unitof-work (JTA transaction). TX context propagates within a subsystem. A JMS binding module System X Subsystem B A schema module A business module Another schema module Copyright 2006, Callista Enterprise AB ESB with pub/sub mediation and protocol switching (JMS <-> WS)

Federation of systems o SOA domains are linked by connecting the ESB: s System X System Y Subsystem X. B Subsystem Y. C Subsystem X. A Copyright 2006, Callista Enterprise AB

> Tooling o The evolution of SOA infrastructure ù from SOAP to ESB o Service Component Architecture (SCA) ù Takes SOA from infrastructure to service modelling o SCA in practice ù Large-scale SOA within manufacturing o Tooling ù Demo of high-end SCA tooling (Web. Sphere Integration Developer) o Standardization ù Status of SCA standardization efforts o Conclusions ù Lego re-use and composition has finally arrived! Copyright 2006, Callista Enterprise AB

Why use SCA tooling ? Power of abstraction • hides complexity and implementation details • allows complex service composition • top-down or meet-in-the-middle model Service infrastructure • ”plumbing” components in toolbox • service runtime Copyright 2006, Callista Enterprise AB Orchestration support (BPEL)

Demo tooling Graphical design Web. Sphere Integration Developer 6. 0 (WID) deploy Runtime Web. Sphere Process Server 6. 0 (WPS) Upcoming open source tools: • Apache Tuscany (in incubator) • Eclipse SOA Tools Platform Copyright 2006, Callista Enterprise AB

Demo overview Product. Catalog. Module In. Out Web. Client. Order. Module Web. App Entry Point External Service Order. Module one. Way Focus on assembly! Copyright 2006, Callista Enterprise AB Product. Catalog Service Entry Point Order Service

Demo! Copyright 2006, Callista Enterprise AB

> Standardization o The evolution of SOA infrastructure ù from SOAP to ESB o Service Component Architecture (SCA) ù Takes SOA from infrastructure to service modelling o SCA in practice ù Large-scale SOA within manufacturing o Tooling ù Demo of high-end SCA tooling (Web. Sphere Integration Developer) o Standardization ù Status of SCA standardization efforts o Conclusions ù Lego re-use and composition has finally arrived! o SCA-get-started kit ù Jump-start your SCA-based reference architecture Copyright 2006, Callista Enterprise AB

SCA specification – ongoing work. . . o Specified by the leading vendors (IBM, BEA, Oracle, . . . ) ù architecture comes from top-of-the-line products ù builds on common core concepts ù tools available (WID/WPS early implementation) o Specification provides common model and API’s to support ù portability ù mix-and-match use of builders and runtimes o Currently: version 0. 9 for public review ù immature but shows direction o Implementation support: Java, BPEL, C++ and defines extension points Copyright 2006, Callista Enterprise AB

SCA spec - dependency injection @Remotable public interface My. Service { public void service. Method(String s); } public class My. Service. Impl implements My. Service { @Property private String config. Property; @Reference private Another. Service another. Service; public void service. Method(String s) { //. . . } } Copyright 2006, Callista Enterprise AB

SCA spec – assembly configuration Subsystem Deployment unit Module Entry Point Component sca. subsystem Copyright 2006, Callista Enterprise AB sca. module Component External Service <Impl. Name>. component. Type

SCA spec - bindings o <binding. sca/> ù not vendor interoperable ù might be implemented as EJB-remote binding o <binding. ws port=”http: //www. . . /Some. Service# wsdl. endpoint(Some. Service/Some. Service. SOAP)”/> o <binding. ejb/> ù stateless session EJB Copyright 2006, Callista Enterprise AB

SCA spec – asynch support o Asynch support ù callback to Java-interface ù for Web. Services: pass callback endpoint ù conversational Copyright 2006, Callista Enterprise AB

SCA spec - infrastructure capabilities o Declaratively assign as Policies [Proposal] ù Security ù Transactions ù Reliable messaging – property of the transport Copyright 2006, Callista Enterprise AB

> Conclusions o The evolution of SOA infrastructure ù from SOAP to ESB o Service Component Architecture (SCA) ù Takes SOA from infrastructure to service modelling o SCA in practice ù Large-scale SOA within manufacturing o Tooling ù Demo of high-end SCA tooling (Web. Sphere Integration Developer) o Standardization ù Status of SCA standardization efforts o Conclusions ù Lego re-use and composition has finally arrived! Copyright 2006, Callista Enterprise AB

Conclusions o Lego - At last! o SCA is the result of several maturing concepts merging into a sound, simple reference architecture o Shields our investment from the fast-paced infrastructure evolution ù Corba, RMI, JMS, EJB, JBI, SOAP, WS-* o SCA could provide value to. Net investments as well ù DCOM, . Net Remoting, Indigo… o Disclaimer: ù A usual, it needs a tuned context of modelling, CCM, test, build, project management, operations, service management…and…SOA infrastructure… Copyright 2006, Callista Enterprise AB

Core values o Isolates service implementations from the infrastructure that binds them together • Services, Components, References - not java calls, JMS, EJB, WS etc o Realizes the Lego vision of composing business services from reusable business modules • Recursive composition (Component m: m Module m: m Subsystem) o Unifies adapter, integration glue and core service development within a service single concept • Language bindings (BPEL, Java, C++, Interface Map, Rule Engine, Human Task) for component implementations. Component references Copyright 2006, Callista Enterprise AB

As a side-affect… SCA is bootstrapped from Dependency Injection and a set of structuring principles …so… The core architecture specified by SCA actually makes SCA itself pluggable (if you resist from using some shortcuts provided by the SCA Java language binding) Copyright 2006, Callista Enterprise AB

SCA get-started kit o Would you like to build on our experience? o Packaged SCA best-practice ù Introductory workshop ù Service modelling ù Business Object / Schema / WSDL management and Versioning strategy, internal versus external interface strategy ù Test automation / TDD integration ù SCA Build System set-up (binary version / dependency management) ù Change Control structure ù Reference application ù Training program o Open Source- or High-End tooling best-practice ù Guidelines for applying Spring in an SCA context ù Web. Sphere Process Server and WID Copyright 2006, Callista Enterprise AB