I have been looking at JBoss as an application server in our manufacturing area. We communicate with our manufacturing tools using an industry standard language and have java libraries to handle the low level communication. Our host applications consist of single client applications that talk to the manufacturing tools and receive information from the manufacturing tools. This information is then processed and may be sent to other systems.
We would like to use JBoss to bring these client applications together, have MBeans for administration, and use some of the services built into JBoss such as MQ to facilitate communications with other systems and to allow administration through the web. We don't need EJB's. Mostly interested in Web administration through MBeans and being able to utilize the Message Queue for sending messages to other systems.
In reading through the message forums, there are two potential issues that I would like to get comment and more information about from anyone in these forums that can help.
1. We will be running several applications, each will be communicating with a dedicated manufacturing tool. Different tool vendors are at different levels with respect to the communication software they provide with their tool. We can have situations where a particular application may get hung because of a problem with the tool. This may in turn hang the port that the tool is communicating on. If this occurs running multiple individual applications, it is not a problem. Just kill the process and restart. In the JBoss environment is seems this may be a problem since it is all running under one JVM.
Q1a. What is the general feeling on this, how isolated are the applications?
Q1b. Is it conceivable to have an MBean service for each application and have that MBean kick off it's own JVM and use the MBean as a proxy for communication between the isolated JVM and the JBoss Server?
2. It seems that the jar files in the individual applications can be seen by other applications in different directory structures (containers). This will be a problem for us. We have a base library and each tool that is controlled uses extended classes of the base library. If there are changes to the base library then this would have to be tested with every deployed application before it could be deployed to one application if the base library class files are seen by all applications. Currently the base library has revisions and the particular manufacturing tool application is approved for certain revisions of the base library.
Q2a. Is there a way to be able to keep multiple versions of the same jar on the server and have different applications reference the different versions?
I appreciate any help or comments from the JBoss team or users. Thanks, Lou Parisi.
I found some information that seems to answer the question on the class loading from a link in another post:
Seems the default unified class loading architecture can be overriden by scoping the classes within an ear file. This is done by adding a descriptor to the jboss-app.xml file:
where the loader-repository element is the JMX Object name for the ear.
Still hoping to get some input from users or the JBoss team on isolating applications. Thanks.
How about multiple instance of JBoss on one server?
You can use Service Binding Manager.
>How about multiple instance of JBoss on one server?
>You can use Service Binding Manager.
Having an instance of JBoss running for each tool/service just does not seem right to me. Maybe I just have to change my traditional thinking. Is this the better way to do it?
I still like the idea of each MBean service kicking off a JVM and then communicating between the MBean and the application in the isolated JVM with RMI. I am going to try to develop a proof of concept application doing this today.
I was successful in creating the client to read the MBean and invoke methods on the MBean but I am having some trouble creating a listener to the MBean. I have posted a question in the JMX forum to try to get some help if anyone is good with the RMIConnectorImpl. Thanks.