One of the promises of J2EE in general and EJB spec in particular was reusable objects AKA "write once - deploy anywhere”, which meant to be "VB killers". It has not happened.

Full text is here

This is a major problem.

Businesses must be absolutly certain that when they commit to a vendor, its the right choice.

Something def needs to be done here.

Hello
just for a complement because i have never had experience in this way :
if a ejb is deploy on websphere and i need to deploy it on weblogic, is it true that i just need to define the xml files - descriptors - for weblogic (with tools of the market) or is it a dream ? If i just need to specify the xml files it's better than develop again the ejb. no ?

Most vendors have forced you to use vendor specific classes or ways of doing things to make it impossible for you to move to a different app server easily.

For example: If you were implementing web services using workshop on a WLS, many of the calls to tie together your EJBs are implemented in such a way to only work for WLS only, and would require you to move the run-time environment too.

Therefore it is possible, but pointless.

> just for a complement because i have never had experience in this way :
> if a ejb is deploy on websphere and i need to deploy it on weblogic, is it true that i just need to define the xml files - descriptors - for weblogic (with tools of the market) or is it a dream ? If i just need to specify the xml files it's better than develop again the ejb. no ?



That's true, but hardly doable unless you know both weblogic and websphere on expert level.

This is really possible. I use some EJBs from LPortal (JBoss) to be integrated in OpenUSS (JOnAS) easily. Yes, easily! I just need to define a new vendor specific XML DD and it works fine.

Greets,
Lofi.

That's exactly what I'm talking about. You have to edit vendor-specific configuration files to deploy into a particular container. It means the one who does it should have expert knowlege of both containers. It is not "write once - deploy anywere". It's "write once - modify configuration for each container". And dont' forget that you have to regress your modifications before using them.

Frankly, I don't understand what is the challenge to have something like

<entity>
<ejb-name>ConfigEntity</ejb-name>
<home>MyHome</local-home>
  <remote>MyRemote</local>
<ejb-class>MyBean</ejb-class>
<persistence-type>Container</persistence-type>
<prim-key-class>java.lang.Integer</prim-key-class>
<reentrant>False</reentrant>
<cmp-version>2.x</cmp-version>
<abstract-schema-name>Config</abstract-schema-name>
<cmp-field>
<field-name>id</field-name>
<table-column-name>MY_ID</field-name>
</cmp-field>
<cmp-field>
<field-name>name</field-name>
<table-column-name>MY_NAME</field-name>
</cmp-field>

EJB is all about component. Let's say you have your "ConfigEntity" as you mentioned in your example. You will have to edit your XML file (the vendor's independent or/and vendor's dependent XML file) if you want to "map" your component into the real situation. For example if you have another table name or attribute. Whether you have to edit the vendor's independent or dependent, it doesn't matter.

Another example is the COMP and JNDI name. You also "map" this name from your component (COMP) into the real situation (JNDI). This is where the "Component Deployer" should work. By dividing the vendor's independent and vendor's dependent XML file, you make it easier for the component deployer.

EJB is not about writing a utility class or a simple "Person" class. EJB is designed for Enterprise environment, where you will have ERP, messaging, mainframe, etc. In such an environment you always need to map your component into the real system. For this purpose you will always need to have vendor's dependent XML file, so the component deployer can take the advantage of his real environment. Therefore we will always need the vendor's dependent XML file :-)

Cheers,
Lofi.

Slava,

Just put yourself on the places of EJB spec Chief Architect and/or EJB container Architect. Do you have something better to propose?

Alex

Alex,

I certainly do. I know the answer to the question if it matters.

Regards,

Slava Imeshev