Evolution of Service Oriented Architecture

1
Evolution ofService Oriented Architecture
ADAM Seminar August 29-31 2007
Guillaume Dufrêne Advised by Lionel Seinturier
2
Agenda

• Previous work Bridging component frameworks
• Evolution of SOA
• ADL for Distributed Heterogeneous CB
  applications
• Applying our solution to the deployment
• Perspectives

3

• Bridging CFs

4
Problem and goals

• Many component frameworks.
• gt How to connect them together ?
• Master thesis Case study about Fractal and SCA

5
Results

• From fractal point of view using SCA server
  Interface.
• Shadow component (proxy-like)
• A dedicated binding controller soap-controller

6
Results

• From Fractal point of view offering Fractal
  client Interface.
• Extending Comanche

7

• Evolution of SOA

8
Problem / goals

• Agility of SOA
• Support evolvable applications
• Adaptation of applications according to their
  context

9
Definition

• A service is a set of business functionalities
  offered to an actor (human or software).
• Interface a mean to describe functionalities

10
Adaptation ? Evolution ?

• Business evolution
• Environment changes
• When ? At every stage of software development.
• Requirements (business needs)
• Analysis (PIM)
• Conception (PSM)
• Implementation
• Deployment
• Run-time

11

• ADL for Distributed HeterogeneousCB applications

12
Strategy

• Refining Architecture Description at each stage.
• Similar approach MDE
• Starting point dependencies description between
  components and middleware at deployment-time.

13
ADL concepts

• Common component concepts
• Primitive and composite
• Ports which provides or requires functionalities
  defined by Interfaces
• Binding mechanism
• Component Frameworks
• Required libraries
• Provided component support
• Host (address, transfer protocol, shell type)

14
Introduced Notions
Vertical dependencies
Horizontal dependencies
15
BNF-like syntax of our ADL

• ADL ltDefinitiongt
• Definition ltPrimitifDefgt ltCompositeDefgt
• ltFrameworkDefgt ltHostDefgt
• PrimitifDef component ltTypeDefgt
  ltProvidedItfsgt?
• ltRequiredItfsgt? ltPropertiesgt
• TypeDef type ltnamegt
• ProvidedItfs provide
• ltInterfaceDefgt (, ltInterfaceDefgt)
• RequiredItfs require
• ltInterfaceDefgt (, ltInterfaceDefgt)
• InterfaceDef ltitf_Namegt ltitf_Typegt
• Properties properties TreeStruct
• TreeStruct ltnodeNamegt ltnodeValuegt
• nodeValue "ltCHARgt" TreeStruct
• CompositeDef composite ltProvidedItfsgt?
  ltRequiredItfsgt?
• ltConnectiongt ltPropertiesgt
• Connection ltPathDefgt -gt ltPathDefgt
• PathDef ltAbsPathgt ltRelPathgt
• AbsPath /ltRelPathgt

16

• Applying our solution

17
UTP as a validating example

• Urban Trip Planer (F.Baligand) FAROS Project

18
UTP definition
Composite UTP provide instructions
Details, tripMap Map require
deviceID Integer, destination String ( .
. . ) /Transportation/instruction -gt
instruction /Transportation/lastStation -gt
/Grapher/from /Grapher/map -gt
tripMap ComponentFramework openCCM type
ccm libraries openccm_api Host gentse
address gentse.lifl.fr shell ssh transfert
scp

• Component Transportation
• type sca
• provide
• instructions Details, lastStation Address
• require
• start Station, destination String
• properties
• dbconf
• host sql.mydbserver.com
• user lambda
• password xxxxxxx
• dbname mydb1
• Component Grapher

19
Using Deployware (FDF)

• Adding some personalities
• Translate our ADL to FDF-script

20
Conclusion / Perspectives

• Done Handle the deployment.
• TBD
• Describe and adapt services from the requirements
  to the run-time
• Partnership with Argia
• Component vs Service Dataflow vs Workflow