Remoting JBossAS integration - next steps

[adrian.brock]

I'd like to start a discussion on the next phase of JBossAS/Remoting integration.

In particular, I'd like to know where we are in terms of clustering and "sharing"
or "not sharing" connections across applications for a given client and configuration.

e.g. I'd like to be able to setup something like (this is pseudo code)

java.naming.factory.initial=org.jboss.remoting.NamingContextFactory
java.naming.provider.url=socket:///?cluster=DefaultPartition

That forms the bootstrap of the client's requested connection attributes.
From this, serialization across that connection with that client will continue
to use the same "locator"/transport/connection no matter what the client does
* EJB
* JMS
* JMX
* AOP
* etc.

Unless there is specific configuration serverside that says to switch to
a different protocol/locator. e.g. JMS is on a subpartition

socket:///?cluster=JMSPartition

[adrian.brock]

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".

[adrian.brock]

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? :-)

[tom.elrod]

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.

[adrian.brock]

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".