reconfigurable service-oriented architectures
DESCRIPTION
TRANSCRIPT
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
Component AccountFacade
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
Component AccountFacade
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
FraSCAti demonstrators
Edifixio: e-Business integration with SCA
46
47
FraSCAti demonstrators
Edifixio
47
48
FraSCAti demonstrators
Thales: Network monitoring
Discovery
Inventory Java Swing
VNUML Virtualized Network
Visualization
Monitoring
48
49
FraSCAti demonstrators
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
FraSCAti demonstrators
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
FraSCAti demonstrators
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