EJB design: Basic Douts..

  1. Basic Douts.. (7 messages)

    Here are some of my Basic Doubts about EJB:- Please Answer If you know about these.

    1.For each client look up, will a new reference of the bean home be created? what is the caching involved here?

    2.When to use session bean for data access that can be done thru an entity bean?

    3. which one is better - using a servlet to invoke the Entity bean or to use a session bean to invoke the Entity bean?

    4. What is the use of a Factory pattern?

    5. What is the use of Foundation classes?

    6. Why this much of complexity involved in EJB architechture?

    If you feel like you know the answers but dont want to answer coz of the time it would take up, guide me to some url where i can find answers for them..

    Threaded Messages (7)

  2. Basic Douts..[ Go to top ]

    I'll attempt to answer these questions, although most of them are "design" questions that have no clear answer. Feel free to post follow-ups :)

    1. A new reference will probably be created, although it is possible for an Application server to optimize this in some cases. Creating a new reference is just a matter of creating a little "stub", not an entire home object, so the performance penalty is not very large. However, if you wish to optimize this behaiviour a bit you can hold on to the home reference (this is common in session beans for instance) and you can also use a Handle which will probably be a bit faster.

    2. My opinion is, use entity beans whenever possible and think twice before using session beans when you want to *represent* data. Sometimes, however, you may want to query the data or otherwise traverse it in a way that represents an "action" in your application more than it represents "data". For instance, you may want to search the list of website entries in your search engine. While it makes sense to represent these entries using entities, the "search" operation (which is not just a simple finder - it is more dynamic and complex) may be represented as a session bean method. In many of these cases, performance issues force you to access the data directly in the session bean rather than using the entities.

    3. This question really has no clear-cut answer. I can only say that what I believe to be the most common (and perhaps most suitable for novices) is servlet-session-entity. This kind of arrangement stems from two different major design patterns: session facades and MVC. The use of the two is quite similar. You can see a good comprehensive example of an MVC architecture in the Java Pet Store application, and a thourough discussion of the facade pattern in the patterns section of this site. Note that it's easy to get the two mixed up, and most implementations do a bit of both.

    4. Are you asking this in general, or specifically about EJB? Factories are commonly used in EJB (as in the rest of the Java world). Two examples are Home interfaces and Resource Factories (e.g, DataSource with JDBC).
    Of course you may design your own code to use Factories. They are useful in your EJB code just as they are everywhere else.

    5. I don't even have a clue as to what you might mean. Care to rephrase/explain?

    6. This is the most un-answerable question you asked :) This is because it is really a matter of opinion. Some answers might be:
    - Overdesign: the spec is over designed. It is too general and not focused enogth. It includes many components that are useless, and pays small attention to the important topics. Also, it tries to address issues that are non of it's business (persistence is a big one that get's flamed a lot).
    - Political spec: the spec is designed and influenced by an expert group with members from many companies that would potentially implement EJB. Each expert tries the pull the spec in his own (company's) direction, and the spec bloats up in an attempt to accomodate everyone.
    - Big problems, big spec: the spec is designed to deal with a very big and complex problem (reusable enterprise-scale components). Because of this, it must address many issues, hence it's large size.

    I'm sure other people can think of other reasons. In my opinion, the first two reasons have some influence, while the third is the largest and most profound reason.

    Good luck
  3. Basic Douts..[ Go to top ]

    Thanx a lot Gal ..so nice of you.
    By Foundation class I meant a class with same attributes as the database table which can be used for returning data from entity bean to a servlet or a session bean-as a whole. One of my friend says that if I have a foundation class, i need not put all the database field specific attributes in to the bean. But he is doubtful about specifying the find methods in xml file in that case.
    take care
  4. Basic Douts..[ Go to top ]

    I guess from your explanation that you mean "value objects". I am not familiar with the specific terminology you use.

    Value objects are objects that encapsulate some or all of an entity's data. The basic design pattern is used primarily to save network bandwidth by fetching all the data in a single request. This specific use has been slightly "deprecated" with the new local interfaces in EJB2.0, but is still feasible in many cases (specifically, where it is used by a web/client tier to render the data for display rather than by session beans to modify data).
    A value object is also a common base of designs that implement optimistic concurrency out of the database. Again, EJB2.0 deprecates some uses.

    Anyhow, beyond that fact that the value object represents the entity data, it has no necessary implication on the way you build your entity bean. Some designs derive the entity bean from the value object to add EJB specific behaiviour. This is not the only design, perhaps not the most common design, and a design that is pretty obsolete in EJB2.0.

    The use of the value object design pattern shouldn't change the deployment descriptor, including the find methods.

    If you want an explanation of this pattern, I believe there is a chapter about it that you can download for review in this site. I haven't had a chance to review it myself, but you can probably assume it is well-written like most the material available here.

  5. Basic Douts..[ Go to top ]

    thanx again Gal for guiding me..
    Now a query regarding the use of Factories..
    In a presentation given to me, it was told that the factories could be used to store references to your ejb homes to avoid look up each time. It sounds great but that presentation could not give me any clue on how to implement this. If you think you can explain this..it would be great.
    any examples?
  6. Basic Douts..[ Go to top ]

    just after the above post one more question came in to my mind - If an entity bean represants a table row, will there be same number of entity beans as the number of tables in an application?
  7. Basic Douts..[ Go to top ]


    Holding of home references: this is a sun pattern called something something 'Service' I believe. I'll show an implementation later.

    EJB's to tables : there is a pattern called 'fine grained EJBs' which is where each EJB maps to a table. This is great for code reuse, as the EJB is purely about data retrieval and storage. All business logic goes into the session facade with this model.
    However, operations on more than one table quickly become impossible, so another approach is to design EJB's as business objects. eg a person may use the user, employee, address, etc tables. However, the person object is not a good candidate for reuse.

    Also, for searching functions, fine grained EJB's are not the answer. The correct choice really depends on the project in questions.

    example service implementation:
    code up a service object with static strings holding all the jndi names. It also holds a hashtable of vectors, with the jndi name being the hashtable key, and the vectors holding home classes.

    public Object lookup(String jndi_name) throws Exception {

    So you pass in the jndi name, the class does a lookup in the hashtable to see if there is a stored reference, if so it is removed from the vector and returned. If not then a jndi lookup is performed and the object is returned.

    When you have finished with the object you return it to the service pool.

    public void free(String jndi_name, Object o) {

    You must select high and low water marks for your handles - ie so you discard some in free if you already have 10 held (say).

    Its exactly the same problem as a connection pool.
  8. Basic Douts..[ Go to top ]

    Thanks a lot Gal and Jonathan..
    hope this thread becomes useful for other beginers also.
    take care