Anybody knows about a performance comparison for Tomcat vs Websphere app server's web container?
www.webperformanceinc.com provides such a comparison but it's very outdated, somebody knows if there is a newer one, say with Websphere v6.1 or v7?
Websphere uses Tomcat under the hood. It only adds some more Java EE capabilities (EJB and so on) and of course the IBM sausage over it, so I wouldn't expect Websphere to be much faster than Tomcat.
Related
I'm evaluating options for my team's middleware. We really have a frankenstein'd setup. We're using Apache ServiceMix(Karaf/ActiveMQ/CXF), Websphere 8.5, ActiveMQ where we don't really need it, and all of our applications are not really coded to failover to another node if the primary goes down. We realized the issues of our setup and now want to improve.
We currently host bundles (not sure if they're all OSGI compliant) in a Karaf Container, which are used via ActiveMQ after being sent JMS messages via Apache Camel from Websphere.
My current idea is to kill off ActiveMQ, make all the camel routes towards HTTP (instead of JMS queues), and convert our data bundles/services to serve via HTTP through Apache CXF (replacing websphere for some things) and not ActiveMQ Queues/JMS. However, we have Websphere licenses, and I do know that it supports bundles in some way, I'm just not as familiar as to how it does (same nature as karaf)?
The main question is in the title, and I hope it's not too generic.
WebSphere 8.5 is a full OSGi container supporting Blueprint just as Karaf does.
You can, in theory, run your camel bundles or whatnot just as fine in WAS8.5. However, Apache Karaf is a lot more aligned towards running ActiveMQ/CXF/Camel stuff than WebSphere will ever be. Installation in Karaf is a few commands, where installation and configuration struggle in WAS85 for the Camel feauters and basic camel routes is .. well, a headace when I tried it last time. Others seems to have the same struggle.
I have rather good experience of running Camel apps inside WebSphere Application Server, but that was by embedding Camel in a standard WebApp, not using the OSGi stuff. So, embedded web apps is my recommendation for running Camel inside WebSphere.
For the "replace AMQ/JMS with HTTP" part. You are aware of that you are replacing pears with apples, right? JMS has a lot of features HTTP does not have (and some overhead compared to HTTP). For the sake of completeness, WebSphere also has a JMS provider built in. So if you have a large HA secured WebSphere infrastructure, the WebSphere (SIBus) provider might be a good choice. Otherwise, ActiveMQ rocks :-)
Does anyone know if its possible to re-configure CometD to use the WebSphere Application Server instead of using Jetty? If so, is there much effort involved in porting it over if I've already got CometD running with Jetty?
CometD runs in any Servlet 2.5 or later Servlet Container, see here.
You did not specify the WebSphere version, but I assume it's a recent enough one.
The only CometD feature that will not work in WebSphere is the WebSocket transport, which is Jetty specific due to lack of standard WebSocket API (now filled by JSR 356 and supported soon in CometD 3).
Your CometD application should deploy and run with no changes in WebSphere, unless you tied yourself explicitly to Jetty APIs.
I understand JMS spec allows me to write MDBs. Then I can deploy them on an appserver like websphere or jboss (and they have inbuilt implementation of JMS provider which is Java EE compliant). The question is when to use a full fledged product like IBM WebSphere MQ or ACtiveMQ instead of using App server's inbuilt JMS provider.
This appears to be a good reference to what you are asking, specific to IBM products but can be generalized to using an application server integrated messaging system vs a standalone messaging system - http://www.ibm.com/developerworks/websphere/library/techarticles/1109_wallis/1109_wallis.html
A built in JMS provider, such as WebSphere SI Bus, possibly others, are built for JMS messaging.
WebSphere MQ (MQSeries), ActiveMQ etc. have clients for multiple languages and are built for applications other than Application Server hosted applications to connect to it (C++, Java SE, Python, etc).
Say you want a local messaging server on the same physical server (or network?) as a non JavaEE application, you don't want to install a Java EE App Server, but want a stand alone messaging server instead (WebSphere MQ, Active MQ).
That said, ActiveMQ, for instance, is the messaging system inside Apache Geronimo. So there is overlapping here.
Then there is a whole discussion about management, clustering and security. Java EE messaging systems are pretty much optimized to follow the cluster layout of Java EE. In other deployment scenarios, the clustering might be optimal in other ways, such as cluster for different security zones. Also security models and management tools might be different in stand alone messagaing servers.
We're looking at the choice between implementing an enterprise integration solution in either:
Spring/Spring Integration/JMS/Spring Web MVC
Websphere Application Server/MDB/Spring
What are the pros/cons?
Especially interested in what WAS/MDB solution is functionally better at.
Cheers
Paul
If the only thing you need in your entire project from the Java EE Specification is to get messages from a JMS provider, I suggest you to not use WebSphere App Server. Go with Tomcat+Basic Spring JMS Template. Simple, free, lightweight.
Websphere will bring a level of complexity you don't need. Stay away from heavy weight app server. But if you need more fancy Transaction management ( XA between JMS and a DB) then get a real Java EE App Server.
My task to monitor the IBM Websphere through pmi client.Pmi client is an agent provided by the IBM to get MBeans and is running under IBM Java. I tried it to run under Sun java. But, it fails to create the Pmiclient. Did Anyone come across this issue?
The IBM JRE has slightly customized classes. This is unfortunately not uncommon with PMI (and also JMX by the way) when working with different WebSphere Application Server versions.
There are hacks around involving copying the relevant IBM implementations and running them with the Sun/Oracle JRE but I don't think that is valid according to the licensing terms. What you really should do is to use the IBM provided JRE.
If you want a riskless shortcut you will build an applicaton (perhaps EJB or servlets) that runs on the WebSphere Application Server and exposes the results from PMI via custom interface. For instance web service.