Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

portability

 
Juan Rolando Prieur-Reza
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does anyone have experience that they would like share about porting a J2EE application or significant bean from WebSphere to another J2EE server? or from? Did you find that there were proprietary features that made it more difficult than if those features were avoided?
Thanks in advance!
 
Pradeep bhatt
Ranch Hand
Posts: 8927
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you use vendor specific feature it is quite natural to be in trouble during porting to different server. If the new server supports the feature the portability will be easy.
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
BTW, it's usually the other way around. WebSphere is RABID about adherance to the J2EE spec. In fact we find that in ports to WebSphere we encounter problems because the other servers aren't as spec-adherent as WebSphere.
The moral -- if you write to WebSphere, it'll usually run very easily on other servers.
Kyle
 
Juan Rolando Prieur-Reza
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Kyle Brown:
... if you write to WebSphere, it'll usually run very easily on other servers...

Thanks! This is a very useful piece of information. It would also be interesting to me to know if there are some features that Websphere has that are somewhat specific to Websphere. For example, there might be some extensions to the deployment descriptor, or method of deployment, or monitoring and administration. So far, it sounds like the answer is not.
[ January 23, 2004: Message edited by: john prieur ]
 
Vijay S. Rathore
Ranch Hand
Posts: 449
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Kyle,

BTW, it's usually the other way around. WebSphere is RABID about adherance to the J2EE spec. In fact we find that in ports to WebSphere we encounter problems because the other servers aren't as spec-adherent as WebSphere.
The moral -- if you write to WebSphere, it'll usually run very easily on other servers.
Kyle

First of all, what do you mean by RABID?
Second, any comment about this Redbook excerpt:

The EJB 2.0 specification does not support inheritance. However, IBM products, such as VisualAge for Java, WebSphere Application Server, and the Application Developer, provide support for inheritance structures of entity EJBs.
.......

Redbook 246819, Page 447.


 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34178
340
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kyle,
Doesn't WSAD generate some ibm-*.xmi files in addition to the EJB deployment descriptor? I imagine these would be different if porting to a different app server.
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jeanne Boyarsky:
Kyle,
Doesn't WSAD generate some ibm-*.xmi files in addition to the EJB deployment descriptor? I imagine these would be different if porting to a different app server.


Jeanne, all application server vendor have additional configuration files that go beyond the J2EE specs. For instance, WebLogic requires a weblogic-ejb-jar.xml similar to our ibm-ejb-jar-ext.xmi file. Both vendors require them for the same reason. However, this is configuration, not code -- it doesn't effect the portability of your code.
Kyle
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Vijay S Rathore:
Hi Kyle,

BTW, it's usually the other way around. WebSphere is RABID about adherance to the J2EE spec. In fact we find that in ports to WebSphere we encounter problems because the other servers aren't as spec-adherent as WebSphere.
The moral -- if you write to WebSphere, it'll usually run very easily on other servers.
Kyle

First of all, what do you mean by RABID?

I mean rabid as in foaming at the mouth insane over adherence to the J2EE specification. Every day in my job we come across porting jobs where a customer tells us "WebSphere is broken -- we did XXX in JBoss or WebLogic and it worked, but it doesn't work in WebSphere!" At which point, we can point the customer to the chapter and verse in the EJB, Servlet, or J2EE specification where it tells exactly what the server is SUPPOSED to do (and which WebSphere invariably does) and which the other vendor's containers do not.

Second, any comment about this Redbook excerpt:

The EJB 2.0 specification does not support inheritance. However, IBM products, such as VisualAge for Java, WebSphere Application Server, and the Application Developer, provide support for inheritance structures of entity EJBs.
.......

Redbook 246819, Page 447.




Sure, WebSphere supports some proprietary extensions to the EJB specification. We explicitly tell you in the InfoCenter documentation, in the redbooks, and even in books like mine that if you use these extensions your code will not be portable. For some customers that's not a concern.
Kyle
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
I always belive that, when we need to change the server, from 1 to another 1, we need to put a lot of efforts for this action, even for Java!
This is because, for example, if we use connection pool, the setting for different servers differ, and thus, once we changed the server, many issues encountered.
Nick.
 
Juan Rolando Prieur-Reza
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Kyle Brown:
Sure, WebSphere supports some proprietary extensions to the EJB specification. We explicitly tell you ... Kyle

I am very pleased with these answers (and all the controversy we provoked ).
Regarding your earlier point, ...this is configuration, not code -- it doesn't effect the portability of your code..."
This is good to know. But sometimes the "configuring" process is very burdensome (I've ported apps between AIX & Sun/Linux and other systems, and even there it was a b ). I guess I'll have to read your book and work with WebSphere in order to reach my own conclusions. Even though WebSphere and others can be used without recourse to their non-EJB2-complient features, I find that such products usually "lead you by the hand" to use their special features and make their product "easier" to use (with the later difficulty extricating your product).
Cheers!
 
Juan Rolando Prieur-Reza
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The remark in Redbook that Vijay aptly pointed out seems to be wrong:
Originally posted by Kyle Brown:
...
The EJB 2.0 specification does not support inheritance. However, IBM products, ...
Redbook 246819, Page 447.

However, this is contradicted:
EJB2.0 Spec: " The session bean class may have superclasses and/or superinterfaces." p95
...
"The entity bean class may have superclasses and/or superinterfaces." p191.
So, maybe the IBM product developers thought they were providing something beyond the spec. But the other compliant products would support bean inheritance as well.
There is one thing about Entity inheritance with relationships that can be a limitation. I think this is described in Mastering EJB...
If you have CMR fields in the superclass, and other CMR fields in the derived class, you will probably have trouble if you use the superclass as an entity as well as its sub (derived) Entity classes. It leads to illogical situations if you find, select, or update. Who owns the pk? etc. I imagine that even WebSphere does not solve this aspect of the problem.
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, the Developers (and my co-author Dan was one of the primary developers!) knew exactly what they were doing. In fact, in our book we quote chapter and verse of the EJB spec to show what is and is now allowable.
Kyle
 
Juan Rolando Prieur-Reza
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kyle,
Thank you. I don't doubt your expertise. But how do you explain the contradiction in which you (or the Redbook) says...
The EJB 2.0 specification does not support inheritance. However, IBM products, ...
Redbook 246819, Page 447

... while the EJB2.o spec says it does support inheritance?
What are those biblical chapter-and-verses in your book so I can go look?
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by john prieur:
Kyle,
Thank you. I don't doubt your expertise. But how do you explain the contradiction in which you (or the Redbook) says...

... while the EJB2.o spec says it does support inheritance?
What are those biblical chapter-and-verses in your book so I can go look?

I can't explain why the redbook says what it does. The authors were probably just trying to be as succinct as possible in stating the truth that the EJB spec doesn't describe component-level inheritance, and made a slightly overly-broad statement.
As for our chapter and verse, in Chapter 25, section 25.11 we quote from the relevant sections of the EJB 2.0 specification (spec page 194, I believe and the Entity bean scenario in Chapter 15 of the spec also).
Kyle
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by john prieur:
The remark in Redbook that Vijay aptly pointed out seems to be wrong:

However, this is contradicted:
EJB2.0 Spec: " The session bean class may have superclasses and/or superinterfaces." p95
...
"The entity bean class may have superclasses and/or superinterfaces." p191.
So, maybe the IBM product developers thought they were providing something beyond the spec. But the other compliant products would support bean inheritance as well.
There is one thing about Entity inheritance with relationships that can be a limitation. I think this is described in Mastering EJB...
If you have CMR fields in the superclass, and other CMR fields in the derived class, you will probably have trouble if you use the superclass as an entity as well as its sub (derived) Entity classes. It leads to illogical situations if you find, select, or update. Who owns the pk? etc. I imagine that even WebSphere does not solve this aspect of the problem.


Actually I just caught your last part of the question. While Dan could handle this more completely, I'm next to certain we actually DO handle this situation of handling who owns the PK in situations where there are CMR's. Hopefully Dan will chime in...
Kyle
 
Juan Rolando Prieur-Reza
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Kyle Brown:
...we actually DO handle this situation of handling who owns the PK in situations where there are CMR's...

Wow! That would be something to see. (And thanks again for the replies.)
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic