5 Replies Latest reply on Nov 25, 2008 9:04 AM by Julien ZANON

    remoting-https-service configuration

    Mr Dude Newbie

      Hello

      I am on trail of a problem that I am facing with JB Messaging and Remoting; Tim from messaging forum suggested that I post here to perhaps resolve this.

      http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4098850#4098850

      Summary of my problem is that I am unable to connect/send JMS messages to a remote machine due https remoting configuration. More details is as follows:

      My env...
      OS: WinXP
      Java: 1.6
      JBoss AS: 4.2.2 GA
      JBM: 1.4.0.GA

      Following is the config part for HTTPS from both remoting-https-service.xml and connection-factories-service.xml files.

      For MQ only SSL port (443) was used for all the JMS communication between client and server. I see that for JBM + Remoting it uses one more port other than regular SSL port, 9443 in this case as configured in remoting-https-service.xml. Furthermore, in my case - the server machine only has 443 open and all the other ports are blocked (the network folks gives me the "hairy eyeball" treatment for requesting to open any other port). They ask why can't you configure it so that all the comm takes place using just port 443.

      So considering the above, what do you recommend? Is it possible to configure the server so that it uses only port 443? BTW I tried changing the bind port in the "remoting-https-service.xml" to 443, but as expected, the server complained at startup that the port is already occupied etc...

      Thanks for your help in advance.

      connection-factories-service.xml

       <mbean code="org.jboss.jms.server.connectionfactory.ConnectionFactory"
       name="jboss.messaging.connectionfactory:service=HTTPSConnectionFactory"
       xmbean-dd="xmdesc/ConnectionFactory-xmbean.xml">
       <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
       <depends optional-attribute-name="Connector">jboss.messaging:service=Connector,transport=https</depends>
       <depends>jboss.messaging:service=PostOffice</depends>
      
       <attribute name="JNDIBindings">
       <bindings>
       <binding>/HTTPSConnectionFactory</binding>
       <binding>/XAHTTPSConnectionFactory</binding>
       <binding>java:/HTTPSConnectionFactory</binding>
       <binding>java:/XAHTTPSConnectionFactory</binding>
       </bindings>
       </attribute>
       </mbean>
      




      remoting-https-service.xml

      <server>
      
       <!-- Standard bisocket connector - the bisocket transport only opens connection from client->server
       so can be used with firewalls where only outgoing connections are allowed.
       For examples of HTTP and SSL transports see docs/examples -->
      
       <mbean code="org.jboss.remoting.transport.Connector"
       name="jboss.messaging:service=Connector,transport=https"
       display-name="HTTPS transport Connector">
      
       <attribute name="Configuration">
       <config>
       <invoker transport="https">
       <attribute name="marshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute>
       <attribute name="unmarshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute>
       <attribute name="dataType" isParam="true">jms</attribute>
       <attribute name="leasePeriod">10000</attribute>
       <attribute name="socket.check_connection" isParam="true">false</attribute>
       <attribute name="callbackStore">org.jboss.remoting.callback.BlockingCallbackStore</attribute>
       <attribute name="callbackPollPeriod" isParam="true">102</attribute>
       <attribute name="clientLeasePeriod" isParam="true">20000</attribute>
       <attribute name="serverSocketFactory">jboss.messaging:service=ServerSocketFactory,type=SSL</attribute>
       <attribute name="SSLImplementation">org.jboss.remoting.transport.coyote.ssl.RemotingSSLImplementation</attribute>
       <attribute name="serverBindAddress">${jboss.bind.address}</attribute>
       <attribute name="serverBindPort">9443</attribute>
       </invoker>
       <handlers>
       <!--
       <handler subsystem="web">org.jboss.remoting.samples.http.WebInvocationHandler</handler>
      
       <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler>
       -->
       <handler subsystem="JMS">org.jboss.jms.server.remoting.JMSServerInvocationHandler</handler>
       </handlers>
       </config>
       </attribute>
       <!-- This depends is included because need to make sure this mbean is running before configure invoke
      r. -->
       <depends>jboss.messaging:service=ServerSocketFactory,type=SSL</depends>
       </mbean>
      
      </server>
      


        • 1. Re: remoting-https-service configuration
          Ron Sigal Master

          I assume that port 443 is being used by JBossWeb (i.e., tomcat) - is that so? I don't know anything about JBossMQ, but I'm guessing it ran behind a servlet, so that the only port opened was that used by tomcat.

          Now,

          1. The Remoting http transport borrows the networking layer of tomcat, which includes opening up a ServerSocket, running worker threads, etc. So, necessarily, it needs its own port.

          2. Remoting also offers the "servlet" transport, which runs behind a servlet. In this case, the network i/o is handled by tomcat, so a second port is unnecessary.

          I've never tried to configure JBossMessaging to work with the servlet transport, but, in principle, it should work. I'm going to point you to Sections "5.4.11. Servlet Invoker" and "5.4.12. SSL Servlet Invoker" of the Remoting Guide http://labs.jboss.com/jbossremoting/docs/guide/index.html. If the servlet transport looks reasonable to you, and you have problems, I can try to help you through them.

          I should note that as of Remoting release 2.2.2.SP2, there's a new, currently undocumented, feature of the servlet transport, described in JIRA issue JBREM-813 "ServletServerInvoker should return an exception instead of just an error message" (http://jira.jboss.com/jira/browse/JBREM-813). I don't know, but it might turn out to be useful.

          Good luck!

          • 2. Re: remoting-https-service configuration
            Mr Dude Newbie

            Thanks for such quick response Ron.

            Pardon my ignorance but if accessing JMS over HTTPS requires the server to open up another port aren't we defeating the purpose of calling it JMS over HTTPS or anythingelse over HTTPS? The IT czars of any respectable organization would frown upon such request. Also if this is the case, how is it different from an applet or an rich client application requesting to communicate with the server using some arbitrary port? Wouldn't this pose a security risk?

            I've tried your SSL servlet invoker option with very less success. Anywho, since I am in a tight schedule bind, I think I am going to resort back to JBoss 4.2.2 with MQ.

            Thanks much

            • 3. Re: remoting-https-service configuration
              Julien ZANON Newbie

              Hi,

              I've the same problematic of monk2005. Does remoting provide now a simple way to use JMS (Jboss Messaging) over HTTPS without using a dedicated port?

              • 4. Re: remoting-https-service configuration
                Ron Sigal Master

                I see that the JBossMessaging group has now scheduled JBMESSAGING-1131 "Add configuration for Remoting servlet transport", which I created about a year ago. If you look at the issue, you'll see configuration files that should allow JBM to work with the Remoting servlet transport, which uses the tomcat port.

                • 5. Re: remoting-https-service configuration
                  Julien ZANON Newbie

                  Thanks for your reactivity.

                  We can't base our application on a functionality not supported by JBM.
                  Jboss encourages usage of JBM instead of JBoss MQ for a long time ago, but a functionality (vital for us) proposed by MQ has just been scheduled 2 days ago for JBM!

                  I am going to resort back to JBoss 4.2.3 with MQ. :-(