DSB Core Management

Version 16 by Christophe Hamerling
on Oct 06, 2011 17:19.

<< Changes from 15 to 16

compared with

Current by Christophe Hamerling
on Apr 24, 2012 13:36.

Key

This line was removed.

This word was removed. This word was added.

This line was added.

Changes (4)

View Page History

...

{toc:outline=true}
The first goal of the DSB management is to hide all the JBI complexity by wrapping and provided some JBI independant APIs and solutions. Another important goal is to hide the kernel management originally based on JMX and to provide a Web service management API.

{info}In the next sections we will refer to the DSB distribution folder with the _$DSB_HOME_ variable even if it is not set in the system environment.{info}

h1. API

The management API is available in the _dsb-kernel-wsapi_ module. It allows to manage business services, but also to manage the DSB kernel : router, registry, monitoring, ... By default, the management API is exposed as Web services at DSB startup on [http://localhost:7600/petals/ws]. The complete list of available service is provided by the getWebService operation on the DSBInformationService service available at [http://localhost:7600/petals/ws/DSBInformationService] (complete list also available at [http://localhost:7600/petals/ws/DSBInformationService/getWebServices]).

h1. Features

h2. {color:#492562}{*}Components{*}{color}

h3. Startup

We assume that we do not need to deal with JBI components and let the Service Bus manage them. To achieve this, we introduced an artifact repository file implementation where JBI artefacts are stored on the Service Bus side. This artefact repository is available under _$DSB_HOME/artifacts/_ and is splited into 3 parts : components, sa and sl.

The components available under _$DSB_HOME/artifacts/components_ can be automatically started at DSB startup by filling the _embedded.component.list_ property in _$DSB_HOME/conf/dsb.cfg_. For example, if the dsb.cfg file is filled like :

{code}
# Components to start as CSV
embedded.component.list=petals-bc-soap,petals-bc-rest
{code}
and if the SOAP and REST components are available in the components folder, they will be started automatically when the container starts (no more JBI lifecycle management for these components is needed).

h3. Configuration

We forked the standard Petals ESB components to be able to configure them more easily and to share information between the container and the components. This section introduces what type of configuration is possible for the DSB components. Especially, we introduced a new way to define ports : instead of having to modify the components themselves (the jbi.xml component) or to have to deal with some JMX calls which are not compliant with the easy approach we want to have, component ports can be configured in the _$DSB_HOME/conf/components.properties_ file like this :

{code}
petals-bc-soapproxy.port=8083
petals-bc-soap.port=8084
petals-bc-rest.port=8082
{code}

h2. Web Services

The DSB can be managed from remote clients using the Web Service API detailed above. The initial goal of the Web service API is to hide the JBI layer which is not Internet-friendly (even if some JBI aspects are used and will be explained in this section). This section gives details on how to use the Web service client library.

h3. {color:#492562}{*}Deploy a JBI Service Assembly{*}{color}

A JBI Service Assembly (SA) can be uploaded to the DSB artefact repository (a folder in the default implementation as described earlier). Once the SA is uploaded, one can call the SA lifecycle operations on the uploaded SA.

A code sample is available at ([http://chamerling.org/2010/04/12/librairie-cliente-pour-petals-esb/])

h3. Bind and Expose Services

A more easy way to work with services is to let the DSB the responsability to configure itself in order to bind or expose services as it can be done with the help of JBI SAs. The default implementation of the DSB comes with a management API which is dedicated to that. By using this Web service API, you just use standard SOAP client or library to communicate with the Management layer of the DSB.

Some utilities based on top of the previously mentioned API are also available to preconfigure the DSB at configuration time. With their help you are able to define sets of services which will be automatically bound to the DSB when it starts.

h4. 'Design' Time

In order to predefine a set of services to bind at startup, a simple properties file located under _$DSB_HOME/conf/services2bind.cf{_}g is defined as:
{code}
# A list of services to bind at startup
# The key MUST start with the protocol to use to bind the service and MUST be unique in this properties file
# CSV Values are also possible

#soap.0=http://localhost:8080/services/Ping?wsdl
#soap.1=http://localhost:8080/services/Pong?wsdl
#rest.0=http://localhost:7777/rest/Weather

soap.proactivespace=http://ns306320.ovh.net:8090/soa4all-space-proactive/ws/ProactiveSemanticSpaceWS?wsdl
soap.owlimspace=http://94.23.221.97:8080/soa4all-space-owlim/ws/SemanticSpaceWS?wsdl
rest.yahooweather=http://weather.yahooapis.com/

#example of service list as CSV
soap.list=http://foo.com/bar,http://bar.com/foo
rest.list=
{code}

In the previous configuration snippet, 

h4. Runtime

h5. SOAP-based Services

The DSB SOAP Component is in charge or binding external services to the bus and to expose DSB services as SOAP services. This can be done by using a collection of Web services embedded and provided by the DSB itself.

In order to bind an external Web service, simply call the _bindWebService()_ operation of the _SOAPServiceBinder_ DSB service with the WSDL URL of the service to bind as parameter. As a result, a new endpoint will be created in the DSB and each time a message is received on this DSB endpoint, it will be forwarded to the real Web service (the one you bound).
{info}TODO : Example with WSDL and resulting endpoints{info}

h2. Registry

The registry can be managed in several ways with the management API. Main features are the capability to:

* retrieve endpoints from the EndpointService : [http://localhost:7600/petals/ws/EndpointService]

* manage [registry listeners|petalsdsb:Adding Registry Listeners] (pause/resume/...) : [http://localhost:7600/petals/ws/RegistryListenerService]

h2. Router

As described in the [router section|petalsdsb:Adding Router Modules], the core routing engine is composed of several modules called by the kernel on message emission and reception. One can use the management API to manage these listeners (pause/resume/...) directly from [http://localhost:7600/petals/ws/RouterModuleService].

PetalsDSB Overview

DSB Core Management

Changes (4)