The [Distributed Service Bus (DSB)|petalsdsb:PetalsDSB Overview] developed within the Soceda project is an extension of the open source Entreprise Service Bus provided by [PetalsLink |http://www.petalslink.com/] called [Petals ESB|http://www.petalslink.com/produits/petals-esb]. The distributed feature will be described later in this section and will highlight the need of such feature at the infrastructure level.
The DSB provides the SOA and EDA infrastructure for the so-called platform components and for end user services. The DSB aims to provide connectivity between services providers, services consumers, event consumers and event providers, potentially distributed over distinct administrative domains, in a completely transparent way on the user point of view. The core features of the DSB are listed below:
* *SOA*: The DSB provides a core SOA layer which will be the basis of all other DSB components. On the client side, the SOA layer provides a way to invoke services without
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]
h2. Components Architecture:
{children:excerpt=true}
The DSB provides the SOA and EDA infrastructure for the so-called platform components and for end user services. The DSB aims to provide connectivity between services providers, services consumers, event consumers and event providers, potentially distributed over distinct administrative domains, in a completely transparent way on the user point of view. The core features of the DSB are listed below:
* *SOA*: The DSB provides a core SOA layer which will be the basis of all other DSB components. On the client side, the SOA layer provides a way to invoke services without
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]
h2. Components Architecture:
{children:excerpt=true}