I had thought about the idea of coming up with a generic presentation layer
that could
reside atop EJBs. Some folks really disliked the idea, because they felt
that it'd bind
the beans tightly to the presentation layer (which is exactly what the
multi-tier thing
is trying to avoid). At this point, my thinking on the subject is still
rather fuzzy, but I
think there's something to it.
Drilling down the other direction into the layering hierarchy, I've been up
to my
eyeballs in IBM's ComponentBroker app server for the past month or so. The
ComponentBroker architecture goes to great lengths to separate business
objects from data objects, data objects from the actual persistence
mechanisms,
etc. It's really quite cool.
http://www.software.ibm.com/ad/cb/
An article on deploying EJBs in ComponentBroker
http://service2.boulder.ibm.com/devcon/news1298/artpag10.htm
Why am I rambling about ComponentBroker? Because the architects
obviously did a lot of grappling with the sort of issues that come up here
on
a regular basis (representing relationships among objects, interacting
with legacy systems as persistence engines), and came up with an
architecture that reflects the functional layering that folks seem to be
looking for. (Basically, you have Business Objects (which are basically
entity beans), which have Data Objects (which contain the state of
the business object), which have Persistence Objects (which map the
data object to an actual persistent store). The hierarchy extends
both upward and downward from there, but that's the core
abstraction).
===========================================================================
Tom Valesky -- [EMAIL PROTECTED]
http://www.patriot.net/users/tvalesky
-----Original Message-----
From: James Cook <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Monday, June 14, 1999 4:00 PM
Subject: Functionality Layering in EJB
>I would like to expand on a concept the was introduced here by Tobias
>Dezulian in the "generic EJB thoughts" thread. It seemed that a couple
>respondents whom I have enjoyed reading here were highly enthusiastic about
>Tobias's concept, and I wanted to find out more.
>
>Concept
>=======
>Separate an EJB into logical layers that would allow some reuse of common
>business functions. This approach may also provide further encapsulation of
>data access, business logic, and core functionality.
>
>Rickard mentioned that he had considered the breakup of a bean to consist
of
>4 levels. I wanted to mention what I was thinking and see if others have
any
>input.
>
>Level 1: Generic code necessary in all beans.
>I would imagine that this could be a superclass that consists of some
>concurrency control to keep track of a bean properties' original values. In
>the case of BMP, these values could be compared against the database to
>determine if user modified fields had changed since the record was
retrieved
>from the database. We use a reflection class and a hashtable to automate
>this process now. (Rickard may have intended this with his mention of
"dirty
>flag mgmt".)
>
>Would it be possible to include debugging messages that correspond with the
>SessionBean or EntityBean interface here, even though that interface is not
>"truly implemented" in a higher layer? Could you still invoke
>super.ejbPassivate() which is in class BeanLayer1, while in BeanLayer3?
This
>of course assumes that BeanLevel3 extends BeanLevel2 extends BeanLevel1.
>
>Level2: Basic bean attributes.
>This layer would serve as the object/struct that gets serialized to the
>client allowing for a level of granularity above the "per attribute" level.
>This layer should be written to allow multi-language clients to receive a
>copy of the struct for client-side processing. Rickard mentions that this
>layer would contain CMP fields, which it does.
>
>Level 3: Implementation of Home interfaces. (extends home interface &
>EJBHome)
>Creation and Finder methods are implemented. For BMP this will involve the
>communication required to persist the object, if any.
>
>Level 4: Implementation of Remote interfaces. (extends remote interface &
>EJBObject)
>Business logic would go here. I am considering the separation of the Remote
>interface from the Home because of the database access required for BMP is
>not "pure" business logic, and could be moved to another layer.
>
>Is this approach really obscure? Will it break most of the tools that the
>App Servers are shipping? Is there other suggestions?
>
>Please give your criticism freely and keep in mind that I haven't written a
>substantial EJB bean yet, nor have I designed a system that relies on EJB.
>There may be some grievous errors that I have overlooked. Please let me
>know.
>
>jim
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
