[this
should maybe be a story, and is under construction. I plan to add som models
etc. comment if you like! but its more to come...
]
I've been working since mid-jan now with a
reengineering of a SQL Server solution. Our task is to port the part of their
system containing Contact information to J2EE.
We have structured all
information in a sensible UML Domain diagram showing all conceptual classes.
Starting the real implementation design we need to make a couple of
architectural decisions. The communication between layers need to be done
according to the ValueObject pattern. The best strategy for this would probably
be a combination between "Updateable VO" and "Multiple VO" as described in Sun's
paper.
(For pure .NET folks out there VO's can be compared
with strongly typed datasets.)
Because
this is a application mainly aimed at webclients we need to make some decisions
regarding state preservation in the application layer. This is really also a
OR-mapping issue..
J2EE with architectural ornaments - MS Access Style
with bloatcode
The obvious simplest solution would be to route
requests from the clients directly through stateless session beans (service
beans) to the DAO's to get the appropriate VO's. Implementing the "Multiple
VO" strategy the client (or the service the client uses to access the app SOA
style) will be able to retreive either a "heavy" VO containing aggregated
information, or "lightweight" VO's containing only key/value pairs for it's
collections.
The lightweight solution would then demand another
call on the application to obtain the VO's for the aggregated objects
(which really are just structs because they are VO's). These objects can easily
be stored in client session.
This whole solution with passing VO's up and down
through the layers creates a lot of chatter and traffic. To me this does not
feel really OO. It feels like databound MS Access forms with architectural
patterns strapped to it to make it run on JBoss. The architecture becomes mere
ornaments and you could just as well have executed sql in the presentation
layer.
Maintaining complete object hierarchy
in-memory
The alternative would be to load all objects into
memory at startup or first use. This way, using stateful session beans, each
client could make requests on references to real objects directly, with these
references placed in their state on the application layer.
The big "how" in this scenario is
search. How to do an effective complex search in large object
hierarchies? If I have 4000 contacts of different types with sub-contacts and
aggregated objects etc. it would probably take ages to do what a simple SQL
SELECT could do in seconds. But the select won't work if I have to have _just
that_ object.. Not a copy..
You could, of course, maintain partial object
hierarchies in stateful beans only. But in this case two sessions would work on
separate copies of an object creating a possible lost update.
to be continued..
would all of this go away with JDO (or objectSpaces
for .NET)?