I haven't gone off on a tear lately, so I must be due for a rant!
Well put Ian. The challenge at hand here is that this is all new
territory.
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.
And, I still do not know what it means to "componentise" an
object model! This business of granularity is a tricky one. EJB
componentises the server framework to make transactions, security
and some other things easy for your components to "inherit". It
does not however make it obvious how a UML'ish object model
should be turned into those EJB components. So far all the EB's
I have seen look like rows from an RDBMS to me! I have heard
it before on this forum that EJB's ain't objects. Well I ain't ready
to throw in the towel just yet!
I think before the tools can be built, the patterns and best practices
for EJB need to be established.
"Show me the patterns"! Can anyone share the things that
were discussed at the recent summit hosted by Inprise?
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...
-Chris
> -----Original Message-----
> From: Ian McCallion [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, February 25, 1999 6:07 AM
> To: [EMAIL PROTECTED]
> Subject: EJB and object models
>
> Re:
>
> > One thing we're experimenting with, especially for data
> > which is represented by a complex graph of related objects,
> > is to send the entire state of the graph to the client as
> > an XML document. The client then interacts with the
> > local representation until it needs some logic that's on
> > the server. It's not yet clear to me whether this will
> > work - the overhead may cancel any gain. Time will tell.
>
> I couldn't disagree more with this approach. EJB was invented to enable
> thin
> clients, so what's the point of sending the entire object graph to the
> client
> and executing all the business logic there? We have to learn how to build
> richly functional reusable-in-place server components. I can't fill in all
> the
> details, but the solution must go something like this:
>
> (1) Develop a detailed business object model of the application.
>
> (2) Utilise your knowledge of the overall application, the business, the
> online
> data, integrity constraints, security, etc to carve up the object graph to
> form
> coarse-grained components. (In other words justify your status as a highly
> paid
> consultant!) When doing this you can put objects into multiple components,
> and
> you can distribute the total behaviour of an object between multiple
> components. For example you could place the "display" behaviour of the
> customer
> address object into client components and the "validate" behaviour into
> server
> components.
>
> (3) Utilise your knowledge of the processes which the application supports
> in
> order to determine the information that must flow between the components
> as the
> process executes. Devise additional PBV objects that carry this
> information
> between the components as the process executes.
>
> (4) Extract the subset of the modified object model corresponding to each
> component
>
> (5) Generate EJB code for each component
>
> (6) Test components separately
>
> (7) Deploy and collect your fee!
>
> We need the modelling tools to support componentisation of an object
> model,
> which I take to mean implementing steps 2-4 above without destroying the
> original object model.
>
> Ian McCallion
> CICS Business Unit
> IBM Hursley
> [EMAIL PROTECTED]
> Tel: ++44-1962-818065
> Fax: ++44-1962-818069
>
> ==========================================================================
> =
> 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".
===========================================================================
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".
