Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Received: by 10.100.5.16 with SMTP id 16mr2252144ane.4.1247569209746; Tue, 14 
	Jul 2009 04:00:09 -0700 (PDT)
Date: Tue, 14 Jul 2009 04:00:09 -0700 (PDT)
In-Reply-To: <a9c375790907140207r7d3d831are3e08f1260f6d1ec@mail.gmail.com>
X-IP: 217.33.200.151
References: <fbb7907b-60b2-44d6-8013-7d394dc7a852@p15g2000vbl.googlegroups.com> 
	<a880efe10907120923t3ca69ac8hde40c137bc530e86@mail.gmail.com> 
	<a9c375790907120942g7e5d22d7wce333a1472467589@mail.gmail.com> 
	<a880efe10907120951o8782ce2i40172a3c202b8a6f@mail.gmail.com> 
	<a9c375790907121226n20d42615v365bc71667c90666@mail.gmail.com> 
	<4aa3d831-6c00-49fa-ba7b-0f7ef988381c@d4g2000vbm.googlegroups.com> 
	<a9c375790907140207r7d3d831are3e08f1260f6d1ec@mail.gmail.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1) 
	Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729),gzip(gfe),gzip(gfe)
Message-ID: <b8d9e488-bdff-4a45-b715-cb1197be5f90@p36g2000vbn.googlegroups.com>
Subject: Re: E-VAN with Ian Robinson and Jim Webber
From: Richard Evans <richyev...@googlemail.com>
To: "Virtual ALT.NET" <virtualaltnet@googlegroups.com>

We have a desire to build in versioning into our SOA. Reasons for this
are to minimise risk and manage change carefully.  The SOA deals with
high value transactions.

Given that for a versioned service you would at the very least version
the interface/contract, what is your opinion on versioning at the
implementation level?

Implementation level

If something goes wrong in a given system, one of the first places to
fault find is to look at what has changed. If you can say a given
version of a service has had no change interface and implementation
wise, the fault is less likely to have occured within the service. The
drawback to this approach is that the version of the service can
stagnate, and become difficult to migrate to the latest code. The
benefit is that clients of the service have high confidence in the
system because they know nothing is changing.

Contract Level

Another school of thought is that given a sufficiently full regression
test pack we should be less concerned with the implementation and more
about the contracts/interfaces/behaviour. Thus with the introduction
of each new version we can move older versions of services onto the
latest code. This keeps our code up to date and the test pack
maintains our confidence in the behaviour of the system. Given enough
successful iterations the approach becomes part of everday life.
Obviously if the test pack is insufficient, a change could break a
client. At this point you could argue the consumer contract is not
sufficient and it is the responsibility of the client. The client
could argue, why did you change it when it was working okay?

My opinion is that both options have something to offer, I'd be
interested to know your opinion on the matter.