reconfigurable service-oriented architectures

1

Reconfigurable Service-Oriented Software Architectures Lionel Seinturier U. of Lille & IUF Constantine – 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

ADAM

Adaptive Distributed Application and Middleware

ADAM leader: Pr. Laurence Duchien, since 01/2007

Previously Jacquard (Pr. J.-M. Geib) : 10/2003 – 12/2006

Software engineering for middleware •  design approaches and languages •  runtime platforms

Senior staff: 4 faculty (2 pr., 2 assoc. pr.), 1 Inria research assoc.

1 post-doc, 12 PhD, 7 engineers

3 3

4

Outline

1. Service-Oriented Architecture – SOA

2. Service Component Architecture – SCA

3. OW2 FraSCAti

4. 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: oasis-open.org

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: oasis-open.org!

10

11

…Still a partial solution Today's 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"•  http://www.osoa.org"

Standardized by OASIS"•  http://www.oasis-opencsa.org"

"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 nutshell

Component implements the business logic Concepts •  Service(s)

– Interface type: Java , WSDL •  Reference(s) •  Property(s) •  Implementation •  Non functional property(s)

– Intent & policy

19

20

SCA in a nutshell

Assembly: ”Process of composing business applications by configuring and connecting components that provide service implementations”

20

21

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

BPEL

Java EE

C++

SOAP/HTTP

JMS

RMI/IIOP

Mixed: - technologies - app locations

Multi-level composition

SCA in a nutshell

Loosely coupled

Loosely coupled

Closely coupled

Entry Points

Entry Points

External Service

External Service

External Services Binding

Wire

Wire

21

22

Simple SCA assembly

[Mike Edwards] IBM Hursley Lab, England

Composite bank.account

Component AccountData

Component AccountFacade

Service Account

Reference StockQuote

22

23

Composite bank.account

Component AccountData


Service Account

Reference StockQuote

<reference name="StockQuote" promote="AccountFacade/StockQuote"> <interface.java interface="services.stockquote.StockQuote"/> <binding.ws port="http://example.org/StockQuote# wsdl.endpoint(StockQuote/StockQuoteSOAP)"/> </reference>

<service name="Account" promote="AccountFacade"> <interface.java interface="services.account.Account"/> <binding.ws port="http://www.example.org/Account# wsdl.endpoint(Account/AccountSOAP)"/> </service>

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="bank.account" > </composite>

<component name="AccountFacade"> <implementation.java class="services.account.AccountFacadeImpl"/> <reference name="StockQuote"/> <reference name="AccountData" target="AccountData/Data"/> <property name="currency">EURO</property> </component>

<component name="AccountData"> <implementation.bpel process=“QName"/> <service name="Data"> <interface.java interface="services.account.Data"/> </service> </component>

23

24

package services.account; @Remotable public interface Account { AccountReport getAccountReport(String customerID); }

Interface is available remotely, e.g. as a Web Service

Java implementation example: Service Service Account

24

25

Java implementation example: Component

package services.account; import org.osoa.sca.annotations.*; @Service(interfaces = Account.class) public class AccountFacadeImpl implements Account { private String currency = "USD"; private Data accountDataService; private StockQuote stockQuoteService; public AccountServiceImpl( @Property("currency") String currency, @Reference("accountData") Data dataService, @Reference("stockQuote") StockQuote stockService) { this.currency = currency; this.accountDataService = dataService; this.stockQuoteService = stockService; } }

Annotation for the service offered by this class

Annotated Constructor to inject property and references


25

26

Modelling with Eclipse SCA Tools

26

27

SCA benefits

Use Case Benefit of using SCA Standard

SOA does not always mean WS •  Neutral to communication technologies •  Supports WS, JMS, JCA bindings •  Wires internal to SCA domain use proprietary technology

Bridging QoS Models of heterogeneous platforms

•  Modeling and configuring QoS aspects is handled by the platform neutral SCA Assembly layer • SCA defines QoS aspects in abstract terms (‘intents’) and allows their mapping to individual platform environments

Managing changes to service provider/location

•  SCA component implementations are programmed to interfaces •  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)

Support for testing, management •  By providing a holistic view of the solution, it becomes possible for management tools to capture service dependency information • Service testing tools can be more effective

Tolerance to new application runtimes and communication technologies

•  Framework for bindings to different technologies makes it possible for developers to apply a consistent programming model

27

28

SCA limitations

Static configuration & deployment • XML file for describing composite components •  Lack of deployment API

No runtime adaptation & reconfiguration •  Lack of introspection API •  Lack of reconfiguration API

SCA is not a reflective component model

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 http://frascati.ow2.org

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

SCA Specification FraSCAti

Status Component SCA Assembly Model (v1.0) J J Assembly Factory

SCA Policy Framework (v1.0) J / L Assembly Factory

SCA Transaction Policy (v1.0) J Transaction Intents

SCA Java Common Annotations & APIs (v1.0) J J J Tinfi

SCA Java Component Implementation (v1.0) J J J Tinfi

SCA Web Services Binding (v1.0) J J J Binding Factory

J = supported J / L = under development

33

34

FraSCAti and the SCA specifications

SCA Specification FraSCAti

Status Components SCA Spring Component Implementation (v1.0)

J / L Plug-in Assembly Factory

SCA BPEL Client & Implementation (v1.0) J Plug-in Assembly Factory SCA 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 Factory SCA EJB Session Bean Binding (v1.0) L Plug-in Binding Factory SCA JCA Binding (v1.0) L Plug-in Binding Factory SCA Java EE Integration (v0.9) L

34

35

