Hi,
I think I don't understand what you are requesting. From my reading of
your message, the only difference between your request objects and an
entity bean is that your request objects would not be accessible outside
the container. Is this correct?
Already, many people recommend never accessing your entity beans directly,
but rather always through a session bean. Again, as I understand it, you
are proposing to make this enforceable rather than up to the programmer's
discipline. Why is this worth creating a new type of bean for?
Have I missed something?
Thanks
David Jencks
On 2001.02.26 05:28:01 -0500 Alexander Jerusalem wrote:
> Hi,
>
> I'm not quite sure if this is the right forum for such a discussion. I've
>
> been developing OLTP applications for years and worked with different
> distributed object platforms. For some time now I use J2EE for practical
> purposes and I think it's great but it lacks explicit support for a very
> important pattern in addition to EntityBeans and SessionBeans. The
> pattern
> goes like this:
>
> * client calls a remote method
> * The method starts a transaction
> * The method instantiates some stateful business objects and manipulates
> their state
> * The method stores the business objects and drops them (so that they can
>
> be garbage collected)
> * The method commits the transaction and returns to the client.
>
> That's what we call "get in, do your dirt and get out" in transaction
> processing. Now of course J2EE supports that pattern to some degree with
> stateless session beans. You can call a method on a stateless session
> bean,
> do some work and commit (or the commit is done automatically). What I'm
> missing is something like a RequestBean. A RequestBean would behave like
> an
> EntityBean but would exist only during a single request (=transaction)
> and
> be visible only for the code in this transaction. I don't know if I made
> clear what I mean. I want container managed persistence for the objects I
>
> manipulate inside the method of a stateless SessionBean. And those
> RequestBeans needn't be remote objects, in fact they shouldn't be remote
> objects because it doesn't make sense for a client to call them directly.
>
> They should only be usable by other EJBs specifically by stateless
> SessionBeans.
>
> Of course nothing prevents anybody from creating such objects, using a
> repository to instatiate them generically or generate them from an XML
> description or something like that. In fact I've done that. But it'd be
> nice if I could use the CMP features of an application server like jboss
> to
> load and store them in a standardized way.
>
> Regards,
>
> Alexander Jerusalem
> www.vknn.org
> [EMAIL PROTECTED]
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> List Help?: [EMAIL PROTECTED]
>
>
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
