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.
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! ;)
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
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...