Web Application Architecture questions

Discussions

EJB design: Web Application Architecture questions

  1. Web Application Architecture questions (12 messages)

    I am reposting this message here...it was originally in another thread:

    I have done quite a bit more reading on Enterprise JavaBeans since that post, and I have increased my understanding and refined my questions. I would like to propose my findings and open issues, and I would greatly appreciate your input, as well as anyone else's.

    <requirements>
    I am building a web application.
    The database behind the application will be a relational database with about 20-25 tables. It will include 1 to 1, 1 to N, and N to N relationships, in which tables of all types are being constantly updated. The two most critical and often accessed tables need to be scaled with approximately 10000 and 40000 records in mind, with one's primary key serving as a primary key to the other.
    The web server will be expected to host approximately 100 concurrent users.
    </requirements>

    <question>
    Do I want to use enterprise javabeans? If so, how do I want to use them?
    </question>

    <PossibleAnswers>
    <PossibleAnswer value=1 name="Fine grained CMP Entity EJBs that meet specification 1.1">
    <description>
    This basically ends up just being a glorified version of a non-enterprise java bean architecture.
    </description>

    <Advantages>
    Would be not having to do my own database calls, which isn't much of an advantage.
    </advantages>

    <Disadvantages>
    Having to use rmi to get my beans to talk to each other, which is supposedly much slower than if I were to just use regular beans.
    </disadvantages>

    <Questions>
    How much slower is it to use rmi vs local method calls if all my ejbs reside on the same appserver
    </questions>
    </PossibleAnswer>

    <PossibleAnswer value=2 name=Coarse grained CMP Entity EJBs that meet specification 1.1>

    <description>
    Entity bean represents independent object. All non-independent objects(eg, tables with foreign keys) are represented as dependent detail objects.
    </description>

    <advantages>
    Saves on rmi calls.
    Some database persistence is done automatically.
    </advantages>

    <disadvantages>
    Dependent objects don't map to the database, so I have to find some other means of updating the database when the dependent data is changed(this inherently violates one of the rules of dependent objects, as I understand them, since they are therefore not immutable).
    </disadvantages>
    </PossibleAnswer>

    <PossibleAnswer value=3 name="Coarse-grained BMP Entity EJBs that meet specification 1.1">
    Same architecture as number 2, just now bean-managed.

    <Advantages>
    Saves on rmi calls
    </advantages>

    <Disadvantages>
    Have to do my own database calls
    </disadvantages>
    </PossibleAnswer>

    <PossibleAnswer value=4 name="Coarse-grained CMP Entity EJBs that meet specification 2.0">
    Same architecture as number 2, except now use xml to map dependent objects to database.
    <advantages>
    Saves on rmi calls
    Persistence done automatically
    </advantages>

    <disadvantages>
    still not widely supported
    </disadvantages>
    </PossibleAnswer>

    <PossibleAnswer value=5 name="JSP and JavaBeans with no entity beans">
    This would be a fine-grained object model

    <advantages>
    No rmi calls
    </advantages>

    <disadvantages>
    Must do all database calls myself
    Unable to take advantage of pooling on entity beans
    </disadvantages>
    </PossibleAnswer>
    </PossibleAnswers>

    <Conclusion>
    To make a decision as to what to do here, the first questions I have to answer are:
    1) just how much slower is rmi than local method/object calling
    2) how much benefit do I get from pooling entity beans(I have gotten the impression from some sources that it is a lot, and from others that it is a little)

    These two questions really seem to me to be at the heart of the decision as to whether or not to use ejbs.(whether to use #5 or not)

    Pending the answer to this question, if I were to use ejbs, building coarse-grained entity beans compliant with spec 2.0(#4) would seem to me my best route because it allows me to use the container to do all my persistence.

    Assuming spec 2.0 were not available, my decision would be between Coarse grained bmp(#3) and fine-grained javabeans. The decision would again hinge on the two questions I framed at the top of this section.
    </conclusion>

    I hope this makes some sense. It seems that there are many possible architectures available, and my desire here is to frame the possiblities in a manner that allows me to choose the best one. Any help will be greatly appreciated.

    John Kelvie
  2. WebApp Architecture questions[ Go to top ]

    http://www.bea.com/press/releases/2000/0606_EJB20.html

    BEA has 2.0 support for WebLogic 5.1.

    Of course, it is beta, since the spec itself is undergoing public review.

    - Gene Florintsev
    gene at florintsev dot com
  3. John,

    I'd really like to respond to your questions, but I'm afraid I can't understand what you're asking until you provide me with a valid DTD. :-)

    Seriously, though, although I'm not an EJB expert by any means, I think you've articulated the tradeoffs incredibly well.

    If performance is the main issue, I think it will be hard to get a high quality answer without building a simple prototype that models the primary kinds of database access you anticipate that you can test on various EJB platforms, and comparing its performance to another simple prototype using only JSP/servlets.
  4. John,

       In repsonse to your 2 questions:

    1) just how much slower is rmi than local method/object calling
        I would like to point out that a high quality app. server implementation can optimize this. Inprise App. server can distinguish between beans communicating locally, and beans on different machines. Hence your question man not even be an issue.

        If your using an app. server that doesn't support local bean optimization, then of course RMI will be slower (Serialization), but unfortunately I am not sure how much slower.

    2) how much benefit do I get from pooling entity beans(I have gotten the impression from some sources that it is a lot, and from others that it is a little)

        The benefits are tremendous, and my proof is TheServerSide.com! Every message and thread is an entity bean, and is pooled. I set a timeout of 5 minutes on entity beans, that way messages on top level pages will always be in memory. Basically this cuts down database calls to nill. I am using an "isModified" strategy, to stop my beans from being stored after each read-only transaction. Thus by pooling entity beans, you are essentially creating an in-memory database.

        For your case, you say that you are constantly updating your data. Pooling will not be AS beneficial for you as it was for me (since TheServerSide is mostly read-only), but will make a lot of sense if your app. is constantly reading "mostly the same data". If your app. is infact using mostly the same rows in the database, then pooling will significantly speed up your application. The only case in which pooling will have no effect or a negative effect, is if your app. will be rarely reading the same rows from the database. A perfect example is DNA reading app. discussed in the the problem with entity beans.

      Hope this helps your decision.

    Floyd
  5. Floyd,
        Thanks, that is extremely helpful. I think using entity beans looks like a good solution for us based on what you have said. Though there is a significant quantity of infomartion being updated, there is as well a significant amount that is just being read, so the pooling sounds like and excellent feature.

    John Kelvie
  6. When you say pooling, do you really mean caching? :-)

    In the EJB spec v1.1, section 9.1.10, what Sun calls "Option A" I call caching, and what Sun calls "Option C" I call pooling. I don't know *what* to call Option B (maybe "frustrating"?).

    The way I understand it, caching means the data are in memory, and one instance has exclusive access (similar to your isDBShared pattern), so you can forgo ejbLoad()s. Pooling means the instances are pooled, and any instance can take on any entity identity, so that you definitely need ejbLoad()'s all the time.

    This starts to look more and more like an object database. . .
  7. Kenneth,

      You are correct. I was using caching and pooling interchangeably, and this could cause some confusion.

      Yes it does start to look like an object database, and thats great! In your business logic, it is better to work only with objects. The persistence of the ojbects behind the seen should be hidden, thus thinking of your entity bean layer as an OODBMS is very good.

    Floyd
  8. Ken,
    It seems Floyd means caching data between transactions. (Commit Option A)

    - dharmesh
  9. Hi,

    If an entity bean is pooled and one of the instances's value is changed, does the change propogate to all the instances? If yes, how and if no, then what strategy should one use to ensure data integrity?

    Secondly, if i'm using a non J2EE compliant database like mysql, if a third non-J2EE application alters a record, and if there is an active instance of the same record in an entity bean, does the change propogate to the in-memory entity bean?

  10. Nikhil,

       If an instance value on an entity bean is changed, then it is changed. <shrug> I don't understand why the instance value of a particular entity bean should have to propagate to other entity beans?

       As for your second question, the change will only propagate to your in memory entity bean if your app. server is set to ejbLoad entity beans before every transaction. For example, in Weblogic you can set isDBShared, this property will tell WL that either it is the sole accessor of the DB (in which case not to expect other apps. to change the DB, so don't ejbLoad before each transaction), or that is not the sole accessor of the DB (so ejbLoad before each transaction). In the former case, your changes to the DB will not propogate to the entity bean layer, in the latter, it will.

    hope this helps,

    Floyd
  11. What do you think about using coarse-grained BMP (or even CMP) entities with OR-Mapping tools (like TopLink or CocoBase)?

    I think this could be good solution for EJB 1.1. Your code will be portable between (the majority of) app servers and you will not directly code SQL-s.

    The disadventage is the additional expenses for OR-Mapping tools.

  12. Stanislav,

      I havn't used any of these tools, but I have heard only good things. The guru's seem to go for coarse grained strategies relying on OR mappers to do their work.

    Floyd
  13. I think the just of your question was 'How should I use EJB to build my application?'

    Here are some thoughts that comes to mind:

    1. Get a product that will do the object to relational database mapping for you. A product like TopLink that is now part of the WebGain Studio(Visual Cafe) product line. This will allow you to really utility CMP... especially when you start looking at 1-N, N-N, etc.

    2. Consider how/if you will front your entities with business object abstractions in the form of session beans. This may impact your 1-1, 1-N, N-N assumptions.

    3. Thinking about what type of transactional boundries you will have to establish. This will significantly impact your fine/course grained plans at the perstence tier.

    4. Make sure that you use the ValueObject pattern for passing back the data of an entity bean as a serialized object. This will reduce the number of round trips that you have to make. Be careful though... ValueObjects are snap shots, and can become stale in fairly dynamic systems.

    5. Always program to the interface.

    6. Keep it as simple as possible.

    Thoughts?

    bmatalus at fusionally dot com