[
Lists Home |
Date Index |
Thread Index
]
Take the frequency of the message type into account. A coarse
grained message is typically large. A high rate of requests
might suggest that you load some of that back to the client
where possible. There is a concept called "occasionally
connected" in which a client has a copy of the data and
most of the at-point-of-entry validation logic. This
proves useful in our business in field reporting applications
in which the update does not need real-time or even near
real-time access. One has to step back and analyze the
characteristics of the enterprise itself (nested processes,
linear and non-linear processes) to find out if the
paradigm of occasionally-connected works. The environment
affects this; for example, unreliable cell phone connections.
Orchestration/Choreography accounts for timing of events,
intensity of events, duration of events. Music or dance,
the dancers should not fall on their butts because the
drummer suddenly decides to reverse the syncopation.
len
-----Original Message-----
From: Roger L. Costello [mailto:costello@mitre.org]
I started this discussion on the other list and have been truly
fascinated by its flow. Thanks everyone!
I have been trying to summarize and organize in my mind all of the
discussion. It seems to me that the discussion is leading towards a
"best practice" for using XML messaging (i.e., SOAP):
1. Stay away from using XML messaging to do fine-grained RPC. For
example, stay away from a service which returns the square root of a
number. Stay away from a service that returns a stock quote (this is
the classic-cited example of a Web service).
2. Conversely, use course-grained RPC. That is, use Web services that
"do a lot of work, and return a lot of information".
3. Consider making the XML messages asynchronous.
4. Always take the overall system performance into account. Don't
fine-tune your XML messaging when it consumes a small percentage of the
overall system time.
Any other "best practices"? /Roger
|
