Lists Home |
Date Index |
- To: Michael Kay <email@example.com>
- Subject: Re: [xml-dev] U.S. Federal Goverment's Data Reference Model (DRM)XML Schema
- From: "J.Pietschmann" <firstname.lastname@example.org>
- Date: Tue, 21 Jun 2005 22:48:35 +0200
- Cc: email@example.com
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0
Michael Kay wrote:
> The problem is that messages exchange information about a
> business object, and different messages exchange different subsets of the
It may be even much worse than that.
a) a message may lump together attributes of different business objects
b) a message may contain data from multiple business object instances
c) a message may contain aggregated data from various business objects
(of the same class or different classes), which forces either
willy-nilly extensions to the already complex business object zoo or
dealing with data which is *not* an attribute of any business object...
As an example: the answer message to "get customer credit and risk data"
which returns credit limits from various accouts of different types the
customer might have, partly aggregated by risk class, as well as the
net security worth backing part or all of the risk.
Telling the designers to make several requests, one for each object, and
aggregate in the client has already been proven to be a bad idea.
My conclusion: design objects and message separately, and use a tool
to check whether they fit together.