Reconfigurable Service-Oriented Architectures
Upcoming SlideShare
Loading in...5

Reconfigurable Service-Oriented Architectures






Total Views
Views on SlideShare
Embed Views



2 Embeds 7 6 1



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Reconfigurable Service-Oriented Architectures Reconfigurable Service-Oriented Architectures Presentation Transcript

  • 1 ReconfigurableService-OrientedSoftwareArchitecturesLionel SeinturierU. of Lille & IUFConstantine – Dec. 2011 1
  • 2 About me•  Pr. @ U. of Lille since 2006•  Institut Universitaire de France (IUF) – Junior member since oct. 2011 •  Associate professor at U. Paris 6 (1999 - 2006)•  Research domain & background •  Component, aspect and middleware –  Aspect-Oriented Software Development [Apress 2005, Eyrolles 2004] –  Dynamic AOP – JAC [Pawlak 02] –  Components & contracts [Legond-Aubry 05] –  Aspects & components – AOKell & FAC [Pessemier 07] –  Adaptation & software tracability [Diaz 07] –  Components for embedded systems – Hulotte [Loiret 08] –  Software architecture for soft realtime – SOLEIL [Plsek 09] –  Ubiquitous computing [Romero 09] –  Multi-cloud interoperability, energy awareness in middleware systems, reconfigurable MOM, feed-back control loops, adaptable business process, trace management 2
  • 3 ADAMAdaptive Distributed Application and MiddlewareADAM leader: Pr. Laurence Duchien, since 01/2007Previously Jacquard (Pr. J.-M. Geib) : 10/2003 – 12/2006Software engineering for middleware •  design approaches and languages •  runtime platformsSenior staff: 4 faculty (2 pr., 2 assoc. pr.), 1 Inria research assoc.1 post-doc, 12 PhD, 7 engineers 33
  • 4 Outline1. Service-Oriented Architecture – SOA2. Service Component Architecture – SCA3. OW2 FraSCAti4. Conclusion 4
  • Service-Oriented Architecture SOA 5
  • 6 From SOA challenges…•  IT architectures•  Complexity •  Managing 10n lines of code•  Monolithic •  Breaking application «silos»•  Seldom evolvable •  Freeing systems from immutable dependencies•  MDE, SOA, CBSE, AOSD, … Source: 6
  • 7 Decomposition of software 7
  • 8 SOA and SPL, FOD, MDE, CBSE, AOSD, ... 8
  • 9 Composition of software 9
  • 10 …to existing SOA, but…SOA leverages complexity and promotes flexibility •  Loose coupling •  Service composition and orchestration •  Well defined and contractualized interfaces •  Standard tools and technologies Source:! 10
  • 11 …Still a partial solutionTodays SOA need to be… •  Deployable in different environments •  Ensure security and reliability •  Adaptable to changing business needs…and thus, SOA lack… •  Structured architectures – What is behind the scene? •  Reuse capabilities – Reuse the wheel when possible… •  Flexibility support – …Or tune it if not! 11
  • 12 A definition of service•  A piece of software running somewhere•  A well defined business interface •  WSDL, WADL, OMG IDL, Java interface, …•  Available at a given address •  {host, port, …}, URL, IOR, naming, trading, …•  Interactions via a given communication protocol •  HTTP, REST, JSON-RPC, SOAP, UPnP, IIOP, Java RMI, JMS, … 12
  • 13 13
  • 14 SOAP API versus REST API 14
  • 15 Three challenges for SOA•  Interoperability •  Orchestrate services with heterogeneous protocols –  e.g., access REST Twitter user account then SOAP weather service –  BPEL orchestrates WSDL-based services only!•  Integration •  Compose heterogeneous piece of software to build a service –  e.g., compose a BPEL process, an OSGi bundle and a Xquery script –  CORBA composes OMG IDL-based software only!•  Dynamically reconfigurable runtime architectures •  research challenge #1 in Service foundations [Papazoglou 07] 15
  • Service Component Architecture SCA 16
  • 17 SCA in a nutshell"SCA (Service Component Architecture)" •  a component model for SOA" •  11/2005"Hosted by the Open SOA consortium" •"Standardized by OASIS" •""Platform providers" •  Open Source: Apache Tuscany, Newton, Fabric3, FraSCAti" •  Vendors: IBM WebSphere FP for SOA, TIBCO ActiveMatrix, Covansys SCA Framework, Paremus, Newton, Rogue Wave HydraSCA, Oracle Fusion Middleware" 17
  • 18 SCA in a nutshell"A set of specifications (16) (02/2010)"Assembly model" •  how to define structure of composite applications" •  extension for event processing and publish/subscribe"Component implementation specifications" •  how to write business services in particular languages" •  Java, C++, Spring, BPEL, EJB SLSB, COBOL, C"Binding specifications" •  how to access services" •  Web services, JMS, JCA, EJB"Policy framework" •  how to add infrastructure services" •  security, transaction, reliable messaging"Integration" •  SCA Java EE Integration" •  SCA OSGi/Spring (draft)"+ SDO for accessing data sources" 18
  • 19 SCA in a nutshellComponent implements thebusiness logicConcepts •  Service(s) – Interface type: Java , WSDL •  Reference(s) •  Property(s) •  Implementation •  Non functional property(s) – Intent & policy 19
  • 20 SCA in a nutshellAssembly: ”Process of composing business applications byconfiguring and connecting components that provide serviceimplementations” 20
  • 21 SCA in a nutshell RMI/IIOP AccountsComposite External Services External Binding Payment Payments Banking Order Entry Points Loosely coupled Service Component Reference Processing OrderProcessing Component Service Closely coupled Java EE Accounts LedgerSOAP/HTTP Multi-level Component BPEL composition Loosely coupled External Service WarehouseComposite External Warehouse Reference Entry Points Warehouse Warehouse Warehouse Mixed: - technologies Broker Service Component Wire Component JMS - app locations C++ Shipping Wire Reference External Service 21
  • 22 Simple SCA assembly Composite bank.account Reference StockQuoteService ComponentAccount AccountFacade Component AccountData [Mike Edwards] IBM Hursley Lab, England 22
  • 23 <composite xmlns="" name="bank.account" > <service name="Account" promote="AccountFacade"> < interface="services.account.Account"/> < port=" wsdl.endpoint(Account/AccountSOAP)"/> </service> <component name="AccountFacade"> < class="services.account.AccountFacadeImpl"/> <reference name="StockQuote"/> <reference name="AccountData" target="AccountData/Data"/> Composite bank.account <property name="currency">EURO</property> Reference StockQuote </component> Service Account Component AccountFacade Component AccountData <component name="AccountData"> <implementation.bpel process=“QName"/> <service name="Data"> < interface="services.account.Data"/> </service> </component> <reference name="StockQuote" promote="AccountFacade/StockQuote"> < interface="services.stockquote.StockQuote"/> < port=" wsdl.endpoint(StockQuote/StockQuoteSOAP)"/> </reference></composite> 23
  • 24 Java implementation example: Service Service Accountpackage services.account; Interface is available remotely, e.g. as a@Remotable Web Servicepublic interface Account { AccountReport getAccountReport(String customerID);} 24
  • 25 Java implementation example: Component Component AccountFacadepackage services.account;import*; Annotation for the service offered by@Service(interfaces = Account.class) this classpublic class AccountFacadeImpl implements Account { private String currency = "USD"; private Data accountDataService; Annotated private StockQuote stockQuoteService; Constructor to inject property public AccountServiceImpl( and references @Property("currency") String currency, @Reference("accountData") Data dataService, @Reference("stockQuote") StockQuote stockService) { this.currency = currency; this.accountDataService = dataService; this.stockQuoteService = stockService;} } 25
  • 26 Modelling with Eclipse SCA Tools 26
  • 27 SCA benefits Use Case Benefit of using SCA Standard •  Neutral to communication technologies SOA does not always mean WS •  Supports WS, JMS, JCA bindings •  Wires internal to SCA domain use proprietary technology •  Modeling and configuring QoS aspects is handled by the platform Bridging QoS Models of heterogeneous neutral SCA Assembly layer platforms • SCA defines QoS aspects in abstract terms ( intents ) and allows their mapping to individual platform environments •  SCA component implementations are programmed to interfaces Managing changes to service provider/ location •  Service endpoint information is not hardwired into client code •  Wiring of components is a first class concept with elaborate support for common scenarios (internal, external, redeployment) •  By providing a holistic view of the solution, it becomes possible for Support for testing, management management tools to capture service dependency information • Service testing tools can be more effectiveTolerance to new application runtimes and •  Framework for bindings to different technologies makes it possible for communication technologies developers to apply a consistent programming model 27
  • 28 SCA limitationsStatic configuration & deployment •  XML file for describing composite components •  Lack of deployment APINo runtime adaptation & reconfiguration •  Lack of introspection API •  Lack of reconfiguration APISCA is not a reflective componentmodel 28
  • FraSCAti 29
  • 30 Adaptability, reconfiguration, reflective systems•  SCA platform challenge•  dynamically reconfigurable runtime architectures research challenge #1 in Service foundations [Papazoglou 07]•  “A system which can examine and modify its own state is said to be reflective” •  Introspection corresponds to “examine” •  Intercession corresponds to “modify”•  FraSCAti brings reflection and reconfiguration to SCA 30
  • 31 FraSCAti in one slide•  A framework for SOA interoperability and integration•  A reflective SCA component model and framework •  Runtime adaptability •  Lightweight, efficient, predictable, scalable•  Components everywhere •  Adaptability of all software layers•  An open source SCA implementation •  LGPLv2 at 31
  • 32 Interoperability & integration with FraSCAti•  Interoperability is supported by SCA bindings •  (5) : Web Service / SOAP / WSDL via Apache CXF, JMS via OW2 JORAM, REST / WADL, JSON-RPC, UPnP, Java RMI•  Integration is mainly supported by SCA implementations •  (9) : SCA composite, Java POJO and @SCA, BPEL, Scala, Fractal, OSGi, scripts (BeanShell, Groovy, JavaScript, Jython, Jruby), Spring, Xquery •  HTTP servlet binding •  C interface/implementation/binding •  JMX 32
  • 33 FraSCAti and the SCA specifications FraSCAti SCA Specification Status ComponentSCA Assembly Model (v1.0) J J Assembly FactorySCA Policy Framework (v1.0) J / L Assembly FactorySCA Transaction Policy (v1.0) J Transaction IntentsSCA Java Common Annotations & APIs (v1.0) J J J TinfiSCA Java Component Implementation (v1.0) J J J TinfiSCA Web Services Binding (v1.0) J J J Binding Factory J = supported J / L = under development 33
  • 34 FraSCAti and the SCA specifications FraSCAti SCA Specification Status ComponentsSCA Spring Component Implementation J / L Plug-in Assembly Factory(v1.0)SCA BPEL Client & Implementation (v1.0) J Plug-in Assembly FactorySCA C++ Client & Implementation (v1.0) L L LSCA C Client & Implementation (v1.0) L L LSCA COBOL Client & Implementation (v1.0) L L LSCA JMS Binding (v1.0) J Plug-in Binding FactorySCA EJB Session Bean Binding (v1.0) L Plug-in Binding FactorySCA JCA Binding (v1.0) L Plug-in Binding FactorySCA Java EE Integration (v0.9) L 34
  • 35 FraSCAti principlesDesigned with adaptability/extensibility/flexibility in mind •  Software components [McIlroy 68] •  Reflection [Smith 82] •  Aspect-Oriented Programming (AOP) [Kiczales 97] •  Software Product Lines (SPL) [Pohl 05] •  Domain Specific Language (DSL)Component-based architecture to support protocols and implementations •  Communication protocols plugged within a binding factory •  Component implementation languages encapsulated as platform componentsReflection to enable introspection and reconfiguration •  Self-descriptive structure •  CRUD like operations for runtime discovery and modification 35
  • 36 FraSCAti principlesDesigned with adaptability/extensibility/flexibility in mindAOP-based mechanism to integrate non functional services •  Non-functional services developed as regular SCA components •  Non-functional policies dynamically woven into the base architecture •  So-called intents and poilicies in SCA jargonSPL-based design to handle variability in the different configurations •  Plug-in mechanism to select featuresDSL for reconfiguration •  Syntactic sugar for a low level reconfiguration API •  At various levels: applicationFractal-based runtime substrate (cf. •  Dynamic reconfiguration capabilities •  Java 5 @-based development style (dependency injection) •  XML-based architecture descriptors •  Structuring concepts (component personality, membrane, control interface, etc.) 36
  • 37 FraSCAti architecture Application Level Application DSL for View Model reconfiguration @intent and policy sets everywhere @intent and policy sets Non functional services Logging Security Service Service Transaction Service AOP ... Non-functional LevelComponent assemble components DescriptionReflection Platform Assembly Parser Factory SPLeverywhere Personality Factory Run-time Level Framework «interface» Component +getFcInterface(in name) : Object +getFcInterfaces() : Object[] +getFcType() : Type Fractal Component Kernel Level 37
  • 38 FraSCAti and SPL FraSCAti SCA Metamodel Parser Assembly Composite SCA SCA Metamodel Resolver Description Parser Property XSD XSD Factory Tinfi Tinfi Tinfi Personality Factory Implementation Spring Spring Spring Component BPEL Spring Spring Spring Service BPEL Binding Spring Spring Spring BPEL Spring Reference WSDL Spring Interface WSDL Spring WSDL SOAP Assembly FactoryRun-time 38
  • 39 FraSCAti and SPLA la carte configuration•  256KB FraSCAti reflective kernel –  API + membrane controllers•  500KB + mininal FraSCAti architecture•  2.4MB + minimal FraSCAti architecture –  Around 2MB for EMF & SCA MM•  2.9MB + membrane generation on the fly –  Using JDK6 compiler•  6.9MB + Eclipse Java compiler (JDT) –  Around 4MB for JDT•  … + the FraSCAti features you need•  40MB All FraSCAti 1.3 features 39
  • 40 FraSCAti and AOP•  Non functional concerns as shared & reflective FraSCAti composites•  AOP for crosscutting concerns 40
  • 41 FraSCAti and DSLSimple reconfiguration scenario 41
  • 42 FraSCAti and DSLFscript/Fpath language composite = $domain/scachild::MyComposite; account = $composite/scachild::AccountFacade; accountRef = $account/scareference::AccountData; stop($account); // (1) unwire($accountRef); // (2) newAccountData = sca-new(«NewAccountDataServiceComponent»); // (3a) add($composite, $newAccountData); // (3b) wire($accountRef, $newAccountData/scaservice::Data); // (4) start($account); // (5) 42
  • 43 FraSCAti usages•  Open-source OW2 consortium project •  LGPL licence,•  Embedded by the Petals Link and Open Wide compagnies for their products (PEtALS, EasyBPEL and SCARBO)•  Several demonstrators and applications developed with industrial partners in the context of funded research projects 43
  • 44 FraSCAti demonstratorsArtenum: Service-oriented scientific computing(Computing On Demand)Defining SCA-basedinteroperable scientific components 44
  • 45 FraSCAti demonstratorsInria: New generation source forge •  Service-oriented components for content management, continuous build, release management… 45
  • 46 FraSCAti demonstratorsEdifixio: e-Business integration with SCA 46
  • 47 FraSCAti demonstratorsEdifixio 47
  • 48 FraSCAti demonstratorsThales: Network monitoring Java Swing Inventory Visualization Discovery Monitoring VNUML Virtualized Network 48
  • 49 FraSCAti demonstratorsAutonomous home control system Movement Sensor HOME ZigBee SOAP UPnP Module Store Set-Top-Box TV HTTP HTTP UPnP RMI Smart Phone Multimedia Server
  • 50 FraSCAti demonstrators Home Control System STB Device RPC (SOAP) Reconfiguration Module Store Rule Engine Adaptation Runtime push push push Executor Adaptation (SPACES) (SPACES) Triggering push push push push push push push push push (SPACES) Context Movement REST Processing Sensor Reconfiguration (HTTP) SCA Platform (SPACES) push push Engine (FraSCAti) push push (FScript) REST(XMPP) Multimedia RPC (RMI) RPC (UPnP) UPnP TV Server RPC (UPnP) Provider Content push Server Runtime Multimedia Provider push Mobile push push Remote Control Device Context Reconfiguration SCA Module Policy View Engine Platform Controller (SPACES) (FScript) (FraSCAti) Multimedia Client-side Modulepush Application Mobile Runtime push Context Reconfiguration SCA Platform Policy push push REST (XMPP) Engine (FScript) (FraSCAme) (SPACES) A B SCA service SCA wire (local) push asynchronous context push SCA reference SCA binding (remote) pull (a)synchronous context pull Third-party provider SCA component SCA composite 50
  • 51 FraSCAti demonstratorsTool demo @ [ASE 2010]•  Home environment •  Heterogeneous devices/technologies/ protocols•  UPnP communications •  From Android to FraSCAti services•  Highlight FraSCAti reconfiguration capabilities 51
  • 52 FraSCAti and multi-cloud computing 52
  • 53 FraSCAti Vs.L Less SCA features supported •  Less implementation languages and binding protocolsL Smaller ecosystem •  Less sponsoring companies, developers, and usersJ Better continuum from SCA tooling to runtime platform •  Share the same SCA metamodel with Eclipse SCA ToolsJ Better footprint to target embedded systems •  Smaller disk and memory footprintsJ Ready for dynamic runtime reconfiguration •  Based on OW2 Fractal component model and associated tools 53
  • 54 Memory consumption 54
  • 55 Invocation time 55
  • 56 Other OSS Competitors•  Fabric3 L/J Fork from the Apache Tuscany project L Developed by fewer contributors•  The Newton Project J Distributed runtime framework based on OSGi, Jini, and SCA J SCA bindings for OSGi and Jini L Does not target a fully-compliant SCA framework L No support for SCA Java annotations L No Web Service binding•  The Mule Project - MuleSCA activity J Some Web pages L No open source code currently available 56
  • Conclusion 57
  • 58 What you should keep in mind about•  A framework for SOA interoperability and integration •  A middleware of middleware•  A reflective component model for SOA •  FraSCAti = SCA + Fractal + FAC + ACO + CBM•  Used at any software level •  SOA applications •  FraSCAti platform and its plugins •  Non functional crosscutting concerns, aka SCA intents •  Component-based reflective membranes •  New middleware, e.g., EasyBPEL/EasyViper•  Visit the FraSCAti Web site:•  Read [SCC’09] and [SPE’11] 58
  • 59 FraSCAti research perspectives•  FraSCAti as a Software Product Line (SPL)•  A component-based programming language for dynamic SOA•  Real-time systems •  OMG Data Distribution Service (DDS)•  Event-based systems•  Embedded systems•  Autonomous systems•  E-green systems•  Home clouds•  Large scale SOA & Cloud Computing 59
  • 60 Thank you for your attentionVisit http://frascati.ow2.orgContact •  Lionel Seinturier: 60
  • 61 SCA referencesSCA Specifications •  OpenSOA •  OASIS OpenSCA http://www.oasis-opencsa.orgOSS Implementations •  Tuscany •  Newton •  Fabric3 •  FraSCAti http://frascati.ow2.orgSCA Resources • • • • 0509_brent.html • Flexible_Agile_Composition_01.ppt [Mike Edwards] • Power_Combination_SCA_Spring_OSGi.pdf?version=3 61
  • 62 Acknowledgements•  Slides from •  Philippe Merle – Inria •  Romain Rouvoy – U. of Lille •  Rémi Melisson – Orange Labs & U. of Lille•  All FraSCAti team members & contributors •  Christophe Demarey, Michel Dirix, Nicolas Dolet, Damiel Fournier, Nicolas Petitprez, Valerio Schiavoni, Guillaume Surrel •  Mahmoud Ben Hassine, Pierre Carton, Jonathan Labejof, Adel Noureddine, Russel Nzekwa, Nicolas Pessemier, Clément Quinton, Daniel Romero •  … 62