RE: SOAP and the Web
And the problem comes down to the message contents, ie, whose schema prevails. This is not different from the import/export techniques in use today, typically, requiring and agreed upon format such as comma-delimited ASCII or even XML. The two fights that consume a lot of time are who is going to change their schema (transformations won't handle what ain't there) and who pays for the extra business logic that might be required to smooth out the transactions. Still, as a means of bringing edge systems online, web services work and are cheaper than this: "The user has the option of creating the import and export definitions or contracting with our company. OTW, bid four weeks for development, the customer must provide an authoritative contact for the duration of the project, we will provide a utility to add simple fields to the database, and will only support fields and types available with our schema current on delivery." Then fight over that after award of contract. Just an aside, this work like data conversion is a loss leader. It can't be done ad hoc without standard discoverable vocabularies. Even REST can't do that. That's why the major attention can't be SOAP or REST; it has to be schema development. Ontologies are opinions; opinions are free until they become transaction controls. The IBM Web Services security paper is an interesting read for proposals on security and intermediaries: http://www-106.ibm.com/developerworks/webservices/library/ws-secmap 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