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

[mark.little@jboss.com]

"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#3990911

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