Jan Algermissen wrote:
> And besides that, a generic interface gives the components at least a
> chance to talk to each other and *detect* changed semantic
> expectations and to deterministicly abort communication or invoke
> mechanism to cope with the change.
>
> This is just impossible if the change occurs at the interface level -
> you'd need to upgrade and re-deploy your clients first.
In the world of mobile code using Java and Jini, this is not the case. And, in
other languages which support interface based design, it can be a smaller issue.
If the client needs to use different data or a different interface, then it is
impacted by the design, and requiring an update is reasonable. For clients
that
don't need an update to continue using the data as they always have, you can
leave them alone, IFF you choose the right versioning strategy.
With mobile code, the new client gets the new interface for the service, using
the new feature(s). The old clients get the new interface as well, but
continue
to use the old implementation.
In XML based data messaging such as web services the backward compatibility
includes issues of data visibility to the clients. Because they deal with the
service implementation at the transport layer, they are more subjected to the
impact of the literal representation of the service exchange.
In other messaging systems which include an invocation layer abstraction, the
transport and the actual data is completely invisible to the client. All it
cares about is the invocation interface that it sees, not what happens under
the
covers.
There are some very important points to this for me. Are you going to spend
more time creating new services that talk to new customers that you aren't in
control of? Or, are you going to spend time modifying and growing your SOA due
to API and usage changes. Web services communications (not development
platforms) purport to enable easy communications (I'm not convinced that buying
and learning multiple tools and multiple configs per interface is an enabler).
But web services really seem to get in the way of the day to day life of an
SOAs
dynamics.
Gregg Wonderly
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
