• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

stubs, skeletons, home objects and interfaces

 
Ranch Hand
Posts: 567
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is a question about the structure and naming of J2EE / distributed component parts.
I'm looking at a sort of generic diagram, probably UML of a very simple distributed set-up where a client contacts a server. I see the client calls the remote interface on the client machine using a stub.
I also see that a skeleton receives the request from the client over the network, and calls the distributed component in the appserver container.
My question is about the way this relates to EJB in terms of which EJB classes run on which machines, and which are stubs and which are skeletons.
The intro that I'm reading doesn't really make this clear, at least not to me.
In my client code, I look up a reference to a home object using JNDI, and use the home object to create my client-side enterprise bean reference. Does this mean the home object is a stub?
Or do the home object and the enterprise bean both have stubs and skeletons? Or what?
Thanks in advance for any lucid explanation!
 
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
stubs and skeletons are not directly related to EJB. This is related to RMI which EJB may use to communicate across distance. RMI is used for distributed computing. if you want to know about how RMI works ask in the RMI forum.
stubs and skeletons are invisible to the EJB user. Do you still wish to know about them? If so probably should learn them after you learn EJB since it will distract you now.
 
Adam Hardy
Ranch Hand
Posts: 567
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm already distracted by them, hence my question. However I'm quite happy to forget about them. The book in which I'm reading up about EJB brought the subject up and just left it hanging there.
I couldn't piece it together within the EJB framework, which in the light of your comment is no surprise.
The reason why I was confused was that I was trying to visualise what happens behinds the scenes on the client, which is not necessarily in an EJB container at all.
Presumably the stub is just some invisible java class or classes that come into action when my client calls up the JNDI reference, creates a home instance and goes create(). To boil it down into one sentence.
 
Ranch Hand
Posts: 351
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The RMI related coding, you do have to do it by yourself when working with EJB. But it is good to know what is happening behind the scenes and what the container and architecture is doing for you.
Which book are you reading? maybe the gurus can suggest you a better source!
Thanks and Regards,
Leena
 
Leena Diwan
Ranch Hand
Posts: 351
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry!!
The RMI related coding, you NOT do have to do it by yourself when working with EJB.
Leena
 
Ranch Hand
Posts: 906
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,
I suggest Mastering EJBs I or II.
As far as I remember, there's a chapter dedicated to RMI. So it explains the stub & skeleton stuffs.
Basically, you can see the stub as a proxy the client uses for remote invocations.
The stub accepts the remote calls and delegates them over the network.
The skeleton receives the remote calls from the stub, and delegates then to the remote object.
So , while the stub is a client side object, the skeleton is a remote side one.
They are the tie between the client and the remote object.
HTH
 
Adam Hardy
Ranch Hand
Posts: 567
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
ironically that is exactly the book that I am reading and those are the chapters that prompted me to ask this question! :roll: (is that the irony smiley?)
 
Ranch Hand
Posts: 228
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A stub is nothing but a reference to a Java Class which does the marshalling of the parameters for you.
When u look up a JNDI Tree, what you get in return is the reference of the Home Interface, which u use to create the remote interface reference and based on that u make method calls. These method calls are delegated to the Stub which basically makes sure that the parameters of the method are in the wire transferable form. After doing that, the skeleton is invoked which is nothing but an Unmarshaller of the parameters and hence u get u'r original parameters(U are in the server side now). This request is then delegated to teh original object which processes it and then returns the return value to the skeleton-> stub-> caller.
Makes Sense
 
Adam Hardy
Ranch Hand
Posts: 567
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the explanation. That makes total sense.
 
JeanLouis Marechaux
Ranch Hand
Posts: 906
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Adam,
I took a loot at my library yesterday eve and there's another book where the RMI stuffs are describes (stub, skeleton, (un-)marshalling, ..)
Try this one from Wrox
 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
according to my understanding ,
In EJB we have Ejbhome,EjbObject,EjbBean.We also have stubs and skeletons for EJBhome and EjbObject both lets traverse through Client code:
1) context.lookuphome()
This step will actually looks up for EJBHome and returns the caller EJBHome Stub.
Think of stubs as some network aware code which actually opening socket on Server where EJBHome SKeleton is listening for EJBHome Stub's request.
2) EJBHome.create()
This method is actually called on EJBHome STUB which we received after step 1.The call is send to EJBHomeSkeleton(more of RMI mechanism)
3) EJBObject <= after receiving it from step 2
The Call from EJBHome Skeleton is forwarded to already created EJBObject Skeleton which first instantiate the EJBBean ,keeps the reference in EJBObject skeleton and then EJBSkeleton returns the network aware EJBObject Stub.Which from
now onwards will be referred as our remote interface object in Client code.
4) So from now on whatever remote method we call on remote interface (EJBObject Stub received) will remotely Call those method on EJBObject skeleton, and in turn EJBObject skeleton will call our Bean's method.
Hope this would help..as I said according to my understanding.Though oreilley and Ed-roman would be better to refer.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic