Project no. 223996
GENESIS
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
Instrument:
Please tick
CA
STREP
IP
NOE
ICT
-
Information and Communication
Technologies Theme
WP6000
–
Report on EasyBPEL integration into Genesis
architecture
Due date of deliverable (as in Annex 1):
M22
Actual submission date:
30/07/2010
Start date of project: Sept. 2008
Duration: 3 years
Lead contractor for this deliverable:
EBM
Revision
2
.00
Project co
-
funded by the European Commission within the
Seventh Framework Programme (2007
-
2013)
Dissemination Level
PU
Public
X
PP
Restricted to other programme participants (including
the Commission Services)
RE
Restricted to a group specified by the consortium
(including the Commission Services)
CO
Confidential, only for members of the consortium
(including the Commission
Services)
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
2
of
23
DOCUMENT CONTROL TABLE
Title
Report On Scalable Service Infrastructure Assessment Activity
Document
reference
D5600.1
Revision
2
.00
Revision date
15/07/2009
Author
Jean
-
Pierre Lorré
Company
EBM WEBSOURCING SAS
Contributors
Jean
-
Pierre Lorré
EBM
Frédéric Gardes
EBM
Thierry Dejean
EBM
Arne Bröring
WWU
Simon Jirka
WWU
Julien
Lesbegueries
EBM
Dissemination
level
Public
Review status
Draft
SP leader approved
Coordinator approved
GA approval
(where applicable)
GA approved
GA approved as public
SIGNATURES
Signatory
Role
Company
Date of
signature
Signature
Julien Lesbegueries
Contributor
EBM Websourcing
29/07/2010
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
3
of
23
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
4
of
23
REVISION RECORD
ISSUE
DATE
UPDATES
AUTHOR
1.00
Julien
Lesbegueries
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
5
of
23
A
BSTRACT
This document presents
the results of WP6430 and WP6450 works resulting in a new component
compliant with GENESIS. This new component is an open source BPEL engine allowing GENESIS
geo
-
processing services to be orchestrated in higher level services. It is useful for asynchronou
s
services that can be encapsulated in order for exceptions, errors and timeout to be managed.
C
OPYRIGHT
The GENESIS Consortium consists of:
Legal Name
Acronym
Country
THALES ALENIA SPACE FRANCE
TAS
-
F
FR
DEUTSCHES ZENTRUM FUER LUFT UND RAUMFAHRT E.V.
DLR
DE
SOGREAH CONSULTANTS SAS
SGH
FR
ACRI
-
ST S.A.S.
ACRI
-
ST
FR
SPACEBEL SA
SPACEBEL
BE
WESTFAELISCHE WILHELMS
-
UNIVERSITAET MUENSTER
WWU
DE
JOINT RESEARCH CENTER
–
EUROPEAN COMMISSION
Institute for Environment and Sustainability (IES)
Institute for
Health and Consumer Protection (IHCP)
JRC
EU
4C TECHNOLOGIES NV
4CT
BE
GMV AEROSPACE AND DEFENCE SA
GMV A&D
ES
G.I.M. GEOGRAPHIC INFORMATION MANAGEMENT NV
GIM
BE
INTECS S.P.A.
INTECS
IT
EBM WEBSOURCING SAS
EBM WS
FR
ERDAS SA
ERDAS
BE
RESEARCH
STUDIOS AUSTRIA FORSCHUNGSGESELLSCHAFT MBH
RSAFG
AT
BRITISH PUBLISHERS LIMITED
BPL
UK
CAMBRIDGE ENVIRONMENTAL RESEARCH CONSULTANTS LTD
CERC
UK
IMPERIAL COLLEGE OF SCIENCE, TECHNOLOGY AND MEDICINE
ICSTM
UK
CENTRE HOSPITALIER UNIVERSITAIRE DE NICE
CHU
NICE
FR
LUDWIG
-
MAXIMILIANS
-
UNIVERSITAET MUENCHEN
LMU
-
MUENCHEN
DE
INSTITUT FUER OSTSEEFORSCHUNG WARNEMUENDE AN DER
UNIVERSITAET ROSTOCK
IOW
DE
INSTYTUT METEOROLOGII I GOSPODARKI WODNEJ
IMGW
PL
COMMISSARIAT A L’ENERGIE ATOMIQUE
CEA
FR
INGENIEURGESELLSCHAFT PROF. KOBUS UND PARTNER GMBH
KUP
DE
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
6
of
23
Legal Name
Acronym
Country
Universite Pierre et Marie Curie
UPMC
FR
KLAIPEDOS UNIVERSITETAS
KU
LT
FRAUNHOFER GESELLSCHAFT ZUR FOERDERUNG DER ANGEWANDTEN
FORSCHUNG E.V.
FRAUNHOFER
DE
ORACLE BELGIUM BVBA
ORACLE
BE
UNIVERSITY OF THE WEST OF SCOTLAND
UWS
UK
BUREAU DE RECHERCHES GEOLOGIQUES ET MINIERES
BRGM
FR
No part of this work may be reproduced or used in any form or by any means (graphic, electronic,
or
mechanical including photocopying, recording, taping, or
information storage and retrieval
systems) without the
written permission of the copyright owner(s) in accordance with the terms of
the
GENESIS
Consortium Agreement(EC Grant Agreement 223996).
All rights reserved.
This document may change without notice.
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
7
of
23
T
ABLE
O
F
C
ONTENTS
1.
INTRODUCTION
................................
................................
................................
.........
9
1.1
D
OCUMENT
O
VERVIEW
................................
................................
...............................
9
1.2
D
OCUME
NTARY
R
EFERENCE
S
YSTEM
................................
................................
.........
9
1.2.1
Applicable documents
................................
................................
...........................
9
1.2.2
Reference documents
................................
................................
...........................
9
1.3
A
BBREVIATIONS
,
T
ERMS AND
D
EFINITIONS
................................
................................
10
2.
OVERVIEW
................................
................................
................................
...............
11
3.
STATE OF THE ART
................................
................................
................................
12
3.1
R
ELEVANT
S
TANDARDS
................................
................................
...........................
12
3.1.1
Web Services
................................
................................
................................
.......
12
3.1.2
WS
-
Eventing
................................
................................
Error! Bookmark not defined.
3.1.3
WS
-
Notification
................................
................................
................................
....
12
3.1.4
Complex Event Processing
................................
........
Error! Bookmark not defined.
3.2
E
NTERPRISE
S
ERVICE
B
US
(ESB)
................................
................................
............
14
3.2.1
Introduction
................................
................................
.
Error! Bookmark not defined.
3.2.2
Petals open
-
source ESB
................................
.............
Error! Bookmark not defined.
3.3
E
VENT
D
RIVEN
A
RCHITECTURE
(EDA)
INTO AN
ESB
...
E
RROR
!
B
OOKMARK NOT DEFINED
.
4.
RECOMMENDATIONS ON S
TANDARDIZATION AND N
EW TECHNOLOGY
IMPROVEMENTS
................................
...........
ERROR! BOOKMARK NOT
DEFINED.
4.1
I
NTEGRATION OF
ESB
C
ONCEPTS INTO THE
GENESIS
A
RCHITECTURE
E
RROR
!
B
OOKMARK NOT DEFINED
.
4.1.1
Distributed Service Architecture
...............................
Error! Bookmark not defined.
4.1.2
Data intensive applications
................................
........
Error! Bookmark not defi
ned.
4.1.3
OGC Compliance
................................
........................
Error! Bookmark not defined.
4.2
L
INKING OF
OGC
SWE
S
ERVICES WITH AN
ESB
.........
E
RROR
!
B
OOKMARK NOT DEFINED
.
4.3
EDA
I
MPLEMENTATION FOR TH
E
GENESIS
S
ENSOR BASED
E
VENT
A
RCHITECTURE
E
RROR
!
B
OOKMARK NOT DEFINED
.
4.3.1
Integration of EDA concepts into an ESB
.................
Error! Bookmark not defined.
4.3.1.1
JBI Components enhanced as Notification Producers
Error! Bookmark not defined.
4.3.1.2
JBI Broker Component
................................
......
Error! Bookmark not defined.
4.3.2
Villerest illustrative use case
................................
.....
Error! Bookmark not defined.
4.4
S
UMMARY
................................
................................
.
E
RROR
!
B
OOKMARK NOT DEFINED
.
5.
IMPACTS ON
ARCHITECTURE
................................
................................
...............
20
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
8
of
23
5.1
O
VERALL
GENESIS
ARCHITECTURE
................................
................................
........
20
5.2
U
SE OF THE RESULTS
................................
................................
..............................
21
5.3
A
DAPTATION OF THE ARC
HITECTURE
.
................................
................................
........
21
L
IST
O
F
F
IGURES
Figure 3
-
1: Publish/Subscribe
-
Paradigm
................................
..........
Error! Bookmark not
defined.
Figure 3
-
2: Subscribtion/Unsubscribt
ion
................................
...........
Error! Bookmark not defined.
Figure 3
-
3: Notification
................................
................................
.....
Error! Bookmark not defined.
Figure
3
-
4: Schematic view of the complex event processing approach
.........
Error! Bookmark not
defined.
Figure 3
-
5: Petals main components.
................................
................................
............................
17
Figure 3
-
7: EDA concepts
................................
................................
Error! Bookmark not defined.
Figure 4
-
1: GENESIS Architecture
................................
...................
Error! Bookmark not defined.
Figure 4
-
2: GENESIS Service Provider Node
................................
..
Error! Bookmark not defined.
Figure 4
-
3: Schematic illustration of the façade solution
...................
Error! Bookmark not defined.
Figure 4
-
4: GENESIS Event Driven Architecture
..............................
Error! Bookmark not defined.
Figure 4
-
5: Event management components
................................
....
Error! Bookmark not de
fined.
Figure 4
-
6: WS
-
Notification Broker c
omponents and interfaces
.......
Error! Bookmark not defined.
Figure 4
-
7: Petals ESB as a notification broker within GENESIS context.
......
Error! Bookmark not
defined.
Figure 4
-
8: Distributed architecture of the GENESIS demonstrator.
.
Error! Bookmark not defined.
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
9
of
23
1.
INTRODUCTION
1.1
D
OCUMENT
O
VERVIEW
This document presents the results of WP6430 and WP6450 works resulting in a new component
compliant with GENESIS. This new component is an open source BPEL engine allowing GENESIS
geo
-
processing services
to be orchestrated in higher level services. It is useful for asynchronous
services that can be encapsulated in order for exceptions, errors and timeout to be managed.
1.2
D
OCUMENTARY
R
EFERENCE
S
YSTEM
1.2.1
Applicable documents
A1
GENESIS
–
Annex I to Grant Agreement
–
Part B
–
Description Of Work
Issue
9.10
–
15/03/2010
1.2.2
Reference documents
R1
Project glossary
R2
Project executive summary
R3
Vretanos
, P.A. (2005): Web Feature Service Implementation Specification. OpenGIS®
Implementation Specification. OGC 04
-
094. Version: 1.1.0
R4
Whiteside, A. & J.D. Evans (2008): Web Coverage Service (WCS) Implementation
Standard. OGC® Implementation Standard. OGC
07
-
067r5. Version 1.1.2
R5
Whiteside A. & J. Greenwood (2009): Candidate Revision: OGC Web Services
Common. OGC 06
-
121r7. Version 1.2.0
R6
Java Community Process. Java(tm) Business Integration (JBI) 1.0
-
Final Release. JSR
208, Sun Microsystems, Inc.,
August 2005.
R7
Dave Chappell, "Enterprise Service Bus: Theory in Practice", O'Reilly Media, June 2004
(1st edition)
R8
Steve Craggs, "Best
-
of
-
Breed ESBs
-
Making your choice", Global Integration Summit,
May 23
-
25, 2005, Banff, Canada
R9
Luckham D. C. 2
006, What’s the Difference Between ESP and CEP? Online
Article.
http://complexevents.com/?p=103, August 2006. Last visited: July
2008.
R10
Bass T. 2007, Mythbusters: Event Stream Processing versus Complex Event
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
10
of
23
Processing. In DEBS '07: Proceedings of the
2007 inaugural
international conference on
Distributed event
-
based systems, pages 1
–
ㄬ
New v潲oI NvI rpAI ㈰〷. ACM.
oㄱ
p潵r捥c 桴t瀺LLwww.j扯獳s潲术摲潯l猠L
1.3
A
BBREVIATIONS
,
T
ERMS AND
D
EFINITIONS
Refer to [R1]
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
11
of
2
3
2.
OVERVIEW
This report explains results on integration of open source tools to manage workflows. These tools
are the BPEL engine EasyBPEL, and the Petals ESB in which EasyBPEL is deployed. Indeed, the
GENESIS portal used first Oracle BPEL, a proprietary BPEL engine e
nhanced by some tools to
visualize and administrate workflows. The idea was to provide an open source alternative.
The mechanism of EasyBPEL is to be executed into an execution environment, as the JBI
-
based
Petals ESB. JBI mechanisms are used to deploy BPE
L workflows. Then in order to replace Oracle
tools, an additional feature must be provided in Petals ESB, in order to accept non
-
JBI deployment
requests coming from the GENESIS portal.
Moreover, main geo
-
processing services are asynchronous services using
the WS
-
Addressing
standard. This was managed in Oracle BPEL engine as a proper extended activity. In a same way,
an extended activity managing WS
-
Addressing is developed for EasyBPEL.
Main works have been then to expose a deployment interface upon Petals
ESB, compliant with
TODO SPB standard. Then an extended activity managing WS
-
Addressing for asynchronous
services has been developped for EasyBPEL.
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
12
of
23
3.
STATE OF THE ART
This part describes relevant standards according to works on EasyBPEL engine and Petals E
SB.
They are mainly coming from Web Services standards.
3.1
R
ELEVANT
S
TANDARDS
3.1.1
Web Services
Web Services
as defined in this document
are software components that comply to tw
o main
standards, WSDL
1
and SOAP
2
(Please note: Within GENESIS usually a different definition is used,
as services like the OGC SWE services which currently do not possess a SOAP interface are also
considered as Web Services).
WSDL (Web Service Description Language) defines the syntactica
l structure of the programmatic
interface offered by a Web service. In particular, it defines the
operations offered by the Web
S
ervice in terms of their parameters and return value
s
.
SOAP (Simple Object Access Protocol) is the communicat
ion protocol being
used by Web
S
ervices. It is an XML bas
ed language, which
prescribes the structure that all me
ssages
exchanged between a Web S
ervice and its consumers should comply to. Both WSDL and SOAP
are independent of a specific programming language and of the transp
ort protocol being used. In
most cases, however, Web Services rely on HTTP as the transport protocol. This allows the
communication to pass through firewalls. Another standard that is related to Web Services is UDDI
(Universal Description Discovery & Integ
ration). It defines how to communicate with a registry for
publishin
g information about Web Service
interfaces and for discovering Web S
ervices.
.
3.1.2
WS
-
BPEL
WS
-
BPEL
3
is a
n OASIS
standard defined for services orchestration. Indeed Web Services are core
unit
s for SOA but are often used in combination with each other in order to provide higher level
services.
A WS
-
BPEL instance, that is also a service itself, can be seen as a conductor in
a
centralized way of execution, invoking several services while processi
ng.
The standard defines means of invoking services
based on WSDL definitions
, called partnerlinks,
and provides a set of control structures (as
conditional If and loops). It allows
building
execution
graphs understandable by BPEL engines.
The
Figure
3
-
1
shows a typical example of what can be found in GENESIS BPEL processes.
The
BPEL is represented as a set of nodes containing an activity:
First, the receiv
e activity allows a BPEL process to receive a message coming from the
external environment (the portal for instance). As a BPEL process is defined by a WSDL
1
http://www.w3.org/TR/wsdl
2
http://www.w3.org/TR/soap12
-
part1/
3
Stands for Business Process Execution Language.
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
13
of
23
and is considered itself as a Web service, the receive activity corresponds to an input
message
of
an operation
of an interface defined for this BPEL process.
The assign activity allows
copying
some data into variables or partnerlinks.
The reply activity allows the BPEL process to answer a request by sending a message. It
corresponds to the output messa
ge of an operation of an interface defined for the BPEL
process.
The invoke activity allows to call Web services, called partnerlinks.
The pick activity allows to wait for multiple incoming messages
or alarms.
The sequence of the represented BPEL process
is to receive an incoming message from the
portal, to reply a acknowledgement in order to tell the requester the processing is accepted or not.
Then the BPEL process sends the request to the real Web service (Service A) that sends it self an
acknowledgemen
t. Then the pick activity waits for the Service A callback (until a defined time out).
The callback is finally forwarded to the portal thanks to the last invoke.
This asynchronous mechanism of callbacks
implies the use of metadata information in order for
services to know where to send them. This is done, in the context of Genesis, thanks to the WS
-
Addressing specification, that will be explained in the next section. It allows
basically
to add
callback a
ddress in message exchanges.
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
14
of
23
Figure
3
-
1
:
Asynchronous BPEL process example.
3.1.3
WS
-
Addressing
WS
-
Addressing is a specification from
the W3C
, defining basically means for Web Services
addressing. It defines
EndpointReference
type and message information headers. The first
construct contains an address localizing a Web Service. The second construct allows to correlate
message exchanges between each other (messageID).
It is used in GENESIS context in SOAP headers of messages sent by services.
In the
Figure
3
-
1
WS
-
Addressing is used in the portal request in order for the BPEL engine
to know where to send
the final callback, and by the BPEL process itself in order to tell the Service A where to send the
callback.
3.1.4
Enterprise Service Bus (ESB
)
The key item for integration of services within a SOA is the Enterprise Service Bus (ESB). The
goal
of an ESB is to provide virtualization of the enterprise resources, allowing the business logic of the
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
15
of
23
enterprise to be developed and managed independently of the infrastructure, network, and
provision of those business services.
The
Enterprise Servic
e Bus (ESB) is a new class of integration tools. It supports integration and is
also characterized by transformation and routing functions. More in
-
depth descriptions of the ESB
concept are available in
(R7, R8)
.
Originally, first commercial ESB products w
ere described both as a way to integrate existing
middleware services (J2EE application servers, message
-
oriented brokers, etc.) and products
(e.g., B2B solutions) and to connect applications with the required protocols. More recently, since
the advent of
the SOA approach, ESBs have also been presented as a way to create a SOA.
ESBs clearly face two major challenges:
How to integrate heterogeneous technology and products, possibly produced by
different
vendors, in a way that is appropriate with respect to t
he size of each particular integration
problem?
How to provide the required features to fully address the specifics of SOA needs?
The Java business Integration (JBI) standard seeks to address the first challenge by adopting the
SOA principles. An ESB is b
uilt from JBI containers that can be an integration framework, a host
for Java connectors, an XSLT engine, a mediation engine, a service orchestrator, etc. JBI
maximizes the decoupling between the JBI containers that all provide and consume services. The
E
SB links the containers together, allowing them to interact.
Currently, it turns out that JBI
-
compliant ESBs are mostly open
-
source ESBs that aim at promoting
highly configurable and made
-
to
-
measure ESBs in order to better fit business needs.
For instance,
ServiceMix
ESB is an Apache project
delivered with the Apache
l
icence
,
providing an Hub and
Spoke architecture;
Open
ESB
, delivered with a CDDL licence
4
is not distributed;
and Petals ESB
delivered with the LGPL licence
5
. Petals
ESB is the only project that natively provides a distributed
framework
composed of nodes, allowing the design of very large scale systems
.
For instance it is
involved in the creation of Service Clouds in the SOA4ALL project
6
.
Another
particularity of this
project is its will to be
fully compliant with all SOA standards such as
JBI,
WSDL
, BPEL,
SCA and
more recently WS
-
* specifications.
The JBI specification has been standardized by the Java Community Process (JCP) expert group.
The
JBI specification promotes a plug
-
in based architecture which enables the creation of tailored
integration solutions by putting together the best
-
of
-
breed integration components. One of the main
interest for using JBI compliant software in an ESB is that i
t is based on Web Services best
practices (WSDL usage, loose coupling, XML messaging).
Companies
may
currently
be
struggling with the second challenge, as they
might
realize that an
ESB vendor's solution does not fit their needs. The reasons are manifold:
for example, the ESB
does not provide management models to control and enforce QoS at different levels and track
consumer usage; it does not fit into existing management and security frameworks; it is unable to
connect to or evolve towards
B2B
archite
cture. This problem will still be open, as long as SOA
technology editors do not address the immediate and long
-
term business needs, and concrete
functional SOA.
4
http://www.sun.com/cddl/cddl.html
5
http://www.gnu.org/licenses/lgpl.html
6
http://www.soa4all.eu/
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
16
of
23
Petals ESB
is an Open Source (LGPL License) Enterprise Service Bus provided by the OW2
middlew
are consortium.
Petals ESB
is built with and on top of agile technologies such as:
The Java Business Integ
ration (JBI) v1.0 specification
(R6)
:
Petals ESB
has recently been
certified by SUN Microsystems as a valid JBI implementatio
n
The Fractal Software
Component Framework
provided by the OW2 consortium:
Fractal is a
modular and extensible component model that can be used with various programming
languages to design, implement, deploy and reconfigure various systems and applications,
from operating system
s to middleware platforms and to graphical user interfaces. From the
Petals ESB
’s point of view, all the container services (such as service registry, message
router, message transporter, discovery, etc.) are implemented as Fractal components. This
is a ma
jor feature which allows core developers to specialize a
Petals ESB
distribution by
choosing the software components to be used for specific needs.
The main
Petals ESB
feature is that it extends the JBI specification by providing a distributed vision
of t
he JBI platform. Several
Petals ESB
containers distributed across several nodes are equivalent
to a single unified
Petals ESB
container. Thanks to this approach, all the services remain
accessible as they are in a typical standalone JBI environment. Where
other JBI containers provide
a distributed approach by connecting containers with the use of JBI Binding Components plus
h
uge configuration,
Petals ESB
provides this feature natively without any additional configuration.
This distributed behaviour is provi
ded by the following software components
(presented in
Figure
3
-
2
)
:
The technical registry:
The
Petals ESB
JBI services, endpoints, interfaces, WSDL
description
and c
ontainer location are stored in the technical registry. This registry is used
by the
Petals ESB
container to register services and to route the JBI messages to the right
endpoint. The registry entries are actually replicated among all the
Petals ESB
nodes
using
a Distributed Hash Table over a multicast channel. This is quite equivalent to data flooding
between registries, i.e., when an entry is added to the registry, the data is sent to all the
network registries. So all the registries have a complete visio
n of the services hosted by all
the containers. This approach is the base of the unified bus but is not scalable at all.
The message transporter:
This layer is not defined in the JBI specification. Its role is to
exchange JBI messages between containers.
In a standard JBI implementation, the
Normalized Message Router gets the local endpoint reference from the local registry and
sends the message to local JBI endpoint
s
. In the
Petals ESB
approach, once the endpoint
transport layer which is in charge to deli
ver the message to the JBI endpoint whatever the
container it is hosted on.
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
17
of
23
Figure
3
-
2
:
Petals main components.
Petals ESB
is
not a simple JBI container. The project also provides various frameworks,
components and tools for extension, service integration, management and monitoring purposes:
The Component Development Kit (also named CDK) is a software framework which
abstracts
all the JBI related API and provides an easy way to create high performance JBI
components (Service Engines and Binding Components) with a small set of classes.
All the JBI components are based on the previously cited CDK framework. The actual
collection of
Petals ESB
JBI components is composed of binding components (provide
connectivity to/from external services) like SOAP, FTP, JDBC, and foreseen in the project,
to the semantic space, and service engines (provide internal technical services) like BPEL,
BPMN, XSLT, EIP, RULES, SCA.
The WebConsole is a Web GUI used to monitor and manage the
Petals ESB
containers.
This tool provides a single access point to monitor
and manage all the distributed
containers. The console is connected to the containers through a JMX based data collector
which is a mediator between the console and all the
Petals ESB
containers.
The Petals ESB architecture consists in a distributed topology of nodes (as presented in
Figure
3
-
3
) that communicate over internet. This characteristic al
lows moving the ESB closer to every
partner involved in services integration. The
Figure
3
-
3
illustrates this specific architecture with
some integrations examples. Business services provided by the bus, like a BPEL engine or XSLT
transformation can be used on every node provided that the corresponding component is
deployed.
Registry
Transporter
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
18
of
23
Figure
3
-
3
:
Distributed aspect of Petals ESB.
4.
NEW COMPONENTS FOR S
ERVICES ORCHESTRATIO
N
The w
orks on
WP6430 and WP6450 result in integrating
PetalsESB
and
EasyBPEL
in
Workflow
deployment.
Some extensions have been developed in order to perform this integration.
4.1
P
ETALS
ESB
EXTENDED SERVICE FOR
BPEL
D
EPLOYMENT
Petals ESB is by default a JBI
-
based bus, with JBI mechanisms of service deployment and
invocation.
In particular, configuration
artefacts are
defined for service deployment :
The Service Unit (SU) is a zip file containing a configuration file with information about
interface / service / endpoint deployed, a WSDL describing the service to be deployed, and
specific files related to t
he service. For example, a SU built to deploy a BPEL process will
contain a BPEL file (and WSDLs of its partnerlinks).
The Service Assembly (SA) is also a zip file containing a set of SUs that are assembled
according to a
particular service project.
These
SAs are generally deployed onto the bus thanks to JMX connection. In the context of a
BPEL process deployement, the following SUs are to be expected:
A SU providing the BPEL process service (representing the W1 red endpoint in
Figure
4
-
1
).
A SU exposing this BPEL process service outside the bus (in order to be visible by the
portal for instance). This is represented in the figure by the W1 blue endpoint.
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
19
of
23
Some SUs import
ing external Web Services (S1, S2, … Sn)
involved in the BPEL process
and making them visible inside the bus.
Figure
4
-
1
:
Deployed services for BPEL process installation.
In the GENESIS context, workflow deployment is expected to be
performed according to a
specification (TODO SPB). Basically it consists in a XML file containing WSDLs, XML Schemas
and the BPEL to deploy. In order to be compliant with
this
mechanism, an addi
tional administration
interface (represented by the A blue endpoint in
Figure
4
-
1
)
has been developed. It consists
in an
automatic generation of the SA described
above
that
is then deployed in a
nominal
way.
4.2
E
ASY
BPEL
EXTENDED ACTIVITY
As we saw before, WS
-
Addressing is used in order to manage services asynchronism.
It implies
that the BPEL engine executing the workflow is able to send messages containing meta
-
data about
callback address.
It is done thanks to an extended activity developed upon EasyBPEL engine.
It consists in adding a specific attribute into invoke ac
tivities, corresponding to a variable containing
particular
Endpoint
Reference (e.g a ReplyTo construct).
This attribute is then used to build the
SOAP header of the external message sent to the Web Service.
WS
-
BPEL extensibility is foreseen
and consists in
our case in the following extracts to add in the
BPEL file.
First we have to define the WS
-
Addressing extension as following:
<ns6:extensions>
<ns6:extension
namespace=
"http://easybpel.ebmwebsourcing.com/extension/activities/package/invokeaddressing"
mustUnderstand="yes">
</ns6:extension>
</ns6:extensions>
Then WS
-
Addressing headers have to be set. We use here the BPEL Assign activity:
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
20
of
23
<
bpel
:assign name="af
fectReplyTo">
<bpel
:copy>
<
bpel
:from>
<
bpel
:literal>
<wsa:ReplyTo xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Address>
http://soap
-
g
enesis.ebmwebsourcing.com/petals/services/RasterResamplingCallbackPort
<
/wsa:Address>
</wsa:ReplyTo>
</
bpel
:literal>
</
bpel
:from>
<
bpel
:to variable="rasterCallback" />
</
bpel
:copy>
</
bpel
:assign>
We assign here a ReplyTo value to the rasterCallback variable.
Finally a special invoke has to be used:
<
bpel
:extensionActivity>
<inva:invokeaddressing name="invoke1"
partnerLink="asynProvider"
portType="wpsServiceNS:RasterResampling"
operation="
ExecuteProcess_RasterResampling_ASYNC"
inputVariable="wpsAsynServiceInputMessage"
outputVariable="wpsAsynServiceOutputMessage"
header
="rasterCallback"
/>
</
bpel
:extensionActiv
ity>
The additional attribute header is used to add WS
-
Addressing metadata in the message going to
be sent by the BPEL engine.
5.
IMPACTS ON ARCHITECT
URE
The aim of this part is to summarize the main concepts that drive the GENESIS architecture, to
give information about the impact of the studies carried on by this
Work Package
and to specify
main improvement drivers.
5.1
O
VERALL
GENESIS
ARCHITECTURE
The GENESI
S workflow deployment architecture consists in a Web service
-
based mechanism
b
ased on a WPS standard using
WS
-
BPEL and WS
-
Addressing. A BPEL engine administration
available as a Web Service
performs
generated workflows.
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
21
of
23
5.2
U
SE OF THE RESULTS
EasyBPEL provide
s an
open source
alternative
for Oracle BPEL engine.
Thanks to the extended
service of workflow deployment
exposed by
the Petals ESB, the portal client can use the same
request format for either Oracle BPEL either EasyBPEL engine.
5.3
A
DAPTATION OF THE
ARCHITECTURE
The integration of EasyBPEL within the GENESIS workflow deployment architecture
implies few
adaptations. First, EasyBPEL
is compliant with the version 2.0 of WS
-
BPEL standard whereas the
Oracle BPEL engine works with the 1.1 version. The second adaptation concerns the BPEL
processes content, since extended activities are proper to their engines (namespace, structure).
Main
differences between the versions of WS
-
BPEL are:
Namespaces:
Standard
V1.1
V2.0
BPEL
http://schemas.xmlsoap.org/ws/2003/03/business
-
process/
http://docs.oasis
-
open.org/wsbpel/2.0/process/executable
PartnerLinkType
http://schemas.xmlsoap.org/ws/2003/05/pa
rtner
-
link/
http://docs.oasis
-
open.org/wsbpel/2.0/plnktype
Some activities name replace (switch in 1.1 became if in 2.0)
Some constructs are slightly different (as for partnerlink types definitions):
In BPEL 1.1:
<plnk:partnerLinkType name="
GimRasterResamplingPLT ">
<plnk:role name="gimRole
">
<plnk:portType name="tns:
RasterResampling" />
</plnk:role>
<
/
plnk:partnerLinkType
>
Whereas in 2.0:
<plnk
:partnerLinkType name="GimRasterResamplingPLT">
<
plnk
:role
name="gimRole"
portType="tns:RasterResampling"
/>
</
plnk
:partnerLinkType>
The workflow generat
ion
must be able to manage these slight
differences depending on the portal
client choice.
Finally, (BPEL) services deployed in PetalsESB
can be visualized and administr
ated thanks to the
Web Console tool (stop/start, uninstall, etc.).
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
22
of
23
GEN
eric
E
uropean
S
ustainable
I
nformation
S
pace for Environment
FP7
-
ICT
-
2007
-
Integrated project 223996
Deliverable :
D5600.1
Date
:
30/07/2010
Issue
:
1.00
Report On Scalable Service Infrastructure Assessment Activity
© Copyright 2008 2010
as per GENESIS Consortium Agreement.
Page
23
of
23
END OF DOCUMENT
- Home
- Browse
- All Categories
- AI and Robotics
- Biotechnology
- Clean Technology
- Data Management
- Electronics - Devices
- Enterprise Applications
- Entertainment
- Internet and Web Development
- Management
- Mechanics
- Mobile - Wireless
- Networking and Communications
- Oil and Offshore
- Security
- Semiconductor
- Servers
- Software and s/w Development
- Storage
- Telecommunications
- Urban and Civil
- Community
- Upload
Comments 0
Log in to post a comment