Robin,
You raise some excellent points. Note, all I said was that it had
to be versioned due to the realistic fact that everytime a service changes
you cannot expect the service consumers to change as well, at least not for
some period of time thereafter. This is pragmatic stuff we learned from the
early days of EDI.
To your point more succinctly, what are we versioning when we
version a service. Loose coupling means we do not have to version the
implementation as long as the interface stays the same. Hence, I can fix or
change my zero-bond calculator to provide the street with the best deal for
me without impacting their systems that have consumed my zero-bond
calculator to price them for clients. So, I would say we're not versioning
the implementation. That's supposed to be able to change.
What I believe we are versioning is the CONTRACT. I capitalized the
word because I believe it's too oft forgotten in this SOA realm by those
that take too technical a tact to its existence. Underlying every service
is a service contract. It's what tell X how to talk to Y and what Y can
expect from X. Over time I expect contracts to become much more complex
entities (let me restate these HAD BETTER become more complex entities if
this thing is going to work long term), thus it is the contract that we are
adhering to that must be versioned.
This will have legal implications when the service contract and the
legal binding are intersected as they will most likely become in
Service-Level Agreements. Hence "we agreed to 3% error rate in version 1 of
our serviced, but updated that to 2% in our version 2" has serious
implications when $3million is lost in a financial deal based on version 1
of the service because they assumed 2% error based on using the wrong
version.
Robin, my only area of confusion now is ... where was I supposed to
respond to you, here or on your blog! :-)
JP
-----Original Message-----
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of
robinmulkers
Sent: Tuesday, November 08, 2005 5:31 AM
To: [email protected]
Subject: [service-orientated-architecture] Re: Basic SOA principles
Hi all,
I like the current path that this group is following about SOA and I
would like to comment one of the principles laid out by JP
Morgenthal that is related to versioning. He says that a SOA should
be "Versioned - multiple versions of the same service should be able
to co-exist to maintain backward compatibility in a changing
environment".
Well, I think there are some fundamental questions to be answered
related to versioning and change management in a SOA.
- Are all services immutable?
- What do we want to version, the service interface or the service
implementation?
- What does software version numbers really mean?
First of all, are we talking about immutable service interfaces here?
Does it mean to us that once a service interface is defined, it
never changes, only the implementation or the location of the
service can change?
Will a new version of an existing service always result in a new
service?
Does some key identifier of the service includes the version number?
Well, if your answer to the 3 questions above is yes, this approach
works in practice, it is well possible to have several versions of a
single service running at the same time.
But this approach is also extremely expensive, it might result in
service consumers using different views of the same service
(different stubs or proxys) and might result in maintaining
different service implementations on the server side. Not really an
ideal world of reuse where several deprecated versions of a single
service must be kept alive because of an installed base of consumers
using it!
Of course, there are more dynamic techniques allowing a client to be
much more independent of a particular service version. But how do we
know if a service consumer is using these techniques or not?
There are also implementation strategies on the server side allowing
different service versions invocations to be transformed and routed
to a single service implementation. But do we really want to manage
this overhead of transformation and routing?
I have faced this problem myself and I want to share my experience
here. I think that if we do not make a difference between changes
that are backward compatible and changes that are not, we cannot
have an efficient change management in a SOA or in composite
applications in general.
I have a range of blogs about this problem here:
http://blogs.ittoolbox.com/eai/applications/
What is your own experience with change management in SOA?
What are the best practices?
Thanks for your feed-back.
Robin
--- In [email protected], "JP
Morgenthal" <[EMAIL PROTECTED]> wrote:
>
>
> Here's what I propose:
>
> A) Loose-coupling - every service is atomic, self-describing,
> accessible, declarative, stateless and composite
> B) Contracted - All services in an SOA are represented by a
contract
> that describes its inputs, outputs, access policies, QoS
requirements and
> error handling procedures
> C) Manageable - all services can be individually managed or
managed
> as a group
> D) Versioned - multiple versions of the same service should
be able
> to co-exist to maintain backward compatibility in a changing
environment
> E) Discoverable - services should be able to be discoverable
at time
> of execution.
> F) Addressable - A service should be able to be uniquely
identified
> in a network
> G) Distributed - Services in an SOA are separated by
geographic and
> machine boundaries and, therefore, must be good netizen
applications. That
> is, they must be developed with the ability to recover from loss of
> communications.
> H) Point-to-Point - At any point in time one consumer uses
one and
> only one producer
>
> ------------------------------------
> Avorcor, Inc.
> JP Morgenthal
Yahoo! Groups Links
------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/NhFolB/TM
--------------------------------------------------------------------~->
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/
