are EJBs portable?

[Bret Waldow]

I mean, is the implementation the same on all servers? Weblogic, WebSphere, JBoss, etc.? Write once, deply anywhere...
I'm just starting to look at EJBs, and if they're server specific, I need to decide who's server to study...
Thanks,
Bret

[Vedhas Pitkar]

Yes they are make EAR once deploy anywhere.If you are short of money then you can try the best free source app server JBoss,or there are others like Blazix,OpenEJB.If you have got moolah then go for WebSphere or WebLogic.

[Andres Gonzalez]

Well, One thing is whether the app server is compliant and another is how they implement the specification API's. I'd say the implementation is not the same in all app servers, otherwise there will be no competency. One CMP engine can be better in app server X than app server Y. But, they all must implement and follow the same contract stated in the EJB specification, for example, so if you can migrate your EJB's from app server X to app server Y with minimal problems.
I'd say that if you stick to the specification you shouldn't have problems with portability, as long as the application servers are specifications-compliant.
But, many application servers add extra functionality that is beyond the J2EE specification. For instance, as far as I know, the ejb specification doesn't mandate a single way to generate primary keys. There are many patterns that explains how to generate these keys (UUID), but there are also app servers that provide that functionality. So, if you're using that "extra" functionality and you were to migrate your EAR file to another app server that does not support that extra functionality, you will run into trouble.
Application servers also used proprietary xml configuration file (jboss.xml, weblogic.xml -not sure about this one-), etc. So you will eventually have to do minor changes to your descriptor. It's not as easy as moving the EAR file to another app server.
My $0.02
[ August 11, 2003: Message edited by: Andres Gonzalez ]

[Lasse Koskela]

One specific problem-cause when migrating J2EE apps can be the classloader hierarchy, which is not dictated by the specifications. If you're using some class visibility hacks, you could be encountering a major refactoring...

[Pradeep bhatt]

Is there a plan to include automatic primary key generation as a part od future spec?

[Pho Tek]

Most IDEs nowadays support auto-generation of deployment descriptors for different servers. If your IDE does not support it; try Xdoclet

[Lasse Koskela]

Is there a plan to include automatic primary key generation as a part od future spec?

It is part of the spec. The container is required to be able to generate unique primary keys using an Object (EJB 2.0 spec, 10.8.3).
Or did you mean a standard facility for generating primary keys for the application code's disposal?

[Pradeep bhatt]

The second one.

[Chris Mathews]

All major EJB Containers support automatic primary key generation, however this support is not mandated by the specification. This is probably partially due to the fact that retrieving auto-generated keys was not supported by JDBC before version 3.0. Now that future versions of the J2EE spec will be based on J2SE 1.4 (which contains JDBC 3.0), I would think that support for automatic primary key generation would be made standard.
Unfortunately, it is not a part of EJB 2.1. So the earliest that we would probably see this feature is in EJB 3.0.

[Lasse Koskela]

So the earliest that we would probably see this feature is in EJB 3.0.

For the interested, theserverside.com has a thread going on about what should be included in 3.0...

[Pradeep bhatt]

EJB 2.1 is not yet out but these guys have started to work on 3.0 spce. Great