[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: RE: Caution using XML Schema backward- or forward-compatib

• From: Len Bullard <len.bullard@u...>
• To: "Costello, Roger L." <costello@m...>, xml-dev@l...
• Date: Fri, 4 Jan 2008 09:05:13 -0600

What I would actually expect is a little different:

1.  A web service vendor does have a list of consumers (customers).
2.  A web service vendor coordinates changes with the consumers.
a)  May receive requests for changes.
b)  May respond to requests with published specifications for changes.
c)  Publishes a schedule of changes
d)  Maintains old service until such time as is reasonable to suspend it but
publishes this schedule.

This isn't an either/or scenario.   URIs can be used for versioning, web
pages may be published to inform, and yes, multiple versions WILL be
maintained for some time depending on the value of the service and the
prevailing contracts.

The problem of the blind exchange scenario is this is too loose a coupling.
Business systems don't work that way and give away services don't have to
care although they might.  Means of communication vary, artifacts of
communication vary but the processes are still communication processes that
vary by the amount and precision of the communication.  RDF, prose, etc. are
useful.  Ultimately the most reliable means is to send the app itself but
that contravenes the whole services notion.  On the other hand, it is how a
lot of what is done outside the web browser commodity market is done.

We keep up a significant amount of inefficiency to maintain web browser
hegemony.  Rich Internet Applications (RIAs) at the right cost make sense
where the concept is one of limited distribution over 'any access anytime by
anyone'.  It might be time to consider alternatives for the sake of
reliability.  The versioning problem is the classic example of why
pre-internet systems did exactly that.

len

From: Costello, Roger L. [mailto:costello@m...] 
 
Hi Fraser,

> what approaches we can take to a) identify impacts of 
> specific types of changes made to the data and/or behavioral 
> aspects of processing

In the scenario that I have been promoting (a web service is deployed
and is available to anyone) it is impossible for the web service to
know what data changes will impact clients, since the clients are
unknown and what they do with the data is unknown.

Consequently, the web service operates in its own self-interest: when
there is a business need, a new version of the data is created.

To minimize the impact of new versions on clients, the web service
publishes a new URL for each new version.  Accordingly, clients can
update to a new version of the web service when they have the desire or
need.

To be responsive to client wishes and to identify new business
opportunities, the web service makes available a feedback web page to
its clients.

Advantages: 

1. The web service is completely decoupled from the clients.  The web
service needs no knowledge of the clients or their processing.

2. There is no need for the web service to try to "identify impacts of
specific types of changes."

3. Versioning is based on business requirements, not on (XML) data
validation limitations.

4. Clients are not impacted by version changes, unless they want to be.

5. It's simple. 

Disadvantage:

1. The web service needs to maintain multiple versions.

Thoughts?

/Roger

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.