webMethods this week is releasing a major overhaul of its integration platform (webMethods 6) that deepens its Java support and bundles in the JBoss appserver on top of their platform. webMethods' bundling of JBoss reflects their philosophy that the integration platform should serve as the core element of the infrastructure, in contrast to the approach taken by J2EE server vendors.
Essentially, webMethods is building the appserver on top of the integration system, not the integration system on top of the appserver.
Read webMethods bundles JBoss app server
Read the webMethods 6.0 launch press release
It's great to see that a piece of corporate america is trusting wrt JBoss. You hear too much of: "JBoss runs perfectly, and is exactly what we need.... BUT ..."
Congrats to the JBoss team, and wM
They better bundle something with it. Their licensing is pretty ridiculous. My last company moved from Vitria to webMethods and each of them had licenses around $500K. They provide a lot of functionality but a lot of it can be duplicated at a much lower cost with J2EE, especially JMS. I'm guessing they chose JBoss because 1) it's free and 2) it's JMS implementation is pretty weak, so it won't have people asking why they need to use webMethods when setting up asynchronous communications.
it's JMS implementation is pretty weak
Care to elaborate why you think that Jboss's JMS implementation is weak ? Have you tried out any of the Jboss 3.x versions ? I have been been using it for a while and I think its performance is rock solid.
I have used JBOSS 3.0.2 Version. And I should say that I agree with Drew McAuliffe in saying JBOSS JMS is pretty weak.
JBOSS JMS was cool till we send and receive few messages.
But when I started doing a load testing, that includes sending 15000 messages of each 8KB size, I got the
-"OutOfMemory Error" and the whole system had gone for a toss. I browsed the JBOSS JMS forums and found that there are many to get the same error while doing loadtesting.
So, now I am in the process of migrating the whole JMS stuff using Fiarano.
Thats an interesting situation. To be fair I did get out-of-memory exceptions when I undeployed my MDBs and let the messages accumulated for over the weekend on a test system. The problem seemed to go away when we configured it to use the RDBMS.
Have you tried configuring the Jboss JMS with RDBMS as message store ?
Marc F spoke at the Java SIG in Palo Alto last night and made the comment that the JMS implementation in JBoss is admittedly weak, so there you have it, directly from, hmmm, the boss :) I recall Marc commenting that the JMS piece will get re-written.
As big and bloated WM is, this bundling announcement gives JBoss a significant credibility boost. Kudos!
Yes, I spoke with Marc about this very thing. I'm trying to see if I'm equipped to do a complete rewrite for JBoss 4. I've put together a team of folks to do some R&D, but we haven't yet committed to doing it.
I just hope the JBoss team is getting something out of this. I know I'd hate to be associated with a bloated piece of crap like WM
I know I'd hate to be associated with a bloated piece of
> crap like WM
Havent used WebMethods proper, only the so called WebMethods enterprise (formerly known as Active Integration Broker), and that was the most overpriced piece of crap I have ever seen.
Webmethods == Toast.
Is there any indication of just how JBOSS is integrated into webMethods? Does JBOSS run standalone - in a separate process with its own JVM - or is it truly embedded within webMethods? Either way, do J2EE applications running within the JBOSS containers "see" webMethods through an interceptor, through JMS, or through something else? Finally, do we know how tightly coupled the specific JBOSS version is (as shipped with webMethods) with the product and can it easily be replaced/upgraded as new JBOSS versions become available?
It is somewhat ironic that Webmethods bundles open source app server like JBoss and at the same time it is the only company which is holding up the release of SOAP 1.2 spec due to patents issues.