OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   [xml-dev] Web Services Best Practice (was: Interesting XML-DIST-APP thre

[ 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.


-----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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS