question on EJB, JNDI and client jars - Weblogic

This is a discussion on question on EJB, JNDI and client jars - Weblogic ; Hi, This is a very fundamental question on EJBs and their clients - what all should go into the client jar of an ejb? I know for sure that just the remote and home interface classes of the ejb are ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: question on EJB, JNDI and client jars

  1. question on EJB, JNDI and client jars


    Hi,

    This is a very fundamental question on EJBs and their clients - what
    all should go into the client jar of an ejb?

    I know for sure that just the remote and home interface classes of the
    ejb are sufficient on the client's classpath to work with an EJB on a
    totally different server, but I dont understand the logic behind it.
    If the client has to pass its object parameters over the network to
    the server where the ejb bean is located, should the container
    generated stub not be present on the client's classpath? After the
    client does the JNDI lookup of the ejb home on the server, how does it
    serialize and pass the parameters over the network if the container
    generated stub is not present?

    Any help would be greatly appreciated. Pointers to material on the
    internet which explain this/related things in detail would be a great
    help.

    Thank you,
    Anoushka

  2. Re: question on EJB, JNDI and client jars

    Anoushka,

    "Anoushka" wrote in message news:403b0c63$1@newsgroups.bea.com...
    > This is a very fundamental question on EJBs and their clients - what
    > all should go into the client jar of an ejb?
    >
    > I know for sure that just the remote and home interface classes of the
    > ejb are sufficient on the client's classpath to work with an EJB on a
    > totally different server, but I don't understand the logic behind it.
    > If the client has to pass its object parameters over the network to
    > the server where the ejb bean is located, should the container
    > generated stub not be present on the client's classpath?


    Normally RMI (and RPC generally) stubs are generated for an object
    on which calls are made. Parameters are passed via serialization.

    > After the
    > client does the JNDI lookup of the ejb home on the server, how does it
    > serialize and pass the parameters over the network if the container
    > generated stub is not present?


    There should be a stub present to make an RMI call, otherwise the
    call will fail.

    > Any help would be greatly appreciated. Pointers to material on the
    > internet which explain this/related things in detail would be a great
    > help.


    Any Java book talking RMI should work. Search Amazon for Java + RMI.

    HTH.

    Regards,

    Slava Imeshev



  3. Re: question on EJB, JNDI and client jars

    "Anoushka" writes:

    > I know for sure that just the remote and home interface classes of the
    > ejb are sufficient on the client's classpath to work with an EJB on a
    > totally different server, but I dont understand the logic behind it.
    > If the client has to pass its object parameters over the network to
    > the server where the ejb bean is located, should the container
    > generated stub not be present on the client's classpath? After the
    > client does the JNDI lookup of the ejb home on the server, how does it
    > serialize and pass the parameters over the network if the container
    > generated stub is not present?


    Most protocols (IIOP, T3, JRMP) provide a slot for encoding a codebase
    in RMI requests. The codebase is usually an http URL that specifies
    where to get classes that are not currently available to the
    client. This URL is used to construct a java.net.URLClassLoader which
    then downloads classes on demand. These classes can include stubs,
    object arguments - pretty much anything you like. There are certain
    security restrictions on the URLClassLoader which is why you sometimes
    have to specifiy a security manager in a client. T3 will for
    preference generate stubs in the client rather than download them,
    however this is not allowed in an applet - and so in this case T3 will
    also download stubs from the server.

    The net of this is that you don't have to put very much at all in a
    client jar UNLESS you can't use the URLClassLoader. In that instance
    you have to put EVERYTHING you need in the client jar.

    HTH

    andy

    --

+ Reply to Thread