Jim,
I think this is indeed worth following up on. My own work/findings are very
similar to this. The main problem with accessing the "state" of an entity
bean via the getData (I tend to use a Class that represents data and some
base behavioural attributes such as simple validation and field cross ref
checks, and refer to it as a model component), is that you narrow the
interface to the entity bean. If the only way to update the entity bean is
by passing the fill SampleData object finer grained attribute access is not
possible. And as you mention by encapsulation all the state of the Entity
into a Class (SampleData) CMP becomes problematic.
I held a discussion last week with some people early this week and we
thought that perhaps one can extend the notion of component to mean a group
of EJB's as opposed to a single EJB(point of debate/discussion!). By
considering a grouping of EJB's as "The Component" this allows for some very
interesting possibilities. Current thinking is to extend this notion to
include the coupling of a Session bean and Entity bean. The entity bean can
be "guarded" by the session bean such that all access to the entity bean go
through the session bean (proxy and/or facade patterns). This way the
SampleData class (or variants of SampleData classes that show differing
VIEWS on the entity) can be separated away from the entity itself. You could
then still allow for fine grain method accessors on the entity while
preserving a more narrow interface to the client via the session bean, this
could also address some of the CMP issues too? (BTW I'm going to look at
TOPLINK as I have to base my EJB Entities on a legacy RDBMS ).
I'm currently looking at securing access to some of my EJB's. Because EJB's
themselves have very limited support for Inheritance I need to examine the
state of the entity to see if the client can access the instance of a
particular EJB entity. To do this means I need to use the isCallerInRole etc
and possible use some vendor specific libraries (depending on EJB/Security
implementation). By putting all the checks in the Session bean that "guards"
the Entity bean I keep my entity bean simple. It for reasons such as the
above plus others I believe this area worth opening up again (admittedly I
was busy on other work during the last thread so soz if I'm just repeating
old stuff).
Should we continue this thread or take it out of the list and continue via
direct e-mail? thoughts people :)
Regards
Rob Masters
Sun Certified Java Programmer
Sun Certified Java Developer
Comcare Australia
(w) 02 6275 0632
(f) 02 657 4045
[EMAIL PROTECTED]
http://www.comcare.gov.au
> -----Original Message-----
> From: James Cook [SMTP:[EMAIL PROTECTED]]
> Sent: August 19, 1999 1:24
> To: [EMAIL PROTECTED]
> Subject: Re: Inheritance and EJB
>
> Since this topic is garnering some attention now, I though I'd post a
> prior
> message regarding the topic. I apologise for the redundancy.
>
> Original Post
> ==============
> I've thought of doing something like this, but backed off because I wasn't
> sure how an EJBServer would support container managed persistence (CMP)
> with
> this approach. This topic is also an extension to the list-thread:
> "generic
> EJB thoughts"
>
> I finally came up with a hierarchy that seems to work well, although I
> haven't tested it yet. Set your email viewer to non-proportional fonts and
> the diagram below will make much more sense (It's hard to draw UML with
> ASCII:
>
> +--------------+ implements +----------------+
> | EntityBean | <- - - - - - - - | BaseEntityBean |
> +--------------+ +----------------+
> | ejbLoad(){} |
> | ejbStore(){} |
> +--------------+ +----------------+
> | Sample | <-------+ ^
> +--------------+ +------------+ | extends
> | |
> +--------------+ contains +--------------------------+
> | SampleData | <--------------- | SampleBeanLogic |
> +--------------+ +--------------------------+
> | | SampleData data |
> | implements +--------------------------+
> V | SampleData getData() |
> +--------------+ | void setData(SampleData) |
> | Serializable | +--------------------------+
> +--------------+ ^
> ^ | extends
> | implements |
> | +---------------+
> +--------------+ | SampleBean |
> | SamplePK | +---------------+
> +--------------+ | ejbCreate(id) |
> | ejbLoad() |
> | etc... |
> +---------------+
>
> BaseEntityBean: responsible for a null implementation of EntityBean
> interface. I actually have code in this class that can optionally printout
> the time and method that is executing. That gives me some ability to view
> when the container calls my ejbLoad, ejbStore, etc. methods. Also
> setEntityContext and unsetEntityContext are implemented here.
>
> Sample: remote interface that declares the business methods available.
>
> SampleBeanLogic: only an implementation of the Remote interface goes in
> here. This looks very good as there is no EJB specific code, only business
> logic. There is also an attribute of type, SampleData which is a reference
> to the object holding the business attributes. I implement the setData and
> getData methods that pass the business attributes with a high level of
> granularity. This satisfies the purpose that started these threads and
> countless other threads on granularity.
>
> SampleData: a class that contains business attributes. Under certain
> circumstances, when a Java client is involved, these classes could contain
> field-level validation methods if the EJB server supports pass-by-value.
> This simple validation will be very useful on the GUI client, and should
> save much network traffic.
>
> SampleBean: for CMP beans, this is where the implementation of ejbCreate
> will go, and that's about it. For BMP, all of the appropriate persistence
> methods are implemented. This is very good separation since only database
> code will exist here in most circumstances.
>
> SamplePK: hasn't changed.
>
> I would also advocate the business/remote separation pattern that has been
> kicked around here. It creates yet another class, but for die-hard (aka
> Glutteous Clenchimus) OOPists you can separate the Sample class into
> SampleBusiness that is extended by Sample (which extends EJBObject). The
> SampleBeanLogic then could implement SampleBusiness to ensure that the
> appropriate classes were implemented at compile time.
>
> Could this be the holy grail of EJB design? Hardly, but it's worth
> investigating. There have been other posts that mention a name-value pair
> or
> hashtable approach to passing data to and from the client. I suppose
> name-value pairs as long as they were stored in an array to achieve
> maximum
> language/platform independence. XML would work as well. Personally, I
> think
> the SampleData class should perform better, require much less coding, and
> in
> the Java-Java world it should allow some validation to take place on the
> client.
>
> The first problem that comes to mind with this approach involves CMP. With
> the data attributes hidden behind an object reference (sampleData), how
> could these Containers know which fields to persist? For those using
> OODBMS,
> I suppose you would persist the sampleData object...problem solved. For
> the
> other 80%(?) of us, I think we're stuck, until the Containers get just a
> tiny fraction of a hair smarter and allow us to specify persistent
> attributes as "sampleData.firstName".
>
> Secondly, I know some containers that can't even handle the
> business/remote
> separation pattern I mentioned earlier, let alone handle the separation of
> the EntityBean implementation described above.
>
> I'm not sure if these shortcomings are our fault. I think we should be
> able
> to change our EJB component design to suit us, as long as it adheres to
> the
> spec. I think the container vendors should look upon this pattern as a
> feature request. Some vendors may be able to support the pattern now. If
> this is the case, I would look forward to hearing about it. If not, what
> are
> the challenges in implementing such a design?
>
> Now if we could convice Jim, Ian, the Valto folks or others to put up some
> concrete diagrams describing the ever ellusive "EntityBean as Collections"
> and the "Definitive Guide to What is a Dependent Object, and How Does One
> Use Them?" all of life's mysteries would be solved. Then we could start
> coding some applications for a change ;-)
>
> 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".
