Tim,
I'd be happy to, but I'll keep it short. This is a long term decision which isn't
entirely resolved.
Let me start by saying we don't have the firewall issues that Tom Jenkins mentioned,
which I'm sure
would have pushed use in a different direction. Another factor that has effected our
decision is
that DOM uses a lot of memory at least in the xml4j and now the xerces libraries.
That said, we are using XML, just not for passing domain data between clients and the
appserver. We
are using XML to communicate meta data about the domain data. This includes:
- Schema information that cannot be determined via reflection. This is mostly because
java doesn't
support parameterized classes. (So what's this a List of exactly?)
- Bean methods and parameters to be used to retrieve addition information. To use the
example from
the cashed rowsets thread, if the employer address list is null the XML meta data
would have the
bean method to use to get the list.
- Other user related information on the data. For example: default field labels and
context
sensitive tips.
A lot of this is needed because we are working towards letting users build and modify
screens. For
instance a query builder where the users can select query criteria from some large
portion of the
domain graph. But I digress.
There are two main reasons we didn't use XML to communicate data over the wire. First,
reflection is
fast once you've acquired the java.lang.reflect.Field or Method objects. The path
through the domain
graph to a given datum is specifiy in a UI field adapter or table model and retrieved
via
reflection. So you can see the meta data is useful but an xml tagged data heirarchy
isn't. A sub
reason is that objects have methods in which we can combine fields like first, middle,
last names
and titles into a single datum. If we used XML, we'd have to precompute these values
or create some
client side means of handling these special cases. Not unreasonable, just not the
direction we were
headed.
Second, we would like to conserve server resources. We wanted to manipulate objects
not XML encoded
data in our beans. That meant adding a XML translation step to the server overhead. In
addition,
there's the substantial overhead in lists of data of tagging each datum of each item.
The tagging of
each item is redundent. So this would mean two formats, one for tagging single domain
objects and
one for lists of domain objects. Again, not unreasonable or undoable, just not a
direction that fit
well with our client framework.
I hope that's helpful. I'm not sure that either of these reasons are general enough to
apply to
other people's projects. As with most complex systems, the decisions made in a small
portion of the
system design are often hard to abstract into general design patterns. I'm always
skeptical of
declarations which paint any technical design decision as black and white. Notice I
said
"technical". I have my politics too.
--Victor
Tim Endres wrote:
> > In fact we have considered using XML hierarchies instead of serialized objects,
>but haven't
> > made the transition because object methods provide us great flexibility in
>defining properties
> > for the client developers.
>
> Victor,
>
> Could you please elaborate. I for one, and I am sure more on this list, would
> like to know more about your decision to not move forward on the XML front.
>
> We are looking at this decision currently. Our system has a low enough volume
> that we are looking at XML for all data communication, as opposed to serialized
> objects.
>
> Any thoughts or experience you have on this topic would be most welcome.
>
> tim.
===========================================================================
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".
