4 Replies Latest reply on Aug 23, 2005 12:41 PM by adrian.brock

    Remoting JBossAS integration - next steps

      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


        • 1. Re: Remoting JBossAS integration - next steps

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

          • 2. Re: Remoting JBossAS integration - next steps

             

            "adrian@jboss.org" wrote:

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

            • 3. Re: Remoting JBossAS integration - next steps

              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.

              • 4. Re: Remoting JBossAS integration - next steps

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