[
Lists Home |
Date Index |
Thread Index
]
Of course, anyone who has done this for long
knows that the hard problem is that unless
one is very high level (weakly referenced
semantics), document types for negotiation
vary wildly. Each RFP includes terms and
conditions which must be answered in detail
and with exacting attention to the precise
language of each request/response pair. This
is very much human-in-the-loop processing.
Once we drop below the level of document type
itself, local process controls may take over,
but these are essentially workflow routing,
recording responses, etc. There is not
enough for a web service to do. The UDDI or
such can offer a set of high level categories,
but the user must select an instrument/document,
then determine its requirements for the
process or request/response to follow. Once these
phases are complete, selection and downselection
begins resulting hopefully in the so-called,
"shortlist" that starts a best and final offer
process. When the award is announced, this
does not mean product is proffered, but that
another round of negotiation, the contracting
process begins.
Some businesses can do business at these levels
of complex processing, and some can't or don't.
Environmentally, organizationally, and finally
personally, there are wildly varying document
types that might be applied. So while it
is systemically easy to say that web services
offers solutions, or that REST is appropriate
for this, the tasks that can be reasonably
standardized after discovery (qualification
and selection), are not that many.
len
|
