Tim Pedone wrote:
> I'm fairly new to EJB and have been reading the archives to help jump
> start my journey. I came across an interesting thread that I had
> a couple of more questions on. In particular, the post from Ian
> McCallion regarding a proposed "strategy" for using EJB:
> >Here's a proposed "strategy" in outline:
> >2. overlay it[your DOM] with "components", Components are
coarse-grained,
> >independently deployable, distributable locales for application code and
> >will correspont to EJBs when we come to write the actual code.
> By saying "application code" (and later in the post "some logic can
be...on
> the server...some on the client) are you referring to Session Beans?
No, my original post was erroneous. I should have said:
"... and some components will correspond to
Entity Beans when we come to write the
actual code."
Other components (of course) will correspond to other runtime constructs,
for example session beans, servlets, applets, "fat" clients or scripts for
Voice response unit and call centres.
<soapbox>
Object behaviour described by the DOM transcends locality. For example, the
DOM may constrain an attribute to be (say) a date. Application code to
implement that constraint would occur in several places:
- In field validation of the C++ GUI used to enter the value.
- In the Entity Bean responsible for storing the value on a database
- In the XML parser used to process EDI requests from business partners
- (etc)
It makes no runtime sense to try to force all this logic into one place or
one language and it makes no architectural sense to regard each duplication
as a lack of architectural purity (i.e. you are a better architect than
that would imply!).
Domain objects and components are different and as a solution architect you
should ensure you have traceability to know which components are hit by DOM
changes.
</soapbox>
> The orginal question was asking for a strategy for implementing domain
> objects as Entity Beans.
> >Component will not always enclose complete DOM objects. (so that some
logic
> >for an object can be placed on the client, and other logic for the same
> >object on the server).
> In my case, all DOM objects will be stored in a database.
I think you mean that the data of the DOM objects will be stored in a
database. The code of the DOM object will be distributed around the place
and will not be stored on the (same) database.
> In order to prevent creating an Entity Bean for every single DOM
> object, you're saying that I should group DOM objects into
> Entity Beans (with more than one DOM object per EB), correct?
Yes.
> If so, I don't see how these can overlap. If they did, I
> would think I would run into a concurrency issue when two
> overlapping Entity Beans need the same DOM object (and
> therefore database record).
The database is the place to address "Concurrency Issues", not the mapping
of the DOM to Entity Beans.
Ian McCallion
CICS Business Unit
IBM Hursley
[EMAIL PROTECTED]
Tel: ++44-1962-818065
Fax: ++44-1962-818069
===========================================================================
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".
