"estebanschifman" wrote : When Mark first explained the concept of EPR to me, he
assimilated an EPR to a simple 'address'. If many people live in the same
address, even in the same apartment/suite, and we are looking for one of them in
particular, we need to know the name of the person we are seeking (UID). One address,
many people = one EPR, many UIDs
|
Check out the paper I referenced in my last post. In a SOA, the fact that there are many
"people" in the service would be encapsulated within the message. Mixing
metaphors, you'd send the letter to the house; the letter is within an envelope that
has the house address on it and within the letter is the identity of the ultimate
receiver. Services are course grained entities, not fine grained objects. It's the
service that is registered with the registry, not the individual
elements/threads/objects/components within it.
anonymous wrote :
| I don't share the description of many listeners in the same EPR being
"...hundreds of EPRs...". It is the very same EPR with hundreds of listeners
servicing it:
|
Now this may be slightly different. If we're talking about the same service that is
accessible through different message delivery implementations, then it's the same
service, with different EPRs.
I suspect that our definition of a service in 4.0 is not perfect at this stage. But this
is only our first GA release after all.
anonymous wrote :
| each registration with a unique identifier. This concept is independent of if the
many listeners are several threads in the same JVM, or distributed in disparate address
spaces.
|
A single VM can host many services. If each listener is a unique service, then it should
definitely have a different EPR to other services within the same VM as well as a
different service name. If each listener is logically tied to the same service (business
logic, implementation object, etc.) then they will all have different EPRs but the same
service name.
Here's an example: I have a single process on my machine that provides a Web Service
transaction service and a shared calendar. The WS-T service can only be interacted with
via SOAP/HTTP because that's the only binding defined by the standard. Within the WS-T
service, there are many different threads running to do work, e.g., start transactions,
commit transactions etc. However, those are back-end implementation choices. The WS-T
service is known by a single service name and has a single EPR for contacting it
initially.
Now the calendar service is available on SOAP/HTTP, but also plain HTTP and JMS, because I
want it to be available to a wider range of clients. This means that it is known by 3
EPRs, but all keyed to the same service name.
anonymous wrote :
| If this is solved with one entry, or hundreds, in the registry underlying repository,
it will be completely hidden for the user. They could't care less.
|
Yes, users don't care what the EPR looks like (in fact, a lot of it is supposed to be
opaque to a user and only of use to the receiver, i.e., the service). Users will typically
look up an EPR given a service name.
anonymous wrote :
| Having a UID added to the registration process would not alter the underlying
architecture of alpha1.
|
If you really mean Alpha1 as in the code prior to Rosetta, then it would change the
architecture, because it appears as though the need for these threads to do the
registration is not based on the same definition of a service.
anonymous wrote :
| It would be a requirement of the registration API. That's why in a post on the
public forum I made on friday, there was a suggestion for the Registry to return a UID at
registration time, and that same UID be required at de-registration time.
|
Each service should register itself once with the registry and deregister itself only when
it goes out of service(!) If each listener is bound to the same service, then obviously we
need to support multiple EPRs per service name, but I believe we already do that.
Why do we re-register/de-register when the listeners re-read their configuration
information?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990911#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...