[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Document Driving the Web Service
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|