[
Lists Home |
Date Index |
Thread Index
]
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
|
