Ok - finally I've had enough of people saying that J2EE applications are portable.
Let's talk about it
If you're using vanilla session beans with no user authentication or authorisation, no CMP entity beans and a basic web application - yes, it's maybe going to be portable. This is before you run into non-specification compliant J2EE servers.
In reality, this just doesn't cut the mustard. EARs are not portable without a lot of work.
(More discussion at JavaLobby
I am not sure if it is 'fair' to talk about J2EE portability woes between the products you have mentioned. Of Orion, JBoss, and Weblogic, only Weblogic has a J2EE certified server.
Although we would all love to have open source CTS tests available, currently only only J2EE compatible (passed the CTS tests, etc, etc) servers can claim to run portable J2EE applications. Are the CTS tests even available for non-licencees to download and run?
Thus, although I appreciate the problems you must have dealt with, before proclaiming J2EE portability to be a myth, it would be interesting to see what types of problems can occur when deploying a rich J2EE compliant application across J2EE certified servers.
Also, lets not forget that portability is referring to portability of the compiled code - the runtime stuff, not the deployment-time configuration tasks like descriptors. Although the configuration stuff IS a lot of work, that part was never meant to be 'portable' under the conventional definition.
<i>I am not sure if it is 'fair' to talk about J2EE portability woes between the products you have mentioned. Of Orion, JBoss, and Weblogic, only Weblogic has a J2EE certified server. </i> <br>
That is correct, unfortunately. Sun has seems to have some problem with JBoss being an open source project and is not giving it the certification, according to this article
Agreed - it is a myth. I've been working a lot lately with the ECPerf toolkit for some internal work. I have no problem getting the CMP beans deployed (they are 1.1, so most app servers seem to support that), the web app, etc. Everything else is app server specific, like tuning and entity-to-database mapping. The portability goes out the window lickity-split.
J2EE portability isn't a myth. Everything that should be portable IS portable. The problem stems from this naive belief that things like tuning and CMP mapping should automagically just "work". Vendors compete on implementation and necessarily have different tuning profiles. Ditto for CMP mappings.
Switching application servers is not a zero-cost proposition. But it's significantly lower than if we didn't have J2EE. For instance, try porting a ColdFusion or PHP application to ASP.NET, or to J2EE, or vice versa. The amount of effort is tremendously higher than having to re-map your CMP beans and tweak some performance settings.
I don't think anyone is naive enough to think that tunings and CMP mappings should work between app servers - however my point was that it presents issues when porting between app servers. I don't know - perhaps 'myth' is too strong a phrase.
Stu is exactly right. Everything can't be portable, else we would have the exact same product, duplicated X times!
We could always go to Microsoft and then you bow down to "their way" of doing everything, from coding, to configuring, administering, tuning, etc.
From an enterprise perspective changing application servers is an nice feature/selling point in the J2EE world but often not the reason most people choose to go with a J2EE solution. :) There are so many other good reasons to choose J2EE over other technologies than just portability.
In terms of portability J2EE does offer a lot but never promised to do it all. What J2EE delivers is so much more (and better) than any other similar technology. (As Stuart points out.)
CMP Portability "The Black Art"
How do you propose we offer portability on CMP? In the true nature of CMP we are talking about object persistence. (Object database or the worlds best O/R mapper that can make my objects into tables.) Before we start to complain about CMP and portability we all need to re-read the CORBA Persistence Object Service specifications.
I'll be the first one to say I am not happy with J2EE for many reasons. But, portability is the VERY LAST complaint on my long list of things concerning J2EE. :)
"J2EE portability isn't a myth. Everything that should be portable IS portable."
I think those that complain about portability perhaps havent dealt with much harder stuff to port (just try something "trivial" like porting an app written in the same language (C++) from NT to Solaris).
I dont know of anything other than J2EE where several man-years of work can be ported from one server to another in a couple of man weeks.
To pick out some points:
1) Already mentioned above, but, choosing J2EE compliant appservers makes a big difference to portability. I know that both Orion and JBoss tend not to be very strict when it comes to deployment/compliance checking. I have seen a few examples of obviously-wrong code that supposedly "worked" on Orion or JBoss - however Weblogic (correctly) would refuse to deploy it. From experience, developing on a mix of Weblogic and Borland will ensure that your app is almost 100% portable.
2) "User management, authentication and authorisation: Modifying users and groups, authenticating and authorising users are tasks that most J2EE applications need to do."
I would tend to disagree. It is definitely not the job of the application - its the job of the security infrastructure.
This tends to be a problem where there is a lack of security infrastructure - every project developing their own user database and admin tool... an administrative nightmare. However, I do sympathise - it is a pain that every appserver interfaces to the security infrastructure differently - JAAS should simplify this.
3) "CMP entity beans are beautiful but deadly - they attract developers with their simplicity and ease of use but strangle them with vendor specific management."
Firstly, any OR mapping tool requires some vendor specific DD info (the persistance store is not guaranteed to be just RDBMS). Secondly, it beats writing, changing, testing and debugging SQL any day. At least most appservers perform a deployment verification - testing your OR mapping (generated SQL) (quality of this depends on appserver, admittedly).
No, J2EE applications are not 100% drag & drop portable - a bit of effort is always required. However, with a little bit of effort at development time, most of your portability issues can be solved in a JIT manner.
Certainly its the best proposition for enterprise application portability we have had.
It's also worth noting that Sun are continually expanding the "should be portable" box. More and more, the gray areas are getting light shined into the corners.
>>I dont know of anything other than J2EE where several man-years of work can be ported from one server to another in a couple of man weeks.
I perfectly agree with your above said statement.. Why don't people estimate "Portability" in terms of "Man days" instead of "literal" meaning of it..
There is always a compromise.. more we standardise ,more the compromise we have to do on perfomance...Then everyone will scream saying M$ solution is "n" times faster than a J2EE based one...
The bottom line is "Portability" should stop at place where it becomes a overkill.. I personally feel it is not bad to spend couple of man-weeks to redeploy the application in another application stack,instead of compromising on other vital things..
Of course J2EE are not 100% portable. In my experience
the core components, the specified APIs (EJB, JMS, whatever) are portable. Of course you have to be sure that
you're not porting across different versions (porting EJB2.0
applications to EJB1.1 can't work). Even if it does not
work right away, you'll be done with a few modifications.
The problem arises with peripheral features that are not
found in any specification. Different security implementations (though JAAS will solve this, hopefully),
startup classes, clustering, vendor specific deployment
descriptors and so on. Most of this will be problem of the
past if vendors implement JMX based components, then at least you have a chance to plug-in features across vendors.
But then why is portability important? It certainly sounds
nice. Java the borderless language. Though I'm not sure if a
manager will say "whoo, that's cool. J2EE is portable. So
next month we can shell out another $50.000 for a different
So if you need to be portable (for reasons beyond me) then
deploy you're work early on a different servers. Then you
have a chance to get it to work. But you have to give up
on some features.
btw, my experience with JBoss and Weblogic are diametral to
yours. At least compared with WLS6.0 JBoss' error messages
are a lot more insightful than BEA's 'there was an error somewhere, I dunno where, I try to deploy your application
anyway' style. Let's be secular this week, let's pause
religious wars ;)
>> But then why is portability important? It certainly sounds nice.
Portability *is* important for a number of reasons - some of these have been illustrated above.
1) You may start development before you have decided on an application server.
2) You may decide on an application server but then change your mind (hopefully, before you have shelled out money).
3) You may have decided and bought an application server, but after 1 year in production, you have realised you have made a terrible mistake.
4) You may have decided on a great appserver - but the relationship with the vendor sours. They are trying to rip you off.
5) You may have decided on a great appserver, and the vendor is great too, but your company gets taken over by a much larger company - they have chosen a different appserver
6) You may have chosen a great appserver with a caring vendor, but now your company has budget constraints and cannot afford it.
In all these fairly common cases, you would normally be left with a sticky problem. However, with J2EE, you can **change your mind**.
Not only is your business logic portable, but your developers skills too.
Portability *is* important for a number of reasons - some of these have been illustrated above.
7) You are developing a J2EE Application and your customers already have a variety of J2EE servers and won't buy your software if it doesn't run on their App Server.
There is a lot to be said for portability. I Should be able to write a full featured J2EE app (with CMP!) and be able to move between compliant App Servers with little or no work. If I choose to stray outside of the spec for performance or features of a particular App Server then I'm responsible for making the conversion.
Currently this level of portability isn't available (AFAIK). But I believe that the spec is maturing and that complete portability will be possible in the next version or two. I can't wait.
"But then why is portability important? It certainly sounds
nice. Java the borderless language. Though I'm not sure if a
manager will say "whoo, that's cool. J2EE is portable. So
next month we can shell out another $50.000 for a different
There's another aspect to portability. And it relates to standards. That is, a developer can be more productive using any number of J2EE stacks the more they are the same.
This is particularly important for 3rd party developers who may deliver a solution for Client A using WLS and a solution for Client B using WebShpere.
I see the job market has already kinda segmented itself. You could be a jam-up J2EE guru but not get a gig because you don't "know" WLS specifically.
I agree, though, that true portability would be great but we shouldn't get all lathered up over it. In 2-3 years this stuff will become legacy technology.
That's what I was saying. We certainly need standards.
The core components of a system, the core specifications
are portable in that way that a developer can write e.g.
an EJB for WLS or WAS.
But there always will be small differences. You'll always
have to tweak your application.
And new features without any specification will pop up.
You can't stop that. It just takes too long for JCP to
agree on a new standard for a vendor to wait.
That may be a problem. But then what's more important:
to have features early on or portability? If most
decision makers want pure portability, then we'll get it.
One small addendum to your post:
One of the great things about J2EE is that is makes your *developers* portable, without vendor lock in. I'm a Weblogic guy right now, but I could go into a situation where I had to use Websphere and be 90% up to speed. A few weeks into the project I should be a productive member of the team.
Contrast this with any Windows technology. Yes, developers are portable, but (obviously) you have vendor lock in.
Portability is a relative thing, Mike.
Try taking an IBM MQSeries app and porting it to Tibco for instance. Two weeks won't even be a beginning. On the other hand if you use XDoclet or another product I've seen, it may be less. And once you learn the App Servers you are deploying to the time will fall I think.
Please remember, it is the code that is portable and not its deployment specifics. Also, even the code is as portable as a vendor's adherence to the agreed specification. It is quite remarkable how easy it is for us to not see the forest because of the tree. Diversity in detail is more than healthy and it is quite natural - benficial even for your job security. You must alow other people's creativity and inventivity have a go. You must give companies reasons to be involved for a profit. You must provide an alternative. If there is anything to complain about, is pure documentation, lack of relevant examples, the minimal effort that vendors take to make the initial developer experience pleasant and yes, easy.
I really wonder: do you have other experince than Java?
Some return of experience. I have been involved in the architecture and implementation of an online banking project for one big international bank.
We had written the implementation using WebSphere 3.2 and it came to testing it on the production platform we found that WAS was performing very slowly (especially with security turned on). We decided to try it on WL 5.1. The port took 2 days for the whole application before it was on our production platform ready for tests. 2 days only !
In my experience, that was the first time I could port one application from one server to another in such a short amount of time. For me, this proves that J2EE is portable to the extent that it is possible to consider it as an option (in case of problem with a given implementation or commercially to negotiate pricing :-)).
Of course, the 2 days we used to change some tuning parameters and did not involve some other elements like training the operations team, etc.
Also, to be fair we were not using Entity Beans so we didn't have to change that (and this could be a lot of work, especially if you're using proprietary performance parameters - which you have to use if you want performance !).
So I agree : portability in the strict sense is a myth. However, it doesn't to be 100% true to be useful :-)
Yes Based on my experience Portability is still a major issue.
Lets take this case ..
In our company we developed our application which
is pretty much complex and has lot of CMP's using weblogic server6.0 .But now one of our client has Websphere licence and wants to use that.
Now to make it work in WSphere
1)We have to change the deployment descriptors of all my CMP beans(which in our case is more in numbers)
2)Re-build the whole thing again and maintain 2 versions of
the DD and jar files.
This creates a lot of other problems as well.Now I am stuck with 2 versions of the DD and the Jar file .Any change like adding a column in the DB and mapping it in the CMP DD has to be done in 2 different places.
Why can't these things be generalized and vendors compete on the Implementation classes they generate (optimize it to the max),performance improvements etc.
That would be the ideal case.
You can get rid of deployment descriptors incompilance using tools like XDoclet.
You can change it to produce diffrent target DD form the the same source tags. (there could be probleme with vendor specyfic performace tags, but in many cases different servers have analogous tags with different dpeloyment descriptors)
Also other tools e.g. Jbuilder could produce different target DD from the same logic.
.. is rather positive.
We are developing stateless session beans, servlets and entity beans on jboss, although the production environment is websphere. as dbms, we use oracle, in production it will run on db2. we are developing under linux and win2k, production environment will be solaris or aix. most developing and testing is done using sun jdk. websphere requires ibm jdk.
All our components run on every platform. So, where's the problem? Ok sometimes you overlook a bug / spec incompliance on one product that has implications on another one. but with a little experience, you're able to write portable code out of the box.
One thing I think everyone is failing to realize is that not all J2EE projects are built for a single customer. Sure, the major projects we developers write tend to be some internal (or external, doesn't matter) tool or site that is made for a specific client, who has specific hardware, and has made specific requirements about what app server is being used. But there are other types of projects...
Mike and I both develop for OpenSymphony and our goal is to make truly portable, drop-n-deploy modules that are actually useful to every J2EE developer, regardless of app server. Xdoclet helps with this greatly. Today I just added Pramati support to Xdoclet and our core module, bringing supported app servers up to Orion, JBoss, Pramati, and WebLogic, all in a single deployable: "oscore.jar". This may sound like it is trivial, but it is in fact a very hard thing to actually accomplish...
...and it is _very_ useful for rapid application development and achieving a broad user base. No one has time to try to understand our OSCore module and then create (via tools or by hand) the specific DDs for their vendor of choice. To be truly useful, we need to include them such that our modules deploy without any fuss and "just work". This is not only useful for open source projects, but also for companies trying to sell truly deployable beans and services.
So Xdoclet solves lots of the portability problem, but not all of it:
.... security ....
Security just isn't portable at all, and hopefully J2EE 1.4 will fix this by introducing JAAS. Until the time that J2EE 1.4 is finished AND all major vendors support the spec, being able to distribute a single "ear" to be deployed on any app server of choice just cannot happen.
Mike has been working hard on getting a project of his to deploy on as many app servers as possible. How nice would it be to be able to distribute an application and just tell the client to "deploy xyz.ear and you're done". He is almost there, with the help of another module, OSUser.
OSUser is nothing more than a standard set of interfaces and providers (EJB, JDBC, LDAP, etc). The special thing about it is that we're working hard on providing bridges from the app server to OSUser such that vendor specific security talks to the same interface your (generic) code talks to. This way an application can do user management without needing to either, a) write vendor specific code, or b) write a special security domain for the app server that talks to their own code.
And so far OSUser has been working very well. Orion support came first, then I added JBoss. Resin was next, and WebLogic and Pramati will be coming within days. What this means is your application could do user management and deploy, without any modifications, to any of these app servers. In my opinion, this is great news for everyone. Even if your company is mandating that you use WebLogic, you could still write your application and test on your desktop using Orion or JBoss (cheaper, smaller, lightweight), and rest assured that it will also work in WebLogic also.
There have been some issues that Mike has faced though, mostly related to bugs and inconsistencies in some app servers. I won't recount all the details (as I'm sure he'd could a better job), but I do know that there are lots of holes the J2EE spec, and the idea of a _truly_ portable deployable just isn't entirely possible.
So is J2EE portable? Yes and No. At one end of the spectrum, one might say "Yes, the development skills and compiled binaries are totally deployable". At the other end, one might say "No, I can't drop in my application I just built in to server XYZ". And in between there are countless arguments. My personal feeling is that J2EE should start moving towards the latter scenario. After deployment, I do believe that an administrator should be able to tweak the deployed component to the point of satisfaction (for speed in most cases).
With the help of Xdoclet and OSUser, we're very, very close. Add with a little ingenuity and I think it is possible to make a sellable unit that works on any app server. But it isn't easy, not by any means...
I'd like to just add one more thing, because I didn't make it clear in my last post:
I think J2EE should define just enough so that any application can deploy on any app server and actually function. From that point, vendors can give extra settings to make the applications faster/smarter/load-balance/whatever. But I think vendor-specific DDs should truly be an administrator's job, not the programmers. An admin can deploy and tweak, but only a programmer can deploy, read error log, tweak DD, deploy, read error log, tweak DD, deploy find app error, tweak DD, deploy... well you get the point.
Mike and I both develop for OpenSymphony and our goal
>> is to make truly portable, drop-n-deploy modules that
>> are actually useful to every J2EE developer, regardless
>> of app server. Xdoclet helps with this greatly. Today I
>> just added Pramati support to Xdoclet and our core
>> module, bringing supported app servers up to Orion,
>> JBoss, Pramati, and WebLogic, all in a single
>> deployable: "oscore.jar". This may sound like it is
>> trivial, but it is in fact a very hard thing to
>> actually accomplish...
You forgot to add Cactus (http://jakarta.apache.org/cactus
) to the list of tools that help ensure portability across containers. It is a unit testing framework for server-side java code that let you write integration unit tests that run in the container and provides Ant tasks to automate testing on several containers.
I run Cactus own tests on 5-6 application servers and it helped me greatly to identify and work around non-compliance bugs in the different container implementations.
... just some advertising for Cactus. Sorry for this slightly OT message.
Currently, the only promise J2EE makes about portablity is that ones application will run on different App Servers, not how it will run. If I code to the J2EE spec, my code will run and my compliant deployment descriptors will be understood.
The spec doesn't solve every problem, and it shouldn't. J2EE makes the porting job from one App Server to another an admins job rather than a coder's job (as much as possible). This is preferred. In my current client engagement, we have successfully implemented a large application that runs unchanged in WebSphere 4 and WebLogic 6.1. Sure, there are a few places here and there where we have to accomidate for minor differences, but its an admins job.
However, in all honesty, portablity only really matters to product developers who want to sell applications to different clients with different platforms. However, for in house business applications that run on one platform, portablity is less important. By the time an application lives its lifetime, it'll need to port from J2EE 1.2 to J2EE 1.6 or 2.x or some other new and hot technology.
However, all in all, Java lives up to its promoise of platform independence, allowing me to develop on Windows, deploy to UNIX, and switch to LINUX. These App Servers are truely showing the power of Java.
I agree with you , The J2EE parortability is a myth. But if we pay little attention during the design and packaging of J2EE applicaiton the portability could be acheieved. Let me explain our experiences, in our j2ee product (XEUS -> https://www.theserverside.com/home/thread.jsp?thread_id=11952
) currently portable across all the big apps server players like iplanet, BEA, boroland BAS and Pramati. We have apps server specific pacakgaging targets using apache Ant that picks application server specific decriptor files,but the the ejb applicaiton remains the same. However this becomes a nightmare if someone uses CMP beans, all our entity beans are BMP's. I think User management, authentication and authorisation within the applicaiton could be possible if the apps server supports JASS. Currently BEA and Pramati supports this.
Support JAAS isn't enough. JBoss, BEA, and Pramati all support JAAS, but they don't support it in the same way. I can't use my LoginModule in JBoss and also in Pramati. It just isn't possible.
It has always been the intent of J2EE that logic be portable while implementation of performance configuration would be vendor-specific. All vendors have to be compliant to a certain extent in order to make sure that applications are portable to the extent that they comply with interfaces set forth in the specifications. I find that configuration of the hosting environment is a trivial matter in the migration of an application.
The portability of an application has to do much more with the architect's mastery of diverse systems than with J2EE. A wise architect will forsee the portability pitfalls of using vendor-specific features that introduce significant lock-in and design his/her applications around these deficiencies.
...the portability of J2EE applications might not be such that you can deploy an enterprise app in various vendor's products, !but! The ideas are the same.
In terms of intellectual portability, J2EE is a winner. I don't have to relearn from scratch each time I need to deploy into another environment. I can use the same ideas on security, transactions etc.
While I do agree that there is an effect of the particular vagaries of different app servers etc, this must be of some benefit.
J2EE Portability is not a myth but a reality as of today. No other platform comes close to what J2EE has to offer in terms of application portablity between application servers. Sure, there are some minor deployment variations and some server specific add-ons that differentiate the various J2EE implementors. But these are controlled by deployment settings in the form of XML files and do not affect the core business logic of the applications - be it Session Beans or Entity Beans. Build you applications with your business logic just once and you are ready for deploying in any application sevrer, with just some minor deployment variations / tweakings. That is close enough to reality for most developers.
Even the application server deployment variations handling is now mostly automated. ObjectFrontier's FrontierSuite platfrom provides support for building J2EE applications and provides ready made jars for deployment in most of the applications servers. And replacing one application with another is just a matter of picking a menu option - the entire application will be ready for deployment in the new application server. With active participation of tool builders and solution providers like ObjectFrontier and the vision of the J2EE platform, application portability is very much a reality today and things can only get better.
S Rajesh Babu