Report On Scalable Service Infrastructure Assessment Activity

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