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

[mark.little@jboss.com]

"estebanschifman" wrote : 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)
  | 

In that case, the queue is part of the service. The service encapsulates everything from the high-level business object down to the communication infrastructure. Whether or not the business object (or even listener in our case) is active is immaterial as long as the recipient of the message is active. We don't make a distinction between the receiving of a message and acting upon it.

Whether or not an EPR has to be removed from the registry in this case is implementation dependant. WS-RX would suggest you do not have to, for example, with SOAP/JMS, but you must with SOAP/HTTP.

anonymous wrote : 
  | 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.
  | 

I think if you take the definition of the service to be everything I've outlined above, then whether or not you remove an EPR from the registry does come back to: you remove it if the service is out of order, because the queue is part of the service and in this case the queue is down too. If the queue remains up, but the listeners/objects/whatever that do the real work aren't there yet (maybe they are created lazily upon receipt of a message) then the service is still "up".

anonymous wrote : 
  | 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 listener is part of the service in this case.

anonymous wrote : 
  | 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 ?)
  | 

As I said earlier, our definition of a service is not quite right and is unlikely to be so for this GA because it will almost certainly need changes to the architecture. However, what we have so far is certainly good enough for users.

anonymous wrote : 
  | 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.
  | 

No. Durability is not an administrative issue. It's an implementation issue. Put simply, the basic rule is:

(i) when a service comes up (something can receive a message), the EPR is registered with the registry.

(ii) when a service goes down (messages that are attempted to be delivered will return a failure to the sender), the EPR is removed from the registry.

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

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