Re: [service-orientated-architecture] Re: if f(x) changes, do you version the service?

[Michael Poulin]

I believe that having versions of the service implementation, the service interface, the contract, the end-point, etc. leads to the nightmare for any of the SOA Service consumer (including another SOA Service) and service maintenance operations. For me, as a consumer, at the moment of the SOA Service invocation, it actually does not really matter if it is an internal service's function changed or an interface; I only have to know (in the simplest way possible), if particular versions of the Service is what I need, may and can use with my current client implementation. (All three "need, may and can" are expressed in my SOA Service Contract with the Service Provider).

So, I would like to have a simplest way of knowing if I can invoke the Service version. (Certainly, we have to define how a new SOA Service version differs from a new SOA Service). I have made an attempt of describing that 'simplest way' in my article in the SOA-WebServices Journal (http://jdj.sys-con.com/read/250503.htm).

I am looking for a formal definition/description of the SOA Service Contract (I am aware of a few initiatives aimed to develop such description language) to simplify any decision making if a change is contractual or not.

- Michael Poulin


Robin <[EMAIL PROTECTED]> wrote:

I've posted a reply already but apparently, it got lost, so I resubmit
a new reply.
------------
What kind of service version are we talking about?
There could be a service version at different levels:
- version of the service implementation
- version of the service interface
- version of the contract

Changing the internal logic of a service implicitely means that we
have a new service implementation version.

If the business logic changes but not the interface, I interpret this
as: the same input message will produce an output message of the same
type but with a different content.
Also possible is that the output returned is the same but
non-functional attributes of the service are changed (response time,
security policies,...)

To my opinion, this is a contractual change and the consumers of this
service must be informed or better, should agree with that change.
Changing the interface version or creating a new contract are 2
possible means to inform the impacted service consumers.

If service consumers are unknown, unreachable or not under your
control, then the only option left is to create a second service (or a
second version of that service if your infrastructure allows you to
deploy several versions of the same service side-by-side) and mark the
previous service (version) as deprecated.

Robin

--- In service-orientated-architecture@yahoogroups.com,
"jeffrschneider" <jeffrschneider@...> wrote:
>
> If the logic in a service is changed and f(x) begins producing a new
> result, do you version the service?
>
> (Note: in this scenario, the interface didn't change just the internal
> logic.)
>
> Thanks,
> Jeff
>

---

All-new Yahoo! Mail - Fire up a more powerful email and get things done faster.

---

Get your email and more, right on the new Yahoo.com __._,_.___

SPONSORED LINKS

Computer software program	Computer software spy	Computer job
Database software	Discount computer software

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___