FraSCAti principles Designed 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

components

Reflection to enable introspection and reconfiguration •  Self-descriptive structure •  CRUD like operations for runtime discovery and modification

35

36

FraSCAti principles Designed with adaptability/extensibility/flexibility in mind

AOP-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 jargon

SPL-based design to handle variability in the different configurations •  Plug-in mechanism to select features

DSL for reconfiguration •  Syntactic sugar for a low level reconfiguration API •  At various levels: application

Fractal-based runtime substrate (cf. http://fractal.ow2.org) •  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

37

Run-time Level

assemblecomponents

Application Level

ViewModel

Non-functional Level...

LoggingService Transaction

ServiceSecurityService

@intent and policy sets

@intentand policy sets

Kernel Level

Component

+getFcInterface(in name) : Object+getFcInterfaces() : Object[]+getFcType() : Type

«interface»Component

DescriptionParserAssembly

Factory Personality Factory

App

licat

ion

Plat

form

Non

func

tiona

lse

rvic

esFr

amew

ork

Component Reflection everywhere

AOP

SPL

DSL for reconfiguration everywhere

Fractal

38

FraSCAti and SPL

Run-timeAssembly Factory

Description Parser

SCAParser

SCA Metamodel

FraSCAti Metamodel

Composite

Component

Assembly

Service

Reference

Property

Interface

XSDXSD

Implementation

WSDLWSDL

WSDL

SpringSpringSpring

BPELSpringSpringSpring

BPEL

SCAResolver

Personality Factory

Factory TinfiTinfi

Tinfi

Binding

SpringSpring

SpringBPELSpring

SpringSpring

SOAP

38

39

FraSCAti and SPL A 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 DSL

41

Simple reconfiguration scenario

42

FraSCAti and DSL

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

Fscript/Fpath language

43

FraSCAti usages

•  Open-source OW2 consortium project •  LGPL licence, http://frascati.ow2.org

•  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 demonstrators

Artenum: Service-oriented scientific computing (Computing On Demand)

Defining SCA-based

interoperable scientific components

44

45

FraSCAti demonstrators Inria: New generation source forge

•  Service-oriented components for content management, continuous build, release management…

45

46


Edifixio: e-Business integration with SCA

46

47


Edifixio

47

48


Thales: Network monitoring

Discovery

Inventory Java Swing

VNUML Virtualized Network

Visualization

Monitoring

48

49


UPnP

RMI

UPnP

HTTP

Smart PhoneMultimedia Server

TV

HOME

Set-Top-Box

HTTP

Module Store

ZigBee

SOAP

Movement Sensor

49

Autonomous home control system

50


REST

(XMPP)

REST (XMPP)

MultimediaServer

Server Runtime

SCAPlatform

(FraSCAti)

ContextPolicy

(SPACES)

push

Multimedia Provider

Reconfiguration Engine

(FScript)push

Provider Content

push

push

Module Store

MovementSensor

UPnP TVRPC (UPnP)

REST

(HTTP)

MobileDevice

MobileRuntime

SCA Platform(FraSCAme)

ContextPolicy

(SPACES)

push

Client-sideApplication

ReconfigurationEngine (FScript)

push

ViewController

push

push

Remote Control Module

MultimediaModule

push asynchronous context push

pull (a)synchronous context pull

SCA wire (local)

SCA binding (remote)

SCA service

SCA reference

A

SCA component

B

SCA compositeThird-party provider

STB Device

Adaptation Runtime

Home Control System

ContextProcessing(SPACES)

push

push

SCA Platform(FraSCAti)

Reconfiguration Engine

(FScript)

AdaptationTriggering(SPACES) push pushpush

Rule Engine(SPACES)

push

ReconfigurationExecutor(SPACES)

pushpush

push

push

push

push

push

push

push push

RPC (SOAP)

RPC (RMI)

RPC (UPnP)

50

51


51

Tool demo @ [ASE 2010] •  Home environment •  Heterogeneous

devices/technologies/protocols

•  UPnP communications •  From Android to

FraSCAti services

•  Highlight FraSCAti reconfiguration capabilities

52

FraSCAti and multi-cloud computing

52

53

FraSCAti Vs.

L Less SCA features supported •  Less implementation languages and binding protocols

L Smaller ecosystem •  Less sponsoring companies, developers, and users

J Better continuum from SCA tooling to runtime platform •  Share the same SCA metamodel with Eclipse SCA Tools

J Better footprint to target embedded systems •  Smaller disk and memory footprints

J 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: http://frascati.ow2.org •  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 attention Visit http://frascati.ow2.org Contact •  Lionel Seinturier: [email protected]

60

61

SCA references

SCA Specifications •  OpenSOA http://www.osoa.org •  OASIS OpenSCA http://www.oasis-opencsa.org

OSS Implementations •  Tuscany http://tuscany.apache.org •  Newton http://newton.codecauldron.org/site/index.html •  Fabric3 http://xircles.codehaus.org/projects/fabric3 •  FraSCAti http://frascati.ow2.org

SCA Resources •  http://www.osoa.org/display/Main/SCA+Resources •  http://www-128.ibm.com/developerworks/library/specification/ws-sca •  http://www.davidchappell.com/articles/Introducing_SCA.pdf •  http://www-128.ibm.com/developerworks/websphere/techjournal/0510_brent/

0509_brent.html •  http://events.oasis-open.org/home/sites/events.oasis-open.org.home/files/

Flexible_Agile_Composition_01.ppt [Mike Edwards] •  http://www.osoa.org/download/attachments/250/

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

reconfigurable service-oriented architectures

Technology