Jerry Zhu wrote:
>
>
> I don't see this an issue if SOA is built on Component
> technology. Since f(x) is implemented at the level of
> Component and if a change of f(x) does not change the
> COM interfaces, then nothing changes. If a change of
> f(x) changes the COM interfaces, by rule, we create a
> new COM interface to incorporate the change of f(x).
> Accordingly interfaces at Service level also changes.
> By no means this change shall break the current users
> who just donot know the new interface and act as
> nothing happened. new users that are aware of the new
> interfaces will use the updated features.
I think that interface based access is a key feature of a well designed SOA.
There must be an interface (like or implementation) description which properly
and completely identifies the type of data going in and out of a service
operation. It should be possible for a client of that service to detect an
incompatibility and it should be possible for a service to assert an
incompatable change if needed.
These things make it much more likely that incompatibilities do not create
imaginary (service responds okay to invalid request) or incorrect operations
(service misinterprets data and acts inappropriately) in your SOA.
Gregg Wonderly
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/service-orientated-architecture/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
<*> 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/
