servicemix

Hub and spoke vs ESB

2006-07-12T23:55:00.000-07:00

Hub and spoke and ESB are two architectural styles used in the message based applications space.
Here are some distinct differences that distinguish a Hub and Spoke from an ESB based architecture
HUB and Spoke

Central point for availing services like trasformation, routing and transaction management.
HUB (usually a message broker) is a monolithic piece of software.
Capabilities of the HUB cannot be used as pluggable components in another HUB.
Services provided by the HUB and the interfacing between these services is not standart based and is usually proprierty standards driven, leading to a risk of vendor locking.
The hub, being a monolithic piece of software can be used only in a 'all or nothing' mode.

ESB

Central point for availing services like trasformation, routing and transaction management.
ESB provided services are themselves distributed in the sence that different components come and play their role in providing the infrastructure services promised by the ESB.
Specific capabilities of an ESB can be plugged into other ESBs to allow the user to get the benifit of mix and match of services.
Services provided by ESB, deployement and installation of these services and interfacing b/n these services is standard based(JBI).
ESB user can choose which services need to installed and used and which services they want to leave per instance of the ESB.

References
1.http://dotnet.sys-con.com/read/121831_3.htm

2006-07-07T02:22:00.000-07:00

Understanding the 'soap-binding' (http://www.servicemix.org/site/soap-binding-example.html) example

The soap-binding example aims to demonstrate how one can use the Servicemix-http and servicemix-jsr181 components to invoke a pojo object as a web service over HTTP.

Here is a breakdown of what happens when you hit the 'send' button on the client.html page.

When send button is clicked, a javascript function(send()) is invoked.

The javascript function submits an Ajax request to the http endpoint deployed using the serviceunit(binding-su.zip) on the Servicemix-http component.The soap request present in the textfield on the left hand side is sent a parameter to Ajax request.

The Httpendpoint receives the http+soap request and sends the request to the 'proxied' pojo endpoint(proxied endpoint references are shown in bold in the excerpt below) deployed using engine-su.zip over the NMR.

Here is the excerpt from the xbean.xml file under
{Serivemix installation directory}\servicemix-3.0-M1\examples\soap-binding\src\components\soap
http:endpoint service="demo:simple-service"
endpoint="simple-service"
role="consumer"
locationURI="http://localhost:8192/Service/"
defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
soap="true" />

The servicemix-jsr181 receives the request from the NMR and invokes the 'SimpleService' pojo' 'ping' method.

The 'SimpleService' returns the response to the 'ping' method and servicemix-jsr181 sends to response back the Httpendpoint over the NMR.

Here is the excerpt of the implemenation for the ping method
public PingResponse ping(PingRequest request) {
PingResponse response = new PingResponse();
response.setMessage("Ping: " + request.getMessage());
return response;
}

This method prefixes a "Ping:" to request recieved and sends it back as the response

The Servicemix-http sends the response back the browser instance from which the ajax request was sent.

The browser invokes java script function that sets the response field value to the response received.

There are some subtle points to note here

The proxied endpoint is configured using the service="demo:simple-service" and endpoint="simple-service" attributes in the http:endpoint configuration in the binding-su's xbeans.xml file. The values demo:simple-service and simple-service point to service name and endpoint name of the pojo endpoint configuration( service="demo:simple-service" endpoint="simple-service" attributes of jsr181:endpoint configuration) in engine-su's xbean.xml file.

The Servicemix-http and servicemix-jsr181 components are installed at runtime and not using the servicemix.xml file under [servicemix-home]\examples\soap-binding folder.

Endpoints,Service Units and Components

2006-06-22T03:16:00.000-07:00

Servicemix allows deployments in the one of the two following modes

Standard JBI mode
Lightweightmode

Refer this link to get to know what these modes mean.
We will look at the Standard JBI way of installing components in this post.
The JBI specification uses the following terminology Service Unit, Service Assembly, Component,Endpoint and Service.One needs to understand clearly what each of them mean, so here is some help

Component:-- The primary purpose of the components in an ESB is to let the services interact with the NMR and vice versa.The closest analogy that I can draw on the interaction between the component and heart of the ESB, the NMR is that of the device driver and the CPU in a computer. Just as the Device driver is responsible for understanding what action what performed on and what data is provided by the connected device(say a floppy disk), the component is responsible for allowing the NMR to interface with the external of internal service.

Service Engines
Binding Components( All the references to 'Components' going forward in this post are references to Binding Components)

Endpoints:-- Components, as explained earlier, donot provide services or data by themselves.They allow the NMR to interface with the services.
Services that need to be accessed by the ESB are accessed as endpoints.Endpoint is how a service is addressed by the ESB.

Service:- Service is the actual business entity the performs the desired function. In our analogy, the service is the printer or the floppy drive that actually does the work or printing or providing data. Example for a service can be a web service or a EJB component that needs to be accessed by ESB. A service is accessed by the ESB using the address specified in the endpoint. In service mix endpoint information can be expressed in a xbean.xml file. (Refer this link for a sample xbeans.xml file)

Service Unit: Service units provide information about the services and their endpoints to the component.In our analogy, service units deploying a service unit is similar configuring the device type,make and location information for the driver. In the context of components and service units,note the following
The components on which service units are deployed are the called target components for the respective service units.

Service Assembly: Service assembly is how several service units are packaged and deployed on to target components.The service assembly is a archive file that contains a JBI.xml file that provides information about the service units and their respective target components.Here is an excerpt of the JBI.xml file that is used in the service assembly. [target]
[artifacts-zip]sample-su.zip[/artifacts-zip]
[component-name]servicemix-http[/component-name][/target] (* I have used [] instead of <> to have text ignored by blogger)

Now that we have the jargon clarified, lets look at what one actually will have to do to make a service accessible using servicemix?

Define your service as an endpoint in an xbeans.xml file(Refer the XBean deployment section of http://servicemix.org/site/servicemix-jms.html for a sample of endpoint configuration for JMS)

Create a service unit by adding the xbeans.xml file to a zip file(say serviceunit.zip).

Create a jbi.xml as specified in step 2 under Manually Creating a Service Unit and Service Assembly section in this article.Create a service assembly by adding the jbi.xml created,serviceunit.zip created in step 2 (above) to a zip file(say serviceassembly.zip)

Place the serviceassembly.zip in the deploy directory under {servicemix home}/bin directory (Note that servicemix-jms component will have to installed before you deploy the service assembly)

Check for the endpoint deployment using the JMX console.A node is displayed as added under the endpoint node.

Your service is now accessible to other services and components that are interfacing with service mix.