[
Lists Home |
Date Index |
Thread Index
]
Those
are my conclusions as well.
I
think the appropriate tool for messaging is scenario modeling. The trick
is to not pass
all of
the possible names, but to pick names that *work* in all of the possible
scenarios.
HTML works because the primary consumers are
humans. By extension, XML works
because the primary consumers are
machines.
There is a sort of meta-management theme:
Mgt
101: Conservation of Power. It is a bad idea to use an amplifier
where a filter is wanted.
Don't
confuse signal processing with amplification, or noise with lack of
power.
Thanks
Joe.
len
Comments inline.
Kind Regards,
Joseph Chiusano
Associate
Booz Allen Hamilton
700 13th St. NW, Suite 1100
Washington, DC 20005
O: 202-508-6514
C: 202-251-0731
Is
domain modeling an appropriate approach to message
modeling?
In
other words, if you want to model a message exchange pattern, would you
use
the same tools you use to model an ontology?
[JMC] Assuming such tools were mutually exclusive regarding their
capabilities (they did not have the capability to model both message exchanges
and ontologies), I would say no. However, the messages that can be exchanged
can be driven by a domain ontology (i.e. "what types of information can/should
we exchange?"), so it would be good if there were interfaces between such
tools, or that a single tool had both capabilities.
Would you use the same tools you use to model a database schema to
model a message schema? Would you use the same interview
techniques?
[JMC] Partly - thinking in terms of the message payload vs. the
message infrastructure. The overlap would be for the message
payload.
Joe
As I
read the blogs on hi-REST and lo-REST, I keep thinking, one shouldn't
try
to model messages as if they were data, that a messaging system is
orthogonal to a database and that this
is a conceptual impedance at the
heart of many a tempest in a teapot with respect to the web
architecture,
REST, and SOAs.
len
| 