5 Replies Latest reply on Nov 11, 2004 11:41 AM by infectedrhythms

    Using Jboss MX Kernel for custom apps...


      I think I already know the answer to this and am very excited... :)

      Currently I write my own server applications that receive "requests" through tcpi/ip and send thoses requests to 3rd parties in real time...

      So bassicaly my server app receives a request, send request to 3rd party, gets response from 3rd party and send response back to "client"

      So I was thinking that I can use the minimal config of Jboss and write my "server" app as an mbean.

      So the answer yes :) But what do I need to know to implement, say for now a simple hello world mbean for the MX kernel?

      I would also need my mbean accessible throught corba using c/C++ client application so I guess I would be able to take advnatge of JBoss's rmi/iiop service right?


        • 2. Re: Using Jboss MX Kernel for custom apps...
          Dimitris Andreadis Master

          Check out:

          for writing simple services and
          to get a basic installation that includes the jmx-console.

          Regarding CORBA, you are better off writing you own CORBA server object, controlled through an MBean of yours and using the ORB provided by the CorbaService.

          • 3. Re: Using Jboss MX Kernel for custom apps...

            Why would I need to implement the corba server within my own bean?

            Would it not be easier to just expose some "execute() method within my mbean and use Jboss's remoting?

            Or are you saying that there is no client libs for c/c++ application to access Jboss remoting?

            Thanks for the answers! ;)

            • 4. Re: Using Jboss MX Kernel for custom apps...
              Dimitris Andreadis Master

              JBoss remoting won't automatically give you a CORBA interface, and I think also corba support is not build in the new remoting layer, yet. How a remoting layer would know how to map your execute() method arguments/retrun values/exceptions to CORBA and vice versa?

              EJBs have an automatic java->idl mapping (rmi/iiop) but again this is very ugly when used from CORBA clients, so unless the EJB interface is extremely simple, this is of no use. In most cases the rmi/iiop interface is used for appserver-to-appserver interoperability.

              So if you want your server to expose a specific CORBA interface X, the best you can do is actually create a CORBA object implementation of the interface and have an MBean to control the lifecycle of such an object.

              Such an example in JBoss is the embedded CORBA Naming Service

              • 5. Re: Using Jboss MX Kernel for custom apps...

                Ah ok that cool. Actually the Corba interface for my service will be quite simple as all calls will originate from one "client", my database which will use and extended stored proc.

                So all my services will implement an execute() method with a parameter called message (maybe XML). Now either the message will be already preformated to the 3rd parties spec or I might implement a simple message protocol that the services will parse and format the message to a specifcation.

                For instance some of my services comunicate to 3rd parties using simply tcp/ip with some delimited message, some ask for XML, some http pair/value queries, some archaic binary protocol with 7bit even party :P etc...

                It's alot easier to format the required request in the db and send it to the service. Unless you thibnk there is a simple and elegant solution? :|

                Now you mentioned also the Corba Example... And I also see there is a threapool service. I think am getting ahaed of myself... I should start simple but so many ideas lol... I guess it would be nicer to keep my service simple and to hook into the corba service? Same goes if I want to use threading within my service I could hook inusing the thread pool service right? I have an old mentality where my apps for each client request spawns a thread. Simple blocking socket accept() with new thread for each connection, with a simple system to count threads so they dont get to high...