EJBObject -----clarification needed.
Amer Khan
Ranch Hand
Posts: 163
posted 13 years ago
I read somewhere that some EJB servers don�t create EJBObject s.These containers intercepts the call from the stub using a type of dispatch design (like the dis-patcher from OMG �s portable object adapter [POA ]speci fication)and handles the call with-out using an EJBObject for the bean.(JBOSS is one such app-Server which does'nt create EJBObjects ).
So does this means that there might be no EBObjects at all with certain vendors?
Thanks in advance.
[
[ October 28, 2003: Message edited by: Amer Khan ]
So does this means that there might be no EBObjects at all with certain vendors?
Thanks in advance.
[
[ October 28, 2003: Message edited by: Amer Khan ]
<i>Dare to dream - everything that exists today,was once a figment of someone's imagination, nobody says tomorrow can't be a figment of your today.</i>
Kathy Sierra
Cowgirl and Author
Rancher
Rancher
Posts: 1589
5
posted 13 years ago
This is a little tricky... when you think of the spec (or anything we explain in our book), think of the objects represented as "conceptual" more than *actual physical THINGS*. In other words, the server is required to *behave* as if it fits the exact lifecycle and object interaction diagrams in the spec, but what it does behind the scenes is none of our concern, and is entirely up to the vendor implementation.
The spec (and our book) gives you a way to THINK about how it works, and to write your code and design your apps accordingly. What the Container *really* does, and the actual objects it *really* creates is up to the vendor. Most vendors will simply try to implement the Container in whatever way produces the correct spec-guaranteed behavior, but in the most efficient way (or fastest, or resource-conservative, etc. depending on that vendor's main goal).
So, what we claim is "an object" is really a "conceptual object" rather than a real live object on the heap. But it doesn't matter. Just like you are NEVER supposed to write your code based on your knowledge of a particular JVM implementation, you are NEVER supposed to write your beans or apps based on your knowledge of a particular Container implementation, unless you are choosing to take advantage of vendor-specific enhancements, in which case your bean/app will no longer be portable.
If someone asks, "Does the Container make EJB Objects?" The answer is always "YES". But what that *really* means in terms of how many *actual* objects are created, and what they implement, etc. is a completely different story.
cheers,
Kathy
The spec (and our book) gives you a way to THINK about how it works, and to write your code and design your apps accordingly. What the Container *really* does, and the actual objects it *really* creates is up to the vendor. Most vendors will simply try to implement the Container in whatever way produces the correct spec-guaranteed behavior, but in the most efficient way (or fastest, or resource-conservative, etc. depending on that vendor's main goal).
So, what we claim is "an object" is really a "conceptual object" rather than a real live object on the heap. But it doesn't matter. Just like you are NEVER supposed to write your code based on your knowledge of a particular JVM implementation, you are NEVER supposed to write your beans or apps based on your knowledge of a particular Container implementation, unless you are choosing to take advantage of vendor-specific enhancements, in which case your bean/app will no longer be portable.
If someone asks, "Does the Container make EJB Objects?" The answer is always "YES". But what that *really* means in terms of how many *actual* objects are created, and what they implement, etc. is a completely different story.
cheers,
Kathy
| It is sorta covered in the JavaRanch Style Guide. |