Partially answering Jan's question, let me say that version control based on
compatibility rules described in http://java.sys-con.com/read/250503_1.htm
might be a part of the strategy. In particular, SOA environment provides
utilities that can evaluate compound service version (including any changes,
in behavior and and in interface) against the policy(ies) defined by the
service consumer. If evaluation returns 'compatible' status, the service may
be used; otherwise, either consumer code or policy have to be changed. The
policy may include rules anticipating only important changes in the future,
i.e. even if a change is not backward compatible but not important to the
consumer, it may be ignored.
- Michael
Jan Algermissen <[EMAIL PROTECTED]> wrote:
Hi David,
On 12.01.2007, at 20:21, David Orchard wrote:
> I finally posted an entry on some thoughts on a more formal definition
> of SOA principles, based a bit on Roy's work on REST.
>
> http://www.pacificspirit.com/blog/2007/01/11/soa_principles
I have a question regarding evolution: you mention payload evolution
(XML language evolution) but not interface evolution. IMHO, the
letter is the far more critical issue because it is much harder to
provide a clean strategy. While a theory of versioning is doable for
e.g. XML languages, I cannot really see one for interfaces.
Since interfaces are allowed to evolve in a SOA how does one deal
with such change?
I am not asking how to handle an individual change, but how one
achieves a cliean strategy (as we have for the payload)?
Jan
---------------------------------
Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.
