3 Replies Latest reply on Aug 8, 2003 9:05 PM by deanhiller

    Where and what should be included in remoting

      On the dev mailing list there has been some discussion on where and what should be included in the remoting and jboss build. As it stands right now, remoting is part of core because it is part of jmx (to provide jmx remoting). I'm not sure that it is used anywhere else currently, but think the plan is to use the generic remoting transport for all the sub projects, to gain consistency.

      Since the inherent purpose of remoting is to provide a transparent transport layer to provide remoting of services and POJOs, as well as detection of these, it make sense that there are (and will continue to be) a wide assortment of transport and protocol layers used.

      Thus we have a problem, since we don't want all this extra stuff in core (i.e. SOAP, JNP, etc.). There are many different ways to solve this, so please post your suggestion. Mine is to remove remoting from the core jmx and make it (yet another) a sub project dependant on both remoting and jmx. This will get remoting out of core and allow us to put in any of the extra protocols into the remoting project. Another solution would be to make the remoting project so that it will allow users to specify what they want included (not sure what to do about compile time though). This route will require a standard approach for configuring the what it to be included (anyone want to take this on?).

      -Tom

        • 1. Re: Where and what should be included in remoting

          Aren't the transports and protocols plugins to the
          remoting abstraction? They don't have to live in
          the remoting module.

          Regards,
          Adrian

          • 2. Re: Where and what should be included in remoting
            jhaynie

            yes, you're right. however, we've included some standard transports, detectors in remoting so they're available out-of-the-box. i would imagine as it grows, each component might have different transports, etc. to handle their component specific remoting needs.

            • 3. Re: Where and what should be included in remoting
              deanhiller

              I personally think it should be kept separate, but I am biased because I may want to use for something completely unrelated to JBoss. I wanted to see the code first though. Can't seem to find the remoting package in org/jboss directly like the JBossRemoting.pdf says though.

              I personally have been trying to figure out a way to separate my api and my transport protocol for some time and haven't yet run into anything I like, nor come up with anything I like either. There tends to be so much trouble especially dealing with cleaning up listeners when a particular client goes away. It is a very interesting problem though.