[
Lists Home |
Date Index |
Thread Index
]
The other way to say it is the sender does not block and wait.
What some look for that might not be there is store and forward,
guarantee of delivery given UDP, and so on (it doesn't have to
be HTTP but...).
The real killer in bidding web services is the lack of performance
guarantees. Often, an interface comes with a performance requirement
that a query return in a second or less. It is common now to see
requirements for publish/subscribe models for systems where the
publisher has to be queried for its state (available, degraded, etc.)
and the queried unit has to answer in a second or less. The proper
response is to take exception to the requirement to use web services
because the performance requirement is mission critical. It is
important not to put the cart before the horse (bid a technology
instead of bidding the mission requirement). MQSeries isn't dead yet.
We won't know the state of practice and the viability of web services
until a few mission critical systems are procured based on this
technology. Some agency out there gets to be the first penguin.
Hopefully, they will publish results for others to use.
len
From: Ken North [mailto:kennorth@sbcglobal.net]
>> Has the ability to perform its functionality synchronously or
asynchronously
To explain synchronous and asynchronous communication, I use a telephone
example. If someone answers when you call, that synchronous. If no one
answers
but you leave voicemail, that's asynchronous.
SOAP supports synchronous and asynchronous messaging. Using RPC-style
messaging, communication is synchronous and the service provider and
consumer
maintain state. Document-style SOAP messaging (XML document in the payload)
supports asynchronous messaging because you can encapsulate state
information in
a document.
|
