I am looking for good examples where the JBoss has been used with IS …
I would like to understand what it has been used for, and what are the benefits of this sort of architecture ?
Customers have used JBoss and the webMethods platform in a few instances - however I cannot disclose specific customer names. Mostly the usage has been to host integration/business logic in a J2EE layer. In addition a customer has hosted Mbeans in JBoss acting as light weight adapters talking to the webMethods platform.
You are probably aware of the upcoming release of the webMethods JBoss Package - with this product you will now have the JBoss Application server embedded within the Integration server. With this product customers can now easily expose their EJBs as IS services and similarly expose IS services as EJBs to the app server environment. This product is currently being previewed by a few customers. These preview customers are testing the software and doing pilot projects, some of which would eventually go into production. To give you some examples, one customer has lots of logic embedded in database stored procedures - they plan to migrate this logic into EJBs and deploy them in the webMethods JBoss package. This would allow them to easily access this logic from IS. Another customer plans to move their existing logic written in RPG programs and MS VB code to EJBs which will be deployed in wM JBoss Package.
The advantage of using IS and JBoss together (as in the webMethods JBoss Package) is that you can now write business and integration logic using EJBs or move existing EJB based business logic to the webMethods platform - in most instances this logic would be something that you require access to for integration purposes. So if you already have J2EE skill set in house, you can now leverage that skill set to write business logic and integrations using the J2EE paradigm, without forcing your developers to learn a new technology (IS). Once this logic is exposed as IS services automatically, they are then accessible to the Integration developer without having to learn anything about EJBs. Similarly your J2EE developers can now easily get access to legacy back end systems - since IS services can now be exposed as EJBs to the J2EE developer. In addition to these benefits, customers can also deploy their regular J2EE applications (non integration related) within this product.
Correct. The JBoss Package run JBoss inside the IS JVM.
Not sure what the question is, so I will ramble…
It is the case that an Integration Server and an Application Server sharing a JVM can run into memory constraints, just as either one individually can. It is possible to use the EJB Adapter to talk to JBoss in another JVM, so if memory or performance of a single box is the bottleneck, then use the EJB Adapter.
JBoss does not take a significant amount of RAM when at rest (for instance, on my machine the additional overhead of the JBoss Package and samples is less than an instance of WordPad.exe that I use to maintain a text TODO list while I work), so the CPU and RAM usage will be predominantly a factor of the apps that are run.
Thomas…sorry for the delay in looking at this thread - looks like Fred has answered your question. If you still have any further questions, please feel free to ask Fred or me.
I understand that you have to sort of configure your Jboss instance (ie pooling) so that the whole IS can run on one machine.
My question was if for instance I want to cluster 2 IS running EJB services.
Would this services be callable from outside the IS JVM using a JNDI lookup straight away ? And in this case how could I cluster these services ?
I am not sure if I completely understand the question, but I will try to answer it.
JBoss runs in the same JVM as IS (essentially embedded). The installer takes care of JBoss configuration and you need not do anything special to make it run in the same VM.
The JBoss clustering option (running multiple JBoss instances within a single IS) is currently disabled. You can however have multiple ISs running their own JBoss instance. Keep in mind however that the JBoss clustering mechanism and IS clustering mechanism are not currently integrated. This however does not mean you cannot load balance between the multiple ISs which are exposing these EJB services. The IS clusetering and JBoss clustering will be unified/integrated in a future release.
There are multiple ways to invoke the biz logic in these EJBs. They can be invoked as IS services in the usual fashion, or you can use a regular Java RMI client that invokes these EJBs by doing a JNDI lookup.
Hi,
It seems a little counterintuitive that IS is embedding a J2EE container instead of being the other way around. Existing commercial applications that have their business logic in EJB’s are typically tested on a certain stack that might include Weblogic, Websphere or even JBoss. Since IS currently embeds JBoss, the user has to change the deployment model completely (lifecycle now depends on IS) and is now tied into using JBoss. Additionally features such as clustering or any app server specific features are lost. It would have been nice if IS is deployable in a J2EE container instead.
I’d be interested to know why IS has decided to embed a J2EE container.
Perhaps you could give an example of a major J2EE-based commercial application and pose a question about how webMethods might best used in some type of integration scenario with that application.
The optional approach of embedding a J2EE app server like JBoss inside IS allows you to easily deploy EJB-business logic built for another part of the organization inside the “cradled” JBoss server so that any IS Flow or Java service can invoke its methods natively. I’m quite sure that no one envisioned redeploying an entire commercial application in the cradled server.
Organizations that already have EJB-savvy development teams can leverage them for integration development without retraining. Also, any IS Flow or Java service can be accessed natively by EJB’s by generating “iBeans” which get hot-deployed in the cradled JBoss server.
Note: I did not say that you need to be an EJB developer or even a java developer to create webMethods integrations, but if your organization has an existing EJB skill set, those folks can do integration development work without learning any new tools (except perhaps the minor differences between JBoss deployment descriptors and those of their existing app server vendor).
Of course, there are other ways to invoke EJB methods from within webMethods integration services including using the EJB adapter, writing RMI client code or invoking a web service wrapper of the desired method. As always, which method is best depends on the skill set of the organization and the specific requirements of the business.
Thanks for your reply. I got the wrong impressiong that the proposal was to deploy existing beans in the embedded JBoss container. You’ve clarified that new integration logic can be developed and deployed as EJB’s in the embedded JBoss container while a user has the option of invoking existing beans that deployed externally as well.
This may be a bit off-beat question, but could not resist asking you.
Well, now that JBoss (open source freeware) made it’s presence felt in a commercial software like webMethods, can we fore see a future where an open source freeware integration server modules are also developed for JBoss?