[jboss-dev-forums] [Design of JBoss ESB] - Re: Multithreaded services and their EPR(s)

[estebanschifman]

Here's yet another twist to the same problem:

The way we are using the registry today is to add an entry when a listener comes up, and remove it when the process stops listening.  Some of us have talked about potential benefits of having entries in the registry that  go beyond the uptime of any particular listener (or listener instance).  This could be the case for all Message transports that are themselves 'durable':  local or remote filesystems, JMS and other 'guaranteed delivery' messaging systems, sql tables, e-mail, etc.    The listener does not need to be up and running for invokers to send a message to that EPR (provided that the service is not expected to give a response in 'near real time':  that the service is asynchronous)

We also have transports that require a listener to be up and running (e.g. sockets).  I think that in most of these (if not all of them) the conversation flow between invoker and provider will be bidirectional.  Entries for these listener's EPR must thus be dynamic, so (just as our listeners do today) they must register as soon as they're ready to provide the service, and de-register before they finish.

This is also the case for those services that, even on 'durable' transports, expect a synchronous response.  A good example of this is how the CbrProxy action class interacts with the content based router service: JMS as transport, but invoker will wait until a response comes back.

My guess is that when the service does not require response (not even an acknowledgement that a Message has been received), and the EPR transport is durable, we could (may be we even must) do with a 'durable' Registry entry.  Listeners servicing such an entry would use the Registry not to register themselves, but to find out where to go pick up their incoming messages.  The rest of services (ack or response required, or volatile transports) need register themselves whey they're ready to listen, and unregister when done (a volatile registry entry).

This surfaces the need for a friendly interactive way for administrators to add/change/remove durable entries to the registry.  A simple call to the appropriate method in the registry API would suffice, but it might be useful to have a friendly user interface so ESB administrators could do it.  (Kurt:  is there an off the shelf juddi user interface that we could use ? Or do we have to develop our own registry browser/editor ?)

Having said all this, we might not need at all a UID for the registration process. Durable registry entries would not need it as they would be manually handled by the ESB administrator.  Volatile entries not only don't need it, but should check if there's an entry for the same EPR they're about to register.

The next question would be if we need the registry to 'know' the difference between durable and volatile entries. When the time comes to have a sophisticated registry browser it might be useful to see which are and which are not durable.  We might also require that volatile entries 'refresh' themselves every so often or else be purged by a clock driven process.   This would avoid dead or zombie processes leaving behind stale registry entries.





View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990899#3990899

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990899