{center}
{flash:file=Architecture^soceda_architecture.swf|width=581px|height=486px}

any knowledge on the final service location and transport protocol. It is up to the service bus to route the message to the right service and to send back the response to the right consumer. All the location and routing knowledge is located at the SOA layer level.
* *Service Binding*: The DSB provides the core functionality to bind external services and to expose internal service with the help of binding components. All the transport and
transformation logic to address specific protocols and final endpoints are located at this service binding level.
* *Standards compliant*: The DSB extensively uses and implement the OASIS and W3C standards to provide most of its core functionality
** WSDL: The Web Service Description Language is used in the DSB to describe all the services which are used and available
** OASIS WSN: The Web Service Notification standard is implemented in order to provide the core EDA feature.
** OASIS WSDM: The Web Service Distributed Management is used to monitor services invocations.
** WS-Agreement: Used to define Service Level Agreements (SLA) and extended to define Event Level Agreements (ELA).
* *EDA*: The Event Driven Architecture feature allow to connect event producers and event consumers to the service bus infrastructure.
* *Polling Engine*: The goal of this core component is to easily connect standard request/response services and to transform them as event producers. The component will be in charge of polling services and to wrap the service responses into WS-Notification messages.

h2. Functionality

The core functionality needed from the DSB are Services binding: The SOA layer will provide this functionality to connect business services to the platform.
* *Event consumer/producer binding*: Based on the SOA layer, the EDA layer will be able to connect event producers and consumers to the platform. The protocol and message transformation between the event environment and the service one will be taken in charge by the event component.
* *Distributed*: Addressing high number of producers and consumers will need a distributed feature.
* *Federated across domains*: The service bus will need to be able to connect producers and consumers distributed across private and public domains.
* *Internet compliant*: The service bus needs to be create communication links over the Internet.
* *Monitorable*: The service bus needs to provide some monitoring sensors which will be gathered by the governance tool to enforce agreements (SLA and ELA ones).
* *Manageable*: APIs to manage to service bus must be provided.
* *Extensible*: New providers and consumers must be connected to the platform without the need to restart and to loose connectivity to other services actors.

h2. Technical Requirements

The Distributed Service Bus needs Java 6 or higher to run. On some node deployments, specific network ports needs to be open to enable node to node communication.
The Source Code is available at: [https://svn.petalslink.org/svnroot/trunk/research/commons/dsb]

{prerequisites}

If you want compile without run all tests, write: *mvn install \-Dmaven.test.skip*
{tip}

h2. Components Architecture:

!dsb.png|align=center!

The DSB is composed of 3 sub components:
* [BPEL Engine|soceda:Workflow Engine]: able to deploy business orchestration and bind WS Providers between them.
* [soceda:Proxy Event Manager]: able to maintain the list of Event Producers for a given topics. It can be considered as a broker for Event Producer.
* [soceda:Adaptation Service]: able to adapt and reconfigure oan instance of BPEL process when a specific events occurs