Just to be clear, here's an example...
* Client connects to JNDI using HTTP
* Client retrieves JMS ConnectionFactory and creates JMS connection
* Server sends a JMS ObjectMessage that has an EJB proxy embedded inside
All this (including the EJB proxy) should just the use same the "HTTP connection"
setup during the initial JNDI handshake.
I quote "HTTP Connection" because obviously the connection might not be
persistent and it might be "clustered".
Unless there is specific configuration serverside that says to switch to
a different protocol/locator. e.g. JMS is on a subpartition
I'd also like to talk about the using different implementations of the discovery service
to identify cluser views. e.g. using a jgroups gossip router to refresh views
when the client is not talking to the server.
But that is probably a topic for another thread? :-)
On the server side, is certainly possible to have one connector (with whatever transport flavor such as http you like) with multiple handlers (one defined for ejb subsystem, one for jms subsystem, etc.).
The only issue then would be on the client. The client would need to have the locator url to that server endpoint. For example, http://myhost:8088. The specific client (for ejb or jms) would need to specify which subsystem it wanted to handle its call as well (which is not tied to the locator url).
Not sure how clustering fits into this? Not sure what you mean in regards to that?
Let's talk about discovery on another thread.
Ok, but how/where do I say all requests by default should stay "sticky"
to the original client connection?
I don't believe this is possible at the moment?
Clustering fits in, because I want the client to be able specify the initial locator
as a logical identifier that gets translated into cluster view, the real urls, see above.
This translation may originally be done by the "discovery".