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