"kurt.stam(a)jboss.com" wrote : 1. I think we agree that the registration of the
EPR should *not* be done in the thread.
|
| 2. However as Esteban pointed out that if we register multiple listeners in different
address spaces we still have a problem. And I think it is actually useful to know from a
registry position that we have mutliple physical listeners, for load balancing and
failover scenarios. So should we have these listeners register as 'different' EPRs
of the same service?
|
| --Kurt
First, I've mentioned this several times, but this paper
http://http://www.orablogs.com/pavlik/archives/The-Session-Concept-in-Web... is
extremely important to the general debate on EPRs and Services (don't let the title
fool you - it is relevant to our architecture]. Although an EPR is an address, it should
NOT be an object-level address (c.f., CORBA IORs). That is the way to close-coupling of
clients to services. We need to maintain a loose-coupling. Things like multiple threads in
the same "service" are back-end implementation issues. If I have multiple
objects within my service and they are able to be dispatched too separately then that
information should be encoded within the body of the message and not in the EPR.
WS-Addressing lets you do the latter, but then you end up with something like WS-RF which
is essentially the CORBA object-key approach. This leads to brittle applications in that
if we change the way the back-end implementation works, the EPRs that all clients have
then need to change.
Everyone should read the paper.
As for clustering support, that's an interesting question. Logically we want a single
service name that can map to multiple EPRs. (Let's ignore the issue of stateful versus
stateless services at this point, because that really does complicate the discussion -
we'll assume stateless). It could be supported with multiple EPRs registered with the
same service name within the EPR (c.f., DNS). Alternatively, you could have a single EPR
and use CBR to dispatch across different physical endpoints. Obviously the CBR would then
need to maintain the mapping information. There are trade-offs to both approaches. For
now, we don't support clustering so we can leave this as an excercise for the informed
user of JBossESB 4.0 GA.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990907#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...