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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...