Hi David,
I agree with you it's nothing terribly different. But if you weren't able
to refer to the EntityBean from outside the SessionBean that created it by
design, it wouldn't be necessary for them to have Remote interfaces at all.
Remote interfaces require that all parameters be serialized on every
invocation of a method. I know that most application servers optionally
optimize that away but that's not standard and they still have to check
permissions and so on. EntityBeans are heavy weight objects which is
emphasized by the EJB spec as follows:
<quote>
Every method call to an entity object via the remote and home interface is
potentially a remote
call. Even if the calling and called entity bean are collocated in the same
JVM, the call must go
through the container, which must create copies of all the parameters that
are passed through
the interface by value (i.e., all parameters that do not extend the java.rmi.
Remoteinter-face). The container is also required to check security and
apply the declarative transaction
attribute on the inter-component calls. The overhead of an inter-component
call will likely be
prohibitive for object interactions that are too fine-grained.
</quote>
So I'd like to have light-weight simple Java Beans but with container
managed persistence.
Regards,
Alexander Jerusalem
www.vknn.org
[EMAIL PROTECTED]
At 16:55 26.02.01, you wrote:
>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]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
