2. 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. 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
33
4. 4
Outline
1. Service-Oriented Architecture – SOA
2. Service Component Architecture – SCA
3. OW2 FraSCAti
4. Conclusion
4
10. 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. 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. 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
15. 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
17. 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. 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. 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. 20
SCA in a nutshell
Assembly: ”Process of composing business applications by
configuring and connecting components that provide service
implementations”
20
21. 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
Ledger
SOAP/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. 22
Simple SCA assembly
Composite bank.account
Reference
StockQuote
Service Component
Account
AccountFacade
Component
AccountData
[Mike Edwards]
IBM Hursley Lab, England
22
24. 24
Java implementation example: Service
Service
Account
package services.account; Interface is available
remotely, e.g. as a
@Remotable Web Service
public interface Account {
AccountReport getAccountReport(String customerID);
}
24
25. 25
Java implementation example:
Component Component
AccountFacade
package services.account;
import org.osoa.sca.annotations.*; Annotation for the
service offered by
@Service(interfaces = Account.class) this class
public 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
27. 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 effective
Tolerance 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. 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
30. 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. 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. 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. 33
FraSCAti and the SCA specifications
FraSCAti
SCA Specification
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
35. 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. 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. 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 Level
Component assemble
components Description
Reflection
Platform
Assembly Parser
Factory SPL
everywhere Personality
Factory
Run-time Level
Framework
«interface»
Component
+getFcInterface(in name) : Object
+getFcInterfaces() : Object[]
+getFcType() : Type
Fractal
Component
Kernel Level 37
38. 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 Factory
Run-time
38
39. 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. 40
FraSCAti and AOP
• Non functional concerns as shared & reflective FraSCAti composites
• AOP for crosscutting concerns
40
41. 41
FraSCAti and DSL
Simple reconfiguration scenario
41
43. 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
49. 49
FraSCAti demonstrators
Autonomous home control system
Movement Sensor
HOME ZigBee
SOAP
UPnP
Module Store
Set-Top-Box
TV HTTP
HTTP
UPnP
RMI
Smart Phone
Multimedia Server
50. 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 Module
push 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
53. 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
56. 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
58. 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. 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. 60
Thank you for your attention
Visit http://frascati.ow2.org
Contact
• Lionel Seinturier: Lionel.Seinturier@univ-lille1.fr
60
62. 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
![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](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)