Collection of ideas and resources on WebSphere and IBM competitive position in the marketplace
IBM WebSphere Application Migration Toolkit has a new feature – it can migrate Tomcat applications and Tomcat configuration to the WebSphere Application Server Liberty profile. The tool is free to download and use for all.
In addition to Tomcat, the tool supports migration of applications from JBoss, WebLogic, OAS, and older versions of WAS into WAS v7 and v8.x.
Last few weeks brought us two new SPECjEnterprise2010 results – one from Oracle and one from IBM. Both were done using very latest software and hardware. Oracle announced their new SPARC T5 processor with much fanfare and claiming it to be the “fastest processor in the world”. Well, perhaps it is the fastest processor that Oracle has produced, but certainly not the fastest in the world. You see, when you publish industry benchmarks, people may actually compare your results to other vendor’s results. This is exactly what I would like to do in this article.
Full results can be found here:
Oracle total EjOPS: 57,422.17 http://www.spec.org/jEnterprise2010/results/res2013q1/jEnterprise2010-20130305-00041.html
IBM total EjOPS: 13,161.07 http://www.spec.org/jEnterprise2010/results/res2013q2/jEnterprise2010-20130402-00042.html
Being “fastest processor in the world” means that such processor must be able to handle the most transactions per second per processor core, which is how software pricing works and how people size their workloads and control their costs. This is not the proof Oracle delivered with their latest result (see full details on Spec website). To give Oracle credit, their result is the biggest overall 57,422.17 EjOPS (transactions per second). But that is a Total number of transactions, not a measure of the processor speed. To achieve that result, Oracle had to use 128 SPARC T5 cores for the WebLogic 12c and additional 128 cores for the Oracle database! The total cost of the hardware to achieve such high number of Total EjOPS is $1.1 Million. Even more sobering is the list price for the software, which is $5.2 Million (including 3 years of support and using lower priced WebLogic Standard – not even clustered!). If you price Oracle configuration with the WebLogic Enterprise (which does support clustering), your software cost will be $7.7 Million. Overall this latest Oracle result produced 449 EjOPS/core at the cost of $109.45 per EjOPS.
Now look at the IBM result published recently using WebSphere 8.5.5 on Power7+ hardware with DB2 database. IBM did not go after the biggest number of EjOPS (which is just the matter of throwing bunch of hardware together). However IBM produced the world record result in terms of EjOPS per processor core – truly a measure of the fastest processor known to men (for Java EE workloads that is). The total hardware cost of IBM result is $74,000 and the software cost is $766,000 (of which WebSphere is only $72,000 and the rest is DB2). This IBM result delivered world record 823 EjOPS per core with the cost of $63.79 per EjOPS. Now this is almost twice as many transactions per second at almost half of the Oracle cost. Truly remarkable.
Since Oracle knew they can not produce the most efficient result in terms of cost or transactions per second, the only way for them to claim world record was to throw large hardware at it and produce the biggest total number of EjOPS. Not a very useful metric I must admit. Much more interesting is the efficiency – measured in EjOPS per core and most importantly cost of EjOPS.
The story does not end here. Why not take a look at the history of performance results on similar and dissimilar hardware? Why not compare these platforms:
Here is a summary of these results listed above:
Here is a brief summary of the IBM WebSphere performance track record since year 2000:
For additional information, please refer to these performance related articles: http://whywebsphere.com/?s=specj
******************* Notes:
(1) SPEC and SPECjEnterprise2010 are registered trademarks of the Standard Performance Evaluation Corporation. Results from http://www.spec.org as of 04/04/2013 Oracle SUN SPARC T5-8 449 EjOPS/core SPECjEnterprise2010 (Oracle’s WLS best SPECjEnterprise2010 EjOPS/core result on SPARC). IBM Power730 823 EjOPS/core (World Record SPECjEnterprise2010 EJOPS/core result), (2) Results from http://www.spec.org as of 04/29/2012 Oracle SUN SPARC T4-4 313 EjOPS/core SPECjEnterprise2010 (Oracle’s WLS best SPECjEnterprise2010 EjOPS/core result on SPARC). IBM Power780 681 EjOPS/core (World Record SPECjEnterprise2010 EJOPS/core result), (3) Results from http://www.spec.org as of 11/14/2012 Oracle SUN Fire X4170M3 519.39 EjOPS/core SPECjEnterprise2010 (Oracle’s WLS best SPECjEnterprise2010 EjOPS/core result on Sandy Bridge). IBM WAS 8.5 System x3650 M4 Intel Sandy Bridge EjOPS/core (World Record SPECjEnterprise2010 EJOPS/core result) (4) Results from http://www.spec.org as of 04/29/2012 Oracle SUN Blade Server X6270 M2 452.285 EjOPS/core SPECjEnterprise2010). IBM Websphere HS 22 Blade 524.621 EjOPS/core.
This article was written by Hariharan Venkitachalam (IBM).
In this article we want to illustrate the options and the benefits of moving off from the Oracle Tuxedo platform on to a IBM solution. Having talked to several customers we want to highlight and provide insights on the migration process. IBM provides different solutions catering to needs of the clients migrating from Oracle Tuxedo. In brief below are the available solutions:
What values does the IBM solution bring to me? As said there are different solutions from IBM and so it would be best to talk the value add on the context of each solution:
IBM TXSeries has been in the market for well over decade and is a mature product; having a wide spread deployment world-wide running across various industries like Banking, Healthcare, Insurance, Retail, Manufacturing, Transportation, and so on.
TXSeries adopts a robust framework of CICS – a famous OLTP platform in the industry. The simplicity of the CICS architecture provides various benefits to that of a Oracle Tuxedo. Firstly, it is proven that TXSeries consumes less CPU power and memory usage to that of Oracle Tuxedo for the same throughput (or a TPS factor). This means you can do more with less. In terms of large deployments, TXSeries scales across different hardware platforms, provides an intuitive work load management, flexibility in deploying applications and refreshing them later with an updated version without requiring to stop your business. Multiple instances of TXSeries systems running on different hardware can talk 2PC (global transaction), provides monitoring through Web based administration tool, Tivoli agents, Web Services SupportPac, WebSphere Business Events SupportPac, IMAT SupportPac…. and all this at no additional cost!
IBM WebSphere eXtended Transaction Runtime offers a first class integration between traditional applications written in C, C++, or COBOL and Java EE applications running on WebSphere environment. This is the best available solution in the market place today to modernize your existing Oracle Tuxedo applications and manage them on the WebSphere environment. The management, deployment and development processes for applications are all integrated with the features provided by IBM WebSphere eXtended Transaction Runtime technology, and couple this with the feature pack that provides the IBM Migration Assistant Tooling for Oracle Tuxedo that helps you to migrate off your existing Oracle Tuxedo applications.
This solution helps in standardizing your entire application environment including Oracle Tuxedo applications based on the WebSphere infrastructure with proven high availability, scalability, work load balancing, security contexts, etc. With this you do not have to maintain or buy additional components for managing Oracle Tuxedo applications compared to your Java EE applications.
IBM Mixed Language Application Modernization Pattern helps clients to deploy in a cloud ready environment such as IBM PureApplication System or through IBM Workload Deployer. This solution leverages the capability of the IBM WebSphere eXtended Transaction Runtime technology as described above. In addition this solution provides a cloud-ready solution to run your existing Oracle Tuxedo application on to a IBM Cloud platform. IBM Mixed Language Application Modernization Pattern is a virtual application pattern that allows you to run COBOL, C and C++ applications on a modern cloud ready environment.
The migration assessment starts with a discovery process. IBM has developed a migration questionnaire that we send to our clients in advance of a discovery call. The questionnaire enables us to get a basic understanding of the existing application environment so that we can ask more appropriate questions, dig deeper in to their application environment and estimate more accurately the potential problems and issues facing the migration on to a IBM technology.
One of the must to understand in terms of Oracle Tuxedo migration is the services used within their existing Oracle Tuxedo applications such as the ATMI API. This can be done either by scanning the source of the application code and looking for ATMI API or to make it even easier we provide a analyzer tool that generates a summary report on the usage of Tuxedo services within the application and if they would be supported with IBM solutions.
We then usually proceed for a proof of concept to migrate a subset of TUXEDO application to the target IBM solution. It helps to validate the target solution that is being offered and can offer further guidance on how the rest of the application migrations could be migrated.
Our initial focus is to retain the existing application in an as-is form as much as possible. However as we work through the migrations we further add value and benefits in terms of providing a better unified management environment for the applications, better tools, other non functional aspects such as scalability, high availability and a future-proof compatible applications that can be run on CICS Transaction Server for z/OS.
IMAT tool provides you the necessary tools that lets you to migrate your existing Oracle Tuxedo based application on a IBM Solution seamlessly, without requiring considerable effort…During the migration process, your application remains as-is – this is a key benefit in the migration projects which are quite sensitive to any changes done in the application business logic. Also you might think that being new to a IBM environment, it would require a larger learning curve – but this is not the case with IMAT… it is equipped will all the tools required with which you continue to develop and deploy your application as you were doing in the Oracle Tuxedo environment! Isn’t this a great boon for such migration? Less learning and quick deployments of your existing applications! This is why we call IMAT an S.M.A.R.T migration offering. You can continue to maintain your existing applications and new application can be written to take advantage of the CICS Application Programming sets.
Not really. We have had proof of concepts where we have done the migration of applications without modifying a single line of code in the existing applications… Even the Makefile or the build scripts used to build the application remain unchanged except for the libraries that needs to be link-edited to the one provided by IMAT tool.
One unique advantage moving to an IBM solution is that your applications become compatible with the best quality of service platforms such as CICS Transaction Server for z/OS if you wish to scale over the roof… With the z Enterprise one can consolidate all the heterogeneous hardware in to one single box with the reliability that you can only get from IBM mainframe.
Enterprise Service Bus (ESB) is by definition required to provide universal connectivity to many different systems that the enterprise needs to connect together. Therefore many ESB vendors provide extensive library of connectors for their products. In this article I will compare adapters and protocols supported by latest versions (as of this writing) of ESB products sold by IBM and Oracle:
Such comparison needs to be done at the technical level (i.e. what? and how?) and also at the financial level (how much?). I researched public information for both vendors using their websites, documentation and google (duh) and came up with a list of adapters and protocols as well as the cost of those connectors. Before I show you the actual comparison, let me make general observations and conclusions from my comparison:
Once again, I think quality is a major consideration and I can’t say that enough. Before you make a decision one way or the other, I highly recommend that you actually test the product in the lab environment and validate ease of use, security, performance and other characteristics. For example, I have seen dramatic performance differences between WMB and OSB in the order of magnitude with file and database adapters (WMB being faster, of course). I believe part of the WMB performance advantage comes from the fact that unlike OSB, it does not force payloads to be converted into XML on the input and then back from XML to whatever format on the output from the message flow (proxy in OSB terms). Buyer beware!
Notes:
* – included free of charge with WMB Advanced v8
** – these are JCA adapters and can be used in WAS
In addition to the adapters and protocols mentioned above, there are additional industry specific pre-built flows, message formats and specialized adapters that are provided with WMB and OSB (not all of them are included above). These pre-built components are designed to simplify development and thus shorten implementation time:
Ease of use and small footprint are important considerations. Especially if you are building integration layer as part of your private or public cloud environment or doing multi tenancy and need to be able to add and remove instances of ESB quickly. I have measured the speed of installation for WMQ and WMB and as you can see from this video even using interactive method on my laptop I was able to fully install WMQ in 43 seconds and WMB in 1min 44 seconds. Using silent script to install these products and removing local install of MQ Explorer will reduce this time down to under 2 minutes total. Startup times for WMQ and WMB on my laptop are under 10 seconds. How long do you think it takes to install Oracle Service Bus and all of its prerequisites? (hint – hours). How long does it take to start and stop? (hint – minutes). Oracle license agreement does not allow me to publish these numbers in the public domain without Oracle’s written permission, but you can try installing OSB yourself and will probably see orders of magnitude difference:
I mentioned above that the quality of adapters and provided features provided by IBM and Oracle is not the same. Lets consider WebSphere MQ adapter as an example. As you can see from the table below IBM WMB provides much stronger integration with WMQ (as expected) by providing support for latest versions of WMQ, better performance, management and lower cost as WMQ is included with WMB at no extra charge (so long as messages are consumed or produced via Broker):
Lets take a look at other adapters and consider transaction control capabilities of those adapters. While both WMB and OSB allow one to connect to remote systems, there is a difference between the two products in their ability to coordinate distributed transactions. This is a very common pattern for ESB – get message from the queue, update certain database, perhaps update another database and send message via another queue, perhaps even update CICS or IMS too. Ability to coordinate distributed 2 phase commit (2PC or XA) transactions is key for ESB product. WebSphere Message Broker shines in this area as you can see from the table below:
Performance is another critical consideration for an ESB. IBM performance team publishes detailed performance reports for WebSphere MQ and WebSphere Message Broker (all found on Support Packs page).
Here is an example of such report for WMB v8 on Linux x86. I have not seen any public performance data for Oracle Service Bus, nor tuning recommendations for specific platforms and protocols. The following table shows the message rates that were obtained for the different use cases when running on a IBM xSeries x3690 X5 with 2 x Deca-Core Intel Xeon E7-2860 2.27GHz processors:
I would love to share with you performance of Oracle Service Bus for the above workloads, but Oracle license agreement requires me to get their written permission to publish OSB results and given the performance difference between WMB and OSB, I do not think I will get such permission any time soon 
.
See related articles:
I’ve spoken to many companies about moving from Java CAPS (or the predecessor SeeBeyond platform) to WebSphere. I thought I would share with you a little insight into how we approach these migrations in order to help organizations reduce the costs and risks associated with the replacement.
Why choose IBM connectivity solutions over Oracle? Go here to learn why WebSphere is the smarter choice.
I won’t spend time discussing why there is a need to replace Java CAPS infrastructure (you can find a quick summary here). Safe to say that anyone running this platform is likely to understand that it is imperative they develop and execute a roadmap to a new integration platform. The problem most organizations face is that they have a significant investment in the existing platform in the form of code artifacts, the details of which are not necessarily well documented, that they are reluctant to lose. Additionally, there is a concern with both costs and risks in order to replace the “plumbing” between applications, a project that might at first glance be perceived as not delivering an immediate business benefit. Our focus is primarily placed on helping customers make the move to WebSphere Message Broker, though there have been some cases where other WebSphere target platforms may make more sense depending on what version and parts of the Java CAPS software stack were in use (e.g., BPEL processes). Here’s a video that outlines some of the key capabilities of WebSphere Message Broker:
We’ve understood these concerns and have developed both an approach to the migration as well as a set of tools that helps to preserve current investments. The approach we take to migrating off Java CAPS (a no charge service offering – based on the WebLogic to WebSphere migration discussed here) consists of three basic steps – a Discovery, followed by a Migration Assessment, and then finally providing guidance, best practices, and support around the Full Migration.
Discovery
Our team has developed a migration questionnaire we send to our client in advance of a scheduled Discovery call. The questionnaire helps us gain a basic understanding of the existing environment, the scope of the integration applications that need to be migrated, a review of testing practices, as well as giving us a chance to review any documentation that exists for the implementation. Next we meet with the client, typically via conference call, to review the responses and dig deeper into any areas where we need more information. Use of the questionnaire helps make the Discovery call an efficient use of everyone’s time, and allows us to be very focused when the team arrives for the onsite Migration Assessment. The output of this step is a basic understanding of the current infrastructure, an understanding of what a future state infrastructure needs to deliver, as well as identifying candidate areas for detailed investigation.
Migration Assessment
This step is where we dig into the details of the Java CAPS implementation. Through the Discovery step we’ve typically identified some example code artifacts, such as OTD’s / ETD’s and Java Collaborations, that we can examine in detail. This step allows us to assess the applicability of our migration tools as well as identify any areas where manual effort needs to augment or replace what we can deliver through automated conversion. The team will also conduct architectural and functional reviews of the system. The output for this step is a full migration plan that includes a timeline with migration steps, level of effort, and a risk mitigation plan. The team follows up the onsite portion of this work with a presentation of the findings and recommendations that include the migration plan deliverables outlined.
This step may be augmented with a proof of concept to migrate an example integration program to the target WebSphere environment. This work helps to build confidence in your team around how the migration can take place, serving as an example for which to build your “migration factory”. It also helps us to identify any specific issues with your artifacts, allowing us to further refine your migration plan.
Full Migration
Once the migration plan has been delivered, you are free to engage whatever resources you would like to use to conduct the full migration. Some of our clients have chosen to use their own IT staff for the migration, others have engaged service delivery partners, and IBM has consulting services (IBM GBS or IBM Software Services for WebSphere) that can be used as needed. In many cases our clients choose to use a blended approach in order to ensure they have the most efficient use of resources while also having the right expertise at the right time.
In any case, our Migration Team will stay engaged to relay their experience and answer questions as they arise.
In a future post I’ll provide some more information on the investment IBM has made developing tools to help automate the conversion of Java CAPS / SeeBeyond environments to WebSphere. One of the recent developments we’ve had in this area is to add support for the conversion of Monk code, so anyone with an older e*Gate implementation can benefit from our tools investment as well.
Interested in learning more about how to migrate your Java CAPS environment to WebSphere? Contact us at whywebsphere@gmail.com.
Back in 2007 Kevin Kelly in his TED talk has made predictions about the future of the Internet. It turns out he was right. Applications talking directly to each other are a norm today. Of course, those of us who were in what was called at the time EAI (Enterprise Application Integration) knew that already, but the general public did not appreciate the value of universal connectivity. Until now. These days everyone talks about APIs, standard formats for data, etc. However the truth is, while social networks and public web is built on standards, the vast majority of enterprise data is still locked in proprietary systems, accessed by proprietary APIs, or worse, via file exchanges or direct access to the database (yeah, its you, pre-internet Oracle eBusiness Suite).
The ability of enterprises to create new applications is limited by the ways those applications can reuse existing business logic and data. This explains huge interest in messaging and connectivity products. Some call them ESBs, others call them SOA products, but no matter what you call it, this kind of specialized middleware must provide a set of capabilities that make it easier to connect to many different types of old and new applications, data formats, protocols and be able to perform transformation of the above mentioned things. Synchronous, asynchronous, transactional, reliable and high performance capabilities are a big plus (as they say in job postings).
Where there is demand, there is usually supply. In case of IBM and Oracle, both vendors provide a set of offerings that claim to solve the problem of connectivity. Both vendors claim that they have the “most complete integration solution on the planet”. I decided to take a look and compare. In this first article of the series I will simply look at the products at a high level and in subsequent articles will look into specifics and more in-depth technical and financial TCO comparisons between products. Here is how offerings from these two vendors stack up to each other. Please note that color coding on this comparison is meant to reflect the strength of the product based on (a) Technical capabilities (performance, feature richness, security, scalability, etc.) and (b) Market position (number of users, market share, history, release schedules, analysts’ feedback, etc.)
* – IBM MobileFirst MessageSight messaging appliance is scheduled for general availability in second quarter of this year.
From the table above you can see that Oracle does provide several important connectivity products, but is missing a number of important components from the platform and is far from being “complete”. In future posts I will compare individual products at a much deeper level, but in the meantime, you can learn more about IBM and Oracle offerings here:
I got asked the other day a question about how well WebSphere Application Server works with the Oracle database. Specifically, i got asked if WebSphere Application Server works with things like Oracle Real Application Cluster (RAC), Fast Connection Failover (FCF), Oracle Notification Service (ONS), Single Client Access Name (SCAN). The short answer is “yes” to all of them. The long answer is:
Oracle Real Application Cluster (RAC):
RAC is the Oracle database cluster solution as the name states. RAC is supported by WebSphere Application Server and has been for a long time. RAC is supported both in a failover mode (active passive) and in a loadbalancing mode (i.e. active active). There were some limitations that existed in Oracle 10g and earlier that would have prevented a seamless failover in some two-phase commit scenarios, but as far as i know, Oracle 11g resolved them. For more details on that limitation and how to workaround them in WebSphere Application Server, take a look at this article: http://www.ibm.com/developerworks/websphere/techjournal/0710_barghouthi/0710_barghouthi.html
FCF and ONS:
I am going to assume the reader is aware of what those features do and I am not going to explain them. What I am going to explain, however, is that WebSphere Application Sever does offer “Fast Connection Failover” equivalent capability and has been for a very very long time. There are two main cases that Fast Connection Failover and ONS are great for:
1) Down scenario. Meaning one of the Oracle cluster members (i.e. nodes) go down.
2) Up scenario: meaning the down Oracle cluster member comes back up.
In the down case and the connection is detected to be stale (say an exception is received on a query execution which Websphere determine its a bad connection error), the application server will purge its connection pool (assuming default connection pool pure policy of entire pool) and will get fresh new connections on the next connection request. That will result in connections getting directed to the working Oracle node and none going to the down Oracle node. Please note that in WebSphere Application Server V6.1 and above, if the connection pool purge policy is set to “failing connections only”, the WebSphere Application Sever will automatically pretest the existing connections in the pool to see if they are stale in the event that a stale connection is detected. This is a one time test and thus, will not be done on newly created connections.
In the up event case, connections in the connection pools need to be re-balanced to point to the other Oracle nodes. In WebSphere Application Server, there are two ways of doing that. I talked about this in the following technote: http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg21229847
That said, there are situations where the above solutions may not be good enough. For example, the application can’t wait for a connection to be used and receive an exception that the database is down before WAS is notified. Or, the database node goes down in a way that for the connection to receive an exception on its usage, the TCP/IP timeout has to occur which might be set to a long time. In those cases, and assuming the Oracle LoginTimeout is not desirable, one can enable Oracle Notification Service feature (ONS). You can configure WebSphere Application Server (WAS) to use ONS by configuring enabling WAS to use Oracle connection pooling instead of WAS’s own connection pooling. To do that, follow the instructions in the following technotes:
1) Enabling the old Oracle connection pool (implicit pool): http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg21282204 (applies to all releases of WebSphere)
2) Enabling the new Oracle Universal Connection Pool (UCP): http://www-01.ibm.com/support/docview.wss?uid=swg21498877 (need WebSphere V8.0 or above)
ONS can then be configured using the Oracle documentation by simply setting the ONS properties on datasource and the UCP or Oracle connection pool.
Single Client Access Name (SCAN)
This feature is independent of the application server and doesn’t need any changes in the WebSphere Application Server for it to work. You can read more about it here: http://www.oracle.com/technetwork/products/clustering/overview/scan-129069.pdf
For the past 14 years I live in Pittsburgh, Pennsylvania and love my city. I can go on for hours describing beautiful landscape, the outdoor fun, great and educated people, rivers, parks, architecture, very low crime rate, museums and last, not least, the relatively low cost of living (yes, I like weather too ). Before I moved from Russia to US back in 1999 during the dot com bubble, I had plenty of job offers from all over US. I did my home work, researched future places to live and compared them based on multiple criteria, including things listed above. Out of several different job offers I took one in Pittsburgh because (1) the city came out on the top of my list and because (2) the best job and (3) best offer came from (4) the best company that happen to be in Pittsburgh (Transarc at the time, later acquired by IBM). Those four things were pure luck and I still feel lucky until this day. It was the right choice.
Having said all this, Pittsburgh does have its fare share of problems, one of them being traffic (and who does not have this problem, hah?).
IBM to the rescue (read announcement).
Pittsburgh was one of only 100 cities chosen from a pool of more than 400 applicants over the past three years to receive an IBM Smarter Cities Challenge grant, which funded the work last year of top IBM experts who studied local transportation opportunities. The full IBM report was released yesterday and can be viewed here.
What does this all have to do with this blog, which name is “Why WebSphere”?
Nobody needs software for the sake of software (well, most people don’t). Having bits is one thing, but having the expertise to apply those bits to solve practical problems is a completely different skill set and a unique differentiation for IBM. Not to mention the goodwill of the IBM company to do the kind of consulting work for free via the grant system. This is one of those things that make me proud to be an IBMer.
If I had to compile a list of most frequently asked questions that I get, one of the top 10 is a question on the differences between WebSphere Application Server (WAS) and Apache Tomcat and their relative values as a function of cost. I assume that most of you are aware of the fact that WAS is a commercial product sold and supported by IBM and Tomcat is free Open Source product from Apache. At some point in the past Tomcat was the reference implementation for JSP and Servlet APIs and developed by a community of vendors and independent committers, including IBM, Oracle, Sun, BEA, Red Hat, JBoss, VMware, SpringSource (now part of VMware) and many others. It was (and still is) a great community effort. Most of the vendors listed above still contribute code and bug fixes to Apache Tomcat.
However software companies listed on public stock exchanges do not exist to contribute code to Apache and not expect anything out of that effort. Quite the contrary, the “big” Open Source of our day is very much commercially driven process (with few exceptions). Today several commercial software companies package Tomcat as part of their offerings, in some cases enhancing the product (as is the case with VMware tc Server), or simply selling Tomcat support directly to users (such as the case with OpenLogic and many others). As you might expect the cost of support for the free Apache product is not very expensive.
Apache Tomcat (and one of its commercial versions being tc Server) provide JSP and Servlet support and none other parts of the Java EE 6. How can you compare Tomcat to WebSphere, which is a full Java EE 6 implementation and some? The answer found by Prolifics is that you look at the Total Cost of Ownership for a certain configuration. There is no one answer fits all as Tomcat might be appropriate for some projects, but not others. One really needs to consider the project scope and requirements to compare the fitness of Tomcat or WebSphere for what one is trying to achieve.
Having done hands-on research in their lab, Prolifics published their findings in their new white paper “IBM WebSphere Application Server v8.5 vs. VMware vFabric tc Server v2.8 Technical and TCO Analysis”. Prolifics priced several different configurations and included two of them in the paper. Here is the five year TCO for WAS vs. tc Server for medium size configuration, NOT including the cost of JDK support (the one with JDK support adds another 30% to tc Server cost):
Click on the image above to download the full report.
To quote the paper: “After testing out tc Server, we observed that for the most part it performs as advertised – as a lightweight environment for simple applications that can be easily managed and monitored with the included tools. It is not suitable for large or Enterprise applications that require High Availability or robust failover. The comparable product in the WebSphere family is WebSphere Liberty Profile 8.5, the lightweight offering that is fully compatible with the rest of the WebSphere family, and thus provides a growth path that does not require any recoding. Our performance tests indicate that IBM WebSphere Application Server outperforms tc Server on common benchmarks, has better documentation, and is fully supported by a single vendor: IBM.”
A couple of weeks ago IBM released a beta of IBM WebSphere Application Server Liberty profile. This is exciting news and brings a robust set of new features. Highlights of this beta update include:
A full list of changes can be found on the New and Noteworthy page of the wasdev.net site.
What I like about Liberty is that the server is so dynamic and lightweight, yet it has significant additional features that you wont find in other lightweight servers (Tomcat or VMware tc Server). Things like JMS, EJB Lite, MDB, JPA, web services, etc. And not only that, but also the ability to do profiling of the server, etc. See examples of such advanced tooling at the link above.
The other nice thing is that Liberty now has clustering and ability to manage multiple servers. All of this without the heavy add-ons, such as full RDBMS and Hyperic required by JBoss JON or tc Server. It is interesting that tc Server download size is 19 MB, yet the admin “console”, which is vFabric Hyperic is 418 MB download and is such a drag to install. Ever worse, in full production you would need to buy licenses of Oracle DB or Postgres to keep all of your admin data. None of those extra megabytes nor costs with Liberty!
I will post detailed comparison of capabilities of Liberty and JBoss and tc Server in near future.
Soloman Barghouthi
Eric Berg
Roman Kharkovski