incubator-wadi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <>
Subject Re: Destination maps to Node or Service....
Date Sat, 04 Feb 2006 03:59:30 GMT
Hi Jules,

With respect to the support of multiplexed connections, I think that 
this is already done: a Dispatcher can be safely shared across multiple 
services as long as these services do not register for the same type of 
message body. The only update which seems to be required is to remove 
Dispatcher.start and Dispatcher.stop from ClusteredManager.start and 
ClusteredManager.stop respectively. If this does not scale well when the 
number of services increases, then we can provide a 
MultiConnectionCluster to replace DefaultCluster.

I am happy with the level of abstraction provided by Node, Cluster and 
Destination. Having said that, I think that when trying to implement 
basic services, these notions are too low-level. So, we may want to 
provide an higher level of abstraction to simplify the implementation of 
clustered services.

This is what I have in mind:
* register a service via Dispatcher by providing some basic meta-data 
such as a service address and name;
* upon registration, Dispatcher notifies the cluster that a service has 
joined the cluster;
* a client relying on a clustered service obtains from Dispatcher a 
service destination; and
* this service destination is transparently updated when a service joins 
or leaves the cluster.

AFAIUI, there is a OTO mapping between Destination and Node (when a 
message is sent to a destination it is sent to the Destination of a 
Node) and a OTM mapping between Node and services (a node hosts multiple 
services). In most cases, when we send a message having a given payload, 
we actually want to send this message to a service supporting the given 
payload. So, in most cases, I think that a developer does not really 
care about the JMS Destination(s) of the service. I think that a 
Developer says: sends that to this service destination, and I let you 
derive the JMS Destinations of the node hosting the service. So, what we 
could have is a ServiceDestination which can be mapped to multiple JMS 
Destination. So basically, we would end-up with e.g.:
ObjectMessage exchangeSend(ServiceDestination to, Object body, long 

Note that ServiceDestination may or may not extend Destination. And I 
would prefer to have ServiceDestination not extend Destination as a 
ServiceDestination can actually be many JMS Destination.


Jules Gosnell wrote:

> Gianny,
> I decided that this was of wider interest so have posted Geronimo dev 
> about it.
> For WADI, although you convinced me to raise the level of abstraction 
> above a JMS Destination, after further thought, I think we can raise 
> the level of abstraction from Node to Service without having to change 
> the API - Cluster and Destination are already abstract enough to 
> express this stuff... - see my posting on g-dev where I suggest that 
> we allow multiplexed connections etc...
> If, as far as WADI is concerned, we go this route (I haven't thought 
> about it deeply yet, so there may be semantic issues that are not 
> easily resolved), then I still don't see a good reason for losing the 
> dependency on javax.jms.Destination - other than its pulling in the 
> whole JMS api as a dependency, which AC and AMQ will do anyway....
> What do you think ? Can you still make good technical case against the 
> use of Destination in WADI code ? If you just replace it with another 
> Abstraction (e.g. Address or RemoteService etc...), what have we gained ?
> Over to you :-)
> Jules

View raw message