On 21/01/2008, Wilson <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Well, I am new to ESB approach so maybe I am not thinking the right way to
> meet the requirements.
>
> I will try to list my requirements for the project I am working on:
>
> ---------------------------------------------
> - The same system will be installed in several nodes in distinct networks.
> The nodes are connected using the Internet.
>
> - Each node needs to exchange information with each other. I think that
> HTTP is the obvious choice for the message exchange. The bigger part of the
> exchanges can be inOnly and asynchronous but I need to make sure the message
> will be received by the target node.
>
> - The nodes need to send messages to third party web services. If these web
> services are down or slow the nodes must keep sending the inOnly messages
> normally. The ESB must hide any problems related to the third party web
> services. Message lost is not allowed.
>
> - The message exchanges must be secure so I want to use HTTPS.
> ---------------------------------------------
>
> I am planning to use an ESB server running Camel or Servicemix or both. The
> ESB server will control all message exchanging.
>
> My idea is to put queues in front of the web services. When a node send a
> message (via SOAP), the ESB will put it in a JMS queue and send acknowledge
> back to the sender. Another endpoint will consume from the JMS queue and
> send the SOAP request to the third party web service. This way if the third
> party web service is down or slow the client can keep sending messages.
Thanks for the heads up.
If your requests with the external web services are InOnly then using
a JMS queue makes loads of sense. If they are InOut (request/response)
and you have some client code which is synchronous in nature, its
maybe not a huge win to use JMS in between (as you have a thread
blocking waiting for the response) as if the box with the thread on it
dies you can't really recover.
You might instead want to use a JMS queue to start the entire task off
of interacting with the external web service; so that the entire task
can be easily retried. (A similar technique is common for things like
sending email).
e.g. send a message T to a queue to initiate the conversation with the
external web service.
Then the JMS consumer takes the T message off the queue and tries to
invoke the external web service - and it keeps retrying until this
succeeds, then when it does, it sends the response to some other
queue. This avoids you having to write your code interacting with the
external service in a very asynchronous way.
e.g.
void onMessage(Message) {
while (shouldRetry) {
boolean worked = false;
try {
// some synchronous code here interacting with the external service
externalService.doSomething(...);
worked = true;
}
catch (Exception e) {
// something went wrong - is external service there?
}
if (worked) {
// send some result to a JMS queue?
return;
}
// failed to process so rollback...
}
It also means if someone kills the machine/jvm thats running the retry
thread, it will get redelivered onto another machine (or later on to
the same machine when its restarted) so you get reliable interactions
with the external service, while still preserving simple
single-threaded code interacting with the service and full
recovery/reliability is supported too
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
