EBM Websourcing

Driven by SaaS market momentum, the growth of large service ecosystems involves radical changes in both enterprise Business Process organization and IT infrastructure to fit interoperability and agility requirements.

Many questions associated with the paradigm shift arise: how can we move to a network of services of Internet scale transparently available across the many devices we use to access information? What support will services need from an increasingly ubiquitous Internet? To meet these requirements, we propose to address the service infrastructure itself and provide an open, context-aware service bus, enabling both syntactic and semantic interoperability.

The SEMEUSE project specifically aims to provide a context-aware semantic service architecture addressing both the design phase, thanks to theoretical context-aware semantic service models and policy-oriented design patterns, and the runtime phase, thanks to a Dynamic Semantic Service Bus (see below figure). This extended service bus is based on a static and dynamic service composition engine so that the current execution context and particular requirements (related for example to nomadic constraints) can be continuously taken into account. A dynamic monitoring system, using CompositeProbes, will also be connected to the orchestration process so that QoS aware late binding can be implemented.

The main objectives of SEMEUSE are then to:

• Enable service to be used anywhere from any kind of device (pervasive technologies).

• Address non-functional/QoS requirements associated with service provisioning, with a special emphasis on dependability constraints and more specifically reliability and security.

• Provide an agile framework supporting business-level Service level Agreements (SLA) definition and monitor system behaviour accordingly in order to enforce required non-functional properties of, potentially composite, service execution.

To meet the target objectives in the project timeframe of 30 months, the SEMEUSE consortium groups complementary competencies, from both academia and industry, bringing together experts in all the areas of relevance, namely middleware development, SOA, ESB, semantic service technologies, SLA management, security policies organisation?

The open-source oriented implementation strategy is further reinforced by the expertise of most of the members of the consortium acting as leaders in the field in particular inside the OW2 (http://www.ow2.org) open-source consortium dedicated to middleware.

Organised in an iterative way (first specifications phase, validation phase, final specification) the work will be organised as follows:

• A reference architecture (including both the theoretical design level and the operational ESB platform) provides the necessary integration dimension.

• A semantic description work-package support the ?static? semantic context-aware service description (including functional and non functional requirements) and the way service are stored, discovered and selected.

• A monitoring and orchestration work-package support the dynamic part of the system, i.e. the way monitoring functions are added in a classical ESB to capture the current execution context, the way this execution context is used to select and orchestrate services?

• The necessary tooling functions (design and monitoring tools as well as design by community tools) are developed in a separate work package

• Use cases are used to improve requirements definition and to validate the global architecture.

This project will use the OW2 PEtALS (http://petals.objectweb.org) Enterprise Service Bus and contribute to pave the way for next generation ESB.

Service oriented architecture needs a specified set of components in order to take all its power: I mean allowing business people to defined or modified business processes that automatically update corresponding software code (in term of service orchestration). This last objective shall be seen as the "Holy Grail" of the next decade.

However such approach needs following standardized components: process modeller such as BPMN editor, orchestration engine such as BPEL and service infrastructure such as those provided by an ESB (Enterprise Service Bus).

EBM WebSourcing and others OW2 (http://www.ow2.org/ - former ObjectWeb) stakeholders provide many of those components as detailed below and illustrated by previous figure.

Design tools:

o UML modeller allows manipulating business object exchange between partners. We suggest to use Topcased (http://www.topcased.org) which a very complete UML 2.0 software (even not completely stable) available under EPL (Eclipse Public licence).

o BPMN modeller provide by STP project (SOA Tool Platform) from Eclipse foundation is very valuable (http://www.eclipse.org/stp/bpmn/index.php). It provides an implementation of BPMN specification as provided by OMG (Object Management Group) (http://www.bpmn.org/). The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts who create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes. Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation (cf. Wikipedia at http://en.wikipedia.org/wiki/BPMN).

JBI service engines:

One of the main added value of JBI (JSR 208: http://jcp.org/en/jsr/detail?id=208) standard is to provide a plugin architecture for Enterprise Service Bus that allows to add new components easily as far as there are compliant with JBI specification. Services connect to the container via binding components (BC) or can be hosted inside the container as part of a service engine (SE).

o Main SE for SOA is the BPEL engine. ObjectWeb provides the Orchestra engine compliant with BPEL 1.1 and 2.0 (http://www.bull.com/fr/middleware/orchestra.php). It is available under the LGPL license.

o Main BCs for SOA are JMS in the Java world and SOAP/HTTP for Web Services. This last one is mandatory according to JBI specification. JORAM (http://joram.objectweb.org/) is the JMS compliant implementation provided by OW2.

Execution:

Run-time containers for services are JEE servers and Enterprise service bus. OW2 consortium provides two flagships products: JOnAS (http://jonas.objectweb.org/, J2EE 1.4 certified) and PEtALS as JBI compliant ESB. They are both available under LGPL (http://www.gnu.org/licenses/lgpl.html). PEtALS provides lightweight and packaged integration solutions, based on JSR-208 specifications, with a strong focus on distribution and clustering.

The OW2 consortium (http://www.ow2.org) is an open source community committed to making available to everyone the best and most reliable middleware technology. OW2 mission is to develop open source code middleware and to foster a vibrant community and business ecosystem.
The OW2 Consortium was initiated on January 1, 2007 through the merger of ObjectWeb and Orientware, two leading open source middleware communities of renown industry players, innovative start-ups, prominent academic organizations and individuals from across the world.