Hello,
>Object modeling has always been sort of naive in its treatment
>of the physical realities of how it will be deployed. For example
>there is no notation for transactions in UML. I once asked a
>Rational person about this, and his answer was "a transaction
>is just a use case". I have always thought that there should be
>a standard notation for transaction demarcation in an object
>interaction diagram.
>
>It is one thing to identify objects and their inter-relationships and
>division of responsibility. It is another to partition a model into parts
>that run on the client, parts that run on the server... and how sub-sets
>of object graphs are passed by value between them. The current
>start of the art looks like meatball surgery to me. I have never
>seen an object model that took it's physical deployment characteristics
>into account very well.
>
The reason is that deployment comes very late in the development
cycle. However, it must be addressed from the design stage. For example,
not all beans can be a entity beans :) And it's project and application
specific. <soapbox> We provide a packages of components that work together
in a set
of design patterns to solve a wide range of business problems.
For many customers, this is a major "value-add" because they provide
50% of the work. </soapbox>
>
>I think before the tools can be built, the patterns and best practices
>for EJB need to be established.
I believe the COTS group of Software Engineering Institute (SEI)
from Carnegie Mellon University, PA is working on that.
(http://www.sei.cmu.edu/cbs/index.html). Any comments John?
>
>"Show me the patterns"! Can anyone share the things that
>
I wasn't at the summit. To learn about what we do with EJB and patterns,
check out our Business Smart Components White Paper at
http://www.theorycenter.com/home/pub.htm
>I have seen Richard's "Dependent Objects" and pass-by-value
>stuff. IBM has some similar statements in their EJB documentation.
>I don't know whether IBM's recommendation jives with Richard's notion
>that dependant objects should be immutable. I am not sold that a
>client should not directly update "view/copy" objects and pass them back to
>the server for a transaction update against the real data. Having the client
>directly call setters on Entity Beans opens one up to long transactions
>and other evils for scalable systems...
IBM's dependant objects are immutable. A lightweight PBV scheme is important!
-Will
-----------------------------------
William Lee, Chief Technology Officer
The Theory Center
28 State Street, 11th Floor
Boston, MA 02109
1.617.573.5099
1.617.262.0703 (Fax)
http://www.theorycenter.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".
