Dan OConnor wrote:
>
> Hi,
>
> Tyler Jewell, the BEA training director for Java and XML
> technologies, yesterday published an article called "What's Wrong
> with the EJB 2 Specification" at
> http://www.onjava.com/pub/a/onjava/2001/02/28/ejb.html. In this
> article, he identifies "dependent objects" as what is wrong with the
> EJB 2 specification.
This makes very good reading and I recommend others to check it out.
I concur with Tyler's comments on the 'ejbRemove' issue, but
unfortunately this appears to be unfixable unless we force EJB users
to change their existing stateless session bean code.
> I have seen indications that container managed persistence in the
> EJB 2.0 specification will be modified significantly from its
> Proposed Final Draft form (see, for example, several postings to
> this news group, or the comment in the release notes of the J2EE
> beta). I hope that any changes to this (IMHO) excellent
> specification will only make it even better. I am of course
> concerned that the opposite is possible, so I hope to begin a
> discussion based on Tyler's article. (I am not part of the Java
> Community Process and do not have access to any work
> subsequent to the proposed final draft.)
In terms of dependent objects, I think that you will be pleasantly
surprised with the updated draft (and I hope we will be too when we
get to see it ourselves).
I think it would be wise to "wait and see" and then have a discussion
on the next draft.
> First, I would like to correct what I believe was a fairly basic
> technical mistake in Tyler's article. He says, "Dependent objects
> don't require primary keys." I would like to suggest that the
> opposite is the case, and I cite from 9.4.4.1 in the spec (proposed
> final draft): "The dependent object class instance must have a
> primary key value that is unique across all instances of the
> dependent object class."
>
> Second, I would like to talk about implementations of this spec.
> Tyler says: "Despite the number of vendors that have embraced the
> EJB 2.0 specification, I'm not aware of a single vendor that's
> implemented dependent objects, including BEA WebLogic and
> JBoss Server, which are usually the most updated
> implementations. It's likely that the confusion described here is felt
> by others in the industry too."
>
> It is not particularly surprising that there are no commercial
> implementations of a draft specification. Some vendors have
> expressed on this list a distaste for providing implementations of
> draft specifications as not being in the best interest of their
> customers, and I take them at their word. However, there are at
> least two vendors who have implemented dependent objects for
> preview to customers: Orion Application Server, and my company
> MVCSoft, which provides an "educational" version of an EJB 2.0
> persistence manager for (ironically) JBoss Server. I have personally
> implemented the majority of the specification, and I feel confident in
> saying that confusion would not defeat the engineers at any major
> application server vendor, including BEA.
>
> To be fair, Tyler may have meant that vendors have not
> implemented dependent objects because they did not feel the
> concept would survive to the final iteration of the specification. I can
> pretty much guarantee that the JBoss community did not feel this
> way at the time the EJB 2.0 proposed final draft was released. This
> is significant only because he cited JBoss in particular, along with
> his own company.
>
> Tyler has three specific objections to dependent objects. They are:
>
> (1) [Tyler:] "Dependent objects are meant to be all things to all
> people." [Dan:] Specifically he is referring to their dual use as local
> fine-grained objects and as objects that track the life-cycle of their
> parent. I honestly don't see why this dual use is bad, so I find it
> difficult to voice agreement or disagreement with this point. For that
> reason, I hope some list residents choose to respond to this point
> in particular (with clarifications, agreement, or disagreement).
>
> (2) [Tyler:] "Dependent objects have a cascading delete
> deployment descriptor option that instructs a container to manage
> the destruction of dependent objects attached to parent objects.
> This is needed to manage life cycle objects. The other
> characteristic needed to support life cycle objects, an automatic
> creation mechanism, does not exist, which makes the intentions of
> the specification developers murky." [Dan:] It seems to me that
> these two operations in the life-cycle of a dependent object are not
> symmetrical. The cascade-delete rule can often be specified free
> from context data (e.g. delete the line item whenever you delete the
> order) but creation almost always requires context data (how could
> you create the line items apart from application logic?) So I do not
> find this objection compelling.
>
> (3) [Tyler:] "Since dependent objects can only be accessed locally,
> home and remote interfaces are not necessary." [snip...] "The
> additional syntax that an EJB developer will have to learn will
> confuse new developers." [Dan:] I have two comments in response
> to this: [A] It seems to me that the inclusion of home and remote
> interfaces for local objects adds unnecessary complexity to the
> development process. Of course, most people will use tools to
> generate them, but still there are extra files to keep in synch; to
> worry about when debugging; to manage in your development
> environment; and to scan through when writing and maintaining
> code. Also, [B] it seems to me that providing home and remote
> interfaces for local objects implies the wrong semantics. Why
> provide remote interfaces for local objects? This is more likely to
> confuse developers than the simple semantics of a dependent
> object.
>
> I am a big fan of the EJB 2.0 specification's persistence model.
> However, there are definitely people with a different point of view.
> (See, for instance, the comments on this article at
> theserverside.com.) There's always room for improvement, and if a
> new version of the specification were to get rid of dependent
> objects (as Tyler suggests should happen) this could indeed be an
> improvement. However, I'm not convinced based on Tyler's
> arguments, and I would welcome comments on both sides of the
> issue.
>
> Thanks,
>
> Dan O'Connor
>
> P.S. Given the identity of Tyler's employer, I hope this doesn't
> count as a Weblogic-specific question.
>
> ===========================================================================
> 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".
--
________________________________________________________________________________
Evan Ireland Sybase EAServer Engineering [EMAIL PROTECTED]
Wellington, New Zealand +64 4 934-5856
===========================================================================
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".
