Re: [Xdoclet-user] Entity BMP, EJB2.0

[Rickard <ri...@mi...>]

James Higginbotham wrote:

> Not to take too much of your precious time up, but a simple comment and
> question. When you were outlining the concept of using the web command =
as
> the argument to the entity bean's create(), this assumes that you don't=
 want
> stateless session beans or other components as the primary entry point =
for
> creation, right?=20


Well, what I outlined didn't really care about whether a middle layer is=20
used or not. Currently I'm skipping a session facade, and am instead=20
using home methods, which accomplishes much of the same thing. Why split=20
things up unnecessarily?

But, it would be entirely possible to use session facades as a middle=20
step, which would be useful if you for example wanted to have a uniform=20
way of interacting with the EJB layer.

> I'm sure this has its uses, and for TSS it may make the
> most sense. I guess I'm accustomed to using the stateless bean wrapper
> pattern with a createXXX(), which would do the work of calling the enti=
ty
> bean's create(). This would allow me to do pre or post processing, mass=
age
> the data a bit, or whatever else I would like to do during the creation
> process. In this case, your command pattern would still work, but it wo=
uld
> be passed to the stateless bean 'manager' for pre/post processing rathe=
r
> than directly to the entity bean's create. Make sense?


Your requirements make sense, but maybe not the implementation. Much of=20
the massaging, and or post processing, could be done in the command. It=20
could also be done in the ejbCreate method itself. For example:
public void ejbCreate(CreateMyEntity command)
{
    // Trim input
    command.setName(command.getName().trim());

    command.setEntity(this);
    command.execute();

    // Custom stuff
    this.setTimeStamp(System.currentTimeMillis());
}
--
So, you could do both pre/post processing in the entity itself. Whether=20
you do it there or in the command itself, is up to you. I would probably=20
prefer to keep the entity code squeaky clean and do massaging in the=20
command, but that's mostly a matter of personal taste I think.

> Also, I am in the process of using XDoclet to construct EJB 2.0 statele=
ss
> and entity beans for doing life's redundant tasks - user account mgmt,
> emailing, content mgmt, etc. I have seen a few sites out (like OpenSymp=
hony
> and JCorporate) offering frameworks with packaged EJBs for doing this, =
but I
> don't want to use someone's framework just for some EJBs (and I've alre=
ady
> chosen the frameworks I need). EJBs are distributed components, and
> therefore if they provide the API and data storage requirements I need,=
 then
> I will use them. I plan on offering some general-purpose open source EJ=
Bs in
> this sense, unless you know of a project that is doing this already?!=20


I don't know of any such projects, and certainly no projects that have=20
been successful, and for good reasons. There are inherent problems that=20
make it difficult to do what you're trying to do. But that's another=20
discussion, and a very long one at that :-)

> In the
> process of getting up to speed with EJB 2.0 and CMR, I've constructed a
> UserAccountManager and assoc CMPs/CMRs as a starting point.=20


Let's say I wanted to impose access checks on modifying a user, or if I=20
wanted to add custom fields to an account, how would I do that with your=20
solution? Do you have any way to handle extensibility and integration?=20
How about getting user info from various backends, such as RDBMS or LDAP=20
or XML or..?

IMHO there are vital points missing in todays toolkit in order to allow=20
wide reuse of components such as those you outline. These holes will be=20
filled, but IMHO they're not right now.

Good luck though ;-)

/Rickard
--=20
Rickard =D6berg
Chief Architect, TheServerSide.com
The Middleware Company