True indirection through descriptors and EJBs - Weblogic

This is a discussion on True indirection through descriptors and EJBs - Weblogic ; I have a question about the concept of referencing EJBs through JNDI, deployment descriptors, etc. My high level understanding is that this concept is supposed to allow you to define, outside of client code, where the container should look for ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: True indirection through descriptors and EJBs

  1. True indirection through descriptors and EJBs


    I have a question about the concept of referencing EJBs through JNDI, deployment
    descriptors, etc.

    My high level understanding is that this concept is supposed to allow you to define,
    outside of client code, where the container should look for EJB's and the way
    you ask for those EJBs via some form of lookup request say passing a JNDI Name.

    What i am seeing in some examples, like the pet store demo, is that the interface
    classes, both local and remote, are being defined and placed in the same package
    as the implementation classes for the EJB. Is that characterstic just a coincidence
    or intentional? Since the consumer uses the interface class and the container,
    via deployment descriptors, dictates the location where the implementation class
    is located, it seems like the client code should import interface classes in a
    generic package indepdent manner to truely reflect indirection.

    Example:

    Client Code Import:

    "import mypackage.ejb.account.AccountRemote;"
    or
    "import mypackage.ejb.account.AccountLocal;"

    Implementation Package:
    "package mypackage.ejb.account.AccountEJB;"

    1) One thing I dont like is that your telling the client code that something is
    remote or local. Shouldnt that be up to the descriptor hidden to the client and
    configurable by the container? Wouldnt it be better to just have the client import
    "mypackage.ejb.account.Account"?

    2) Your also telling the client the interface class is located in mypackage.ejb.account.
    But what if, in your deployment descriptors, you were using an implementation
    class in a different package on a different server? Is that possible?

    Seems like there should be another way/place to describe the interface. Would
    it be better to do something in the client like:

    "import mypackage.jndi.Account" and have descriptors describing that the implementation
    comes from like "mypackage.ejb.AccountEJB" on Server A or maybe point to another
    server where the package name could be "someoneelses.ejb.AccountEJB".

    Im still new to this stuff so if you say "go back and read the re-read the spec,
    its all in there", I will...:P

    Thanks for clarification

  2. Re: True indirection through descriptors and EJBs


    Not sure if this covers all of your concerns, but...

    Interface classes and implementation classes are completely distinct. They are
    connected together by the EJB deployment descriptors. They do not have to be in
    the same packages. Package names do not imply anything about "location".

    Your EJB business APIs should be remote interfaces, not local ones. That way they
    can be invoked from anywhere inside or outside the application. A local interface
    can only be invoked from within the container's JVM, so external clients cannot
    invoke them. A good design pattern to follow is to use local interfaces only for
    methods that are "internal" to the application, e.g. EJB-to-EJB calls.

    Hope this helps...

    -- Mark --


    "Ken" wrote:
    >
    >I have a question about the concept of referencing EJBs through JNDI,
    >deployment
    >descriptors, etc.
    >
    >My high level understanding is that this concept is supposed to allow
    >you to define,
    >outside of client code, where the container should look for EJB's and
    >the way
    >you ask for those EJBs via some form of lookup request say passing a
    >JNDI Name.
    >
    >What i am seeing in some examples, like the pet store demo, is that the
    >interface
    >classes, both local and remote, are being defined and placed in the same
    >package
    >as the implementation classes for the EJB. Is that characterstic just
    >a coincidence
    >or intentional? Since the consumer uses the interface class and the
    >container,
    >via deployment descriptors, dictates the location where the implementation
    >class
    >is located, it seems like the client code should import interface classes
    >in a
    >generic package indepdent manner to truely reflect indirection.
    >
    >Example:
    >
    >Client Code Import:
    >
    >"import mypackage.ejb.account.AccountRemote;"
    >or
    >"import mypackage.ejb.account.AccountLocal;"
    >
    >Implementation Package:
    >"package mypackage.ejb.account.AccountEJB;"
    >
    >1) One thing I dont like is that your telling the client code that something
    >is
    >remote or local. Shouldnt that be up to the descriptor hidden to the
    >client and
    >configurable by the container? Wouldnt it be better to just have the
    >client import
    >"mypackage.ejb.account.Account"?
    >
    >2) Your also telling the client the interface class is located in mypackage.ejb.account.
    > But what if, in your deployment descriptors, you were using an implementation
    >class in a different package on a different server? Is that possible?
    >
    >Seems like there should be another way/place to describe the interface.
    > Would
    >it be better to do something in the client like:
    >
    >"import mypackage.jndi.Account" and have descriptors describing that
    >the implementation
    >comes from like "mypackage.ejb.AccountEJB" on Server A or maybe point
    >to another
    >server where the package name could be "someoneelses.ejb.AccountEJB".
    >
    >Im still new to this stuff so if you say "go back and read the re-read
    >the spec,
    >its all in there", I will...:P
    >
    >Thanks for clarification



+ Reply to Thread