Question about 10 Simple Rules for building an ESB Applicati

Item 1

It has been found through experience that reuse and therefore agility in the ESB deployment can be achieved by placing the logic in the appropriate places. For instance if more Service Types are being created then ESB processes it may mean the ESB is not being used correctly or the way in which the service types are designed is incorrect. For instance if I identify use cases such as split by XPath, split by Row number, split by column information etc, I might try initially to create 3 different splitter service types, when what I really should do is create a splitter service that can handle multiple formats. In the first scenario I have 3 Service Types and in the second I have 1 Service Type. Now as I create ESB processes that need a splitter I will use the single splitter service type, configured to the correct behavior and for each process that uses it the count on the right hand side (ESB Processes) goes up. As for the service instances, it could be that the ratio from service type to instances is 1:1 for mediation services such as a splitter, however the ratio may increase if the service type that has been created is connecting to a physical external source or 'On Ramp', such as file polling service. In this case you will potentially need to deploy an instance per physical connection, e.g. an instance to read from the directory c:\myData on a windows host and another to read on \usr\myData on a linux host.

The ratio is determined as a guideline to help you start to follow best practices, obviously if a new service type has to be created for each step in a new ESB process then there is something wrong. Ideally a few well engineered services can be created to increase productivity, reuse etc. If the number of Service Types is greater than the number of ESB Processes it essentially means that you are not making use of the itinerary.

There is no limit on the number of custom processes/service per ESB process. The ratio is meant as a guideline to increase agility through reuse etc, not a physical limitation.

Item 3

An On Ramp is a service, such as file or database polling service, that receives and/or polls for data/events from an external source and places it on the ESB. When placed on the ESB the data will be in an XQMessage format.

Item 9

Within the API of ESB there is the ability to invoke an RPC style request within a service on the com.sonicsw.xq.XQEndpoint interface called call(XQMessage request, long timeout), this maybe used to invoke a single source on the bus and wait for a response. While it is perfectly valid to do this in a service invocation it is unwise to do more than 1, and in fact in about 5 years that I have used the product I may have used this once. Otherwise you are essentially building an Orchestration layer into the service, when one is provided by the itinerary, and as such you will get less out of the box control for error handling etc as the ESB will no longer understand all the calls embedded in your code. So in summary if you use the call() API, only use it once per service and allow the itinerary to provide the orchestration. A better approach is to use a callout service that is configured as part of the itinerary and ignore the call() method all together.

Hope this helps

David

Great, thanks for the response David, that clears everything up!

Hi all,

Just getting started with Sonic ESB. Where can I find a copy of the '10 Simple Rules for building an ESB Application' document?

Best Regards,

Troy

Hi Troy,

Here's the link:

http://www.psdn.com/library/entry.jspa?externalID=1888&categoryID=1220

Thanks Nathan!