Tighter J2EE standard needed

[Scott Huddleston]

Hi Craig and Matjaz,
Just a quick question: Is there a push to further standardize J2EE/EJB?
I have experience with several different enterprise application servers that claim to be J2EE compliant, yet require their own configuration files (e.g. WebLogic 6.0 requires weblogic.xml). If, when creating an enterprise app that you want to be 'installable' on any J2EE app server, you have to create an individual config file for each server it seems to defeat the purpose (or promise) of write once run anywhere.
Scott

[Marcos Maia]

Hi, I�m not Craig or Matjaz, but take a look at the specification s and you�re gonna see that this is completely allowed. The deployment descriptor files are not part of the java code so this doesn�t hurt the write once run anywhere promise:
ejb specs: http://java.sun.com/products/ejb/docs.html
j2ee specs:
http://java.sun.com/j2ee/download.html#platformspec

[Scott Huddleston]

That's exactly my point. The deployment part of the specification just isn't tight enough. I agree that the java code usually doesn't have to be touched, but trying to juggle all the ent. app. servers in a deployment effort would be made much easier if the spec required that the app server MUST accept an EAR with the such and such files in such and such format, i.e. the deployment would succeed, I would be a happier camper.

[Matjaz Juric]

Hi,
If you follow the development of the EJB specification (as well as J2EE in general) you will see that each new specification brings the ultimate portability a step further. EJB 2 for example introduced the EJB QL which enables portability of query expressions between app servers. Source code portability is already on a high level. However I believe there will always be some vendor specific configuration necessary. App server vendors are namely allowed (and encouraged) to provide value added features to their products. You will however have to make the decision whether to use these additional features or not. In case you use them you will limit the portability.
Cheers,
Matjaz

------------------
Matjaz Juric
Author of Professional EJB

[Craig Berry]

I agree that the specification could be far more restrictive to allow for much easier portability, however, I'm not so sure that you will see true portability for a while as the server vendors try to implement their own value-added functionality.
At this point, let me throw a question out. I've seen a number of questions this week about portability of EJBs, but how important an issue is this really? I don't work in a production-quality environment so I can say, but to me, if your going to fork out a significant some of money to buy WebLogic for example, then you're not likely to be porting your beans around a whole lot. Do you guys want to develop on one type of server and deploy the finished beans to a different one? Is it just basic Java-interoperability pride that leads you to want portability?
I'm just curious has to how significant a problem this lack of portability really is?
------------------
Craig Berry
Author of Professional EJB

[Anil Vupputuri]

I dont feel EJB components can be ported easily, as EJB2.0 QL has its own vendor dependent features , so obviously code need to be changed for entity beans.
Pls refer the theserverside.com for excellent articles on server side architecture, especially EJB's.

[Scott Huddleston]

Hi Craig,
We're actually a product company that 'trys' to have a generalized solution that can be deployed successfully on a variety of app servers. You're right that most won't have this problem. To your point about vendor "value-added functionality" I fully agree. My point is that a deployment should still succeed even if you don't include a vendor-specific configuration file. This is not currently the case.
Scott

Originally posted by Craig Berry:
I agree that the specification could be far more restrictive to allow for much easier portability, however, I'm not so sure that you will see true portability for a while as the server vendors try to implement their own value-added functionality.
At this point, let me throw a question out. I've seen a number of questions this week about portability of EJBs, but how important an issue is this really? I don't work in a production-quality environment so I can say, but to me, if your going to fork out a significant some of money to buy WebLogic for example, then you're not likely to be porting your beans around a whole lot. Do you guys want to develop on one type of server and deploy the finished beans to a different one? Is it just basic Java-interoperability pride that leads you to want portability?
I'm just curious has to how significant a problem this lack of portability really is?

[faisal mahmood]

I agree but it is still possible to write a fully compliant J2EE applications if you don't use any app server specific feature. If you use a vendor specific functionality then you will need to have the flexibility to migrate the extra functionality (e.g. if possible you can extract certain jar files and move them over to the new deployment environment).

[Scott Huddleston]

Let's take a specific example. Weblogic will complain if you don't include weblogic.xml in the EAR, EVEN IF you don't leverage any WebLogic-specific functionality. It is not in our interest to have any app-server specific functionality.
Scott

Originally posted by faisal mahmood:
I agree but it is still possible to write a fully compliant J2EE applications if you don't use any app server specific feature. If you use a vendor specific functionality then you will need to have the flexibility to migrate the extra functionality (e.g. if possible you can extract certain jar files and move them over to the new deployment environment).