I agree there is something extra needed. This is true of any distributed
system - not just EJB style. I've worked for 5 plus years on CORBA and
later Java RMI systems and now EJB/J2EE.
The methods and interfaces defined during traditional object modelling
simply aren't appropriate for remote invocations. I always fought against
generating IDL from the class diagram. It creates a nasty mess that with
poor performance. Remote interfaces have to be designed using specific
idioms and patterns (like no granular get/set methods etc).
So I agree with the intent of 6,7,8. ie there is another step(s) during
which the distribution interfaces are plugged into the domain model. Don't
just think of adding session and entity beans - think distribution, think
high latency of remote call - reduce the number of remote calls as much as
possible etc etc
My problem is that having used CORBA and RMI I find the EJB model
unbelievably restrictive. With CORBA/RMI/Sockets I can plug the
distribution layer in if its needed but leave it out if it isn't. With EJB
the interfaces to the object are always remote with the attendant
restrictions (serializable params etc). I find the mixing of
distribution/persistence/transactions into one glob messes up many of the
good practices that I have adopted over the last 5+ years.
I know the best practices for using EJBs are still developing but lets not
forget the (often hard) lessons learned from RMI/CORBA. You must be very
careful about the design of the remote interfaces. All the component models
use remote interfaces for the components so buyer beware :-)
Also don't forget that the session/entity beans using RMI style interfaces
have inherently synchronous blocking behaviour for their methods.
Experience has shown that asynchronous models scale better. (With open
sockets for the TCP/IP connection you will sooner or later run out of
threads or file descriptors).
regards
Mike Swainston-Rainford
At 22:33 28/03/00 -0500, you wrote:
>No, I don't think that's correct.
>The old sequence of
>
> 1) requirements
> 2) use cases (even more important now!)
> 3) identify classes
> 4) class diagrams
> 5) sequence diagrams
>
><snip>
>So add:
>
> 6) cluster result of 3) into components
> 7) define wich components are entities (need persistence), these
> become
>entity beans
> 8) define service layer in terms of session beans
>
>Does this make sense?
>
>Frank Sauer
>The Technical Resource Connection
>Tampa, Fl
>http://www.trcinc.com
===========================================================================
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".
