[EMAIL PROTECTED] wrote:
>
> <...>
>
> None of these issues are explicitly covered in the EJB 1.0 specification. I
> view this as a major hurdle for EJB to overcome before it hits the mainstream.
> I don't like the idea of shops building their own marshaling code, since that is
> non-portable and violates the rapid application development EJB value
> proposition.
Why would you have to build your own marshalling code? EJB fully
handles RMI parameter types, which includes Serializable objects.
It seems to me that data-transfer between the client and server
should primarily take the form of Serializable objects.
What is more complicated---as you point out---is pruning the object
graph. Of course you don't want to send an object which references
half your database. The simplistic solution is for objects to contain
foriegn key references to other objects, not direct pointers. (You
can break the simplistic rule when you are certain you want to include
some referenced objects. A good example is an Order object; you would
probably want to send the associated LineItem objects with the Order.)
Another interesting issue is how you structure the data models, which
also has persistence implications. Do the client and the server use
the same data/persistence model? Or, does the server maintain its
own data/persistence model and then expose a data/network model to
the client? I tend to favor the latter, since I don't want the
entire data/persistence model exposed to the client. This means that
you wind up writing more code, but it does give the client a simpler
view of the world.
-eric
===========================================================================
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".
