Extending an EJB

Discussions

EJB design: Extending an EJB

  1. Extending an EJB (13 messages)

    Is it possible for me to create an EJB by extending it from another EJB? Revert As soon as Possible....

    Threaded Messages (13)

  2. Extending an EJB[ Go to top ]

    Hi,

    Yes, it is posible extend one EJB by another one.

    Best regards,

    Taras
  3. Extending an EJB[ Go to top ]

    I believe this needs some additional clarification. Based on the EJB 1.1 specification, component inheritance is NOT allowed. So a developer can't actually inherit one EJB from another. However, a developer can extend the EJB's implementation class and/or the home or remote interface.

  4. Extending an EJB[ Go to top ]

    Hi Steve
       It will be very helpful ; if u can elaborate on this.
       Best regards ,
    Pankaj
  5. Extending an EJB[ Go to top ]

    In version 1.1 of the EJB specification, this is detailed in section B.2.

    The basic synopsis is that inheritance of an EJB is not supported. But that interface inheritance and implementation class inheritance are allowed.

    As an EJB developer, you are responsible for defining the home and remote interfaces and the bean's implementation class. The interfaces and implementation class along with the implementations of the home and remote interfaces class (both generated by the EJB container) are what make up the your EJB.

    So if you have an EJB called Customer, here's a typical set of classes/interfaces that would make up your Customer EJB.

    CustomerHome (home interface)
    Customer (remote interface)
    CustomerBean (implementation class)
    CustomerHomeObject (class that implements the CustomerHome home interface, generated by the EJB container)
    CustomerObject (class that implements the Customer remote interface, generated by the EJB container)

    All of these classes/interfaces are what make up your Customer EJB. There is no way to simply declare a new EJB, InternalCustomer that extends Customer EJB. However, you can extend the home or remote interface and/or the implementation class.

    So if you wanted to create an EJB called InternalCustomer that extends the functionality of your Customer EJB, you would have to extend the interfaces and/or the implementation class as below:

    InternalCustomerBean extends CustomerBean
    InternalCustomerHome extends CustomerHome
    InternalCustomer extends Customer.

    HTH.

    Steve


  6. Extending an EJB[ Go to top ]

    Thanks Steve
       
    Pankaj
  7. Extending an EJB[ Go to top ]

    Steve,
    Got a problem with your answer. Presumably:

    public interface CustomerHome extends EJBHome {
       Customer create();
    }

    public interface InternalCustomerHome extends CustomerHome {
    ...
    }

    The problem is:
    what is the signature for InternalCustomerHome.create() ?

    We can't do:
        InternalCustomer create();
    since signatures cannot vary only by return type. Which means that InternalCustomerHome uses the supertype:
        Customer create();

    But then the problem is that stubs for remote objects cannot be downcast, so there's no way to access the InternalCustomer interface features, even though the actual bean implements those features.

    The most we can get is polymorphic implementation for a stable interface - we can subclass beans but not the interfaces.

    I don't think I'm missing anything - am I?

    Dan
  8. Extending an EJB[ Go to top ]

    Nope. You're not missing anything. You can't create a signature in your home interface

        InternalCustomer create();

    if you have

        Customer create();

    in your super home interface.

    The compiler won't allow it. There are ways around this, however. You're options are to not have Customer create() in your super home interface, or define InternalCustomer create() with a different signature such as

    InternalCustomer create(int dummy);

    with a corresponding ejbCreate in your InternalCustomerBean.

    HTH.

    Steve
  9. Extending an EJB[ Go to top ]

    OK, we agree.
    So, to take this a bit further, this makes it hard to apply dependency inversion techniques.
    For example, suppose in a warehouse that I have Locations and StockItems in 1 to many correspondence: a location can contain many stock items and a stock item resides in a single location. If I need a two-way relationship, then I would normally introduce an interface so that my packages are independent, such as Locatable. Then, Location has many Locatables, and a StockItem implements Locatable.

    If you're still with me, then this means that we:
    a) can't use LocationHome to hold Locatable StockItems, because all that we can ever get back is a reference to a Locatable, and we can't downcast
    b) on the other hand we could have a StockItemHome to get references to StockItem, and then use these as Locatables because upcasting is alright.

    I reckon this is a limitation that needs to be understood by EJB designers, what think you?
  10. Extending an EJB[ Go to top ]

    Dan,

    When you say dependency inversion techniques, do you mean modeling a many to many relationship?

    I believe you're stating that you have a StockItems Bean that implements a Locatable interface and a Location Bean where you want to return the StockItems within the Location. Does Location implement Locatable?

    You stated:

    > a) can't use LocationHome to hold Locatable StockItems,
    > because all that we can ever get back is a reference to a
    > Locatable, and we can't downcast

    Remember that a home interface is supposed to be used as a factory for creating your beans, they are not generally used for creating beans of another type.

    If you want to return all of the StockItems in a given Location, you would define a business method in your Location bean's remote interface and your bean implementation that returns a collection of StockItemHome. So your client code would look up a particular location and then call the business method returning the home objects (or the remote objects) of all the stock items for that particular location.

    If you want to get the location of a particular stock item, then you would define a business method in your StockItem bean's remote interface and your bean implementation that returns a LocationHome. So your client code would look up a particular stock item and then call the method returning the home interface of the particular location for that particular stock item.

    > b) on the other hand we could have a StockItemHome to get
    > references to StockItem, and then use these as Locatables
    > because upcasting is alright.

    This is OK.

    Maybe I'm missing you here.

    Steve
  11. Extending an EJB[ Go to top ]

    Hi Steve,
    this is a good thread - thx for your input.

    By dependendency inversion I don't mean necessarily many-to-many, what I means is getting rid of bi-directional dependencies which can also happen with one-to-many relationships.

    In other words, I'd like to be able to redeploy either the StockItem bean or the Location bean in different applications, and have a way of decoupling their dependencies.

    If there is a good business / architectural / design reason for a bi-directional dependency, then dependency inversion can (in "traditional" OO) save the day.

    Your solution works, but only because there is still a bi-directional relationship: Location and StockItem remain are closely coupled.

    There a write-up of dependency inversion in:
    http://www.objectmentor.com/publications/dip.pdf
    by Robert Martin.

    It's related to (and is perhaps what I'm really describing)acyclic dependencies:
    http://c2.com/cgi/wiki?AcyclicDependenciesPrinciple
    http://www.objectmentor.com/publications/granularity.pdf

    Let's keep this thread going...
    Dan
  12. Extending an EJB[ Go to top ]

    OK. Now I understand what you're referring to as Dependency Inversion. Basically, de-coupling of objects. Thanks for the articles, they contain some good info.

    I believe that Dependency Inversion is already built into EJB via JNDI and the use of Home and Remote Interfaces. So, I believe the following scenario will give the developer the required Dependency Inversion:

    LocatableHome (home interface)
    Locatable (remote interface)
    StockItem (bean implementation)

    PlaceHome (home interface)
    Place (remote interface)
    Location (bean implementation)

    Now, the Location EJB is only dependent on the Locatable home/remote interface and the StockItem EJB is only dependendent on the Place home/remote interface. If you use JNDI properly, you won't have a direct dependency between the two EJBs.

    The implementation of either EJB could be swapped out with a different implementation as long as the implementation has the same method signatures as the remote interface.

    If you want to re-use one of the EJBs in another application, you can. So if you want to re-use the StockItem EJB, you would need another implementation of the Location EJB that uses the Place home/remote interface. Or, if you choose not to have a Location EJB, the StockItem EJB would have to gracefully handle a failed JNDI look-up of the Location EJB.

    Steve
  13. Extending an EJB[ Go to top ]

    Hi Steve,
    thanks for the reply, and apols for not responding sooner.
    To be honest I still don't think that you've given me the answer, but I think I need to articulate my problem more completely. But ... this has been a good thread and I think I should raise the issue again under a new (and appropriately titled) thread. I'll try to draw up a complete description of the problem that I think remains, but in the meantime thanks again for your thoughts.
    Cheers
    Dan
  14. Extending an EJB[ Go to top ]

    Dan, Steve:

    Appreciate the discussion.

    Under what thread has discussion of this issue continued?

    Thx
    ML