Simon is a hands-on software architect who works within 
[Twitter] simonbrown: wondering whether Adobe's commercial approach to Flex Builder will limit adoption of Flex ... which will be a shame, because I quite like it
[Coding the Architecture] As mentioned before, we were speakers at, and community sponsors of the Software Architect 2008 conference (3rd-5th June 2008, London). This is the first dedicated software architecture conference that I've been to and the majority of the ...
SOA : Code reuse
Somebody I once spoke to about SOA mentioned that in an SOA, a service should ideally be developed in isolation and not share code with other services. I think that the important point here is the substitutability of a service, although there are other factors that come into play, including loose coupling and whether or not a service has an implementation independent interface.
The code reuse point is interesting though. Of course, code reuse is a good thing and you'd need to put careful consideration into not reusing code. While there are circumstances where this may be the case (e.g. you want two separate implementations running in parallel to ensure correctness and consistency of your business process), typically you're going to reuse code.
Assuming that you do reuse code in your service, there are two ways to deploy it. Imagine that you're building an SOA with J2EE, deploying a group of services as an EAR file. Although each of your services will be defined separately (e.g. as web services or MDBs), typically you'd include just a single copy of the shared code. If you need to update the shared code, this will affect all services. Contrast this approach with deploying each service as a separate EAR file. Now, although you've reused code, each service has its own version at runtime, meaning you can upgrade individual services as necessary.
There are clearly development and maintenance implications of taking the latter approach, but it does provide a certain level of separation between services in the architecture. My feeling is that this is irrelevant as to whether something is a "service" or not, but it might be something to bear in mind when defining an SOA. Any thoughts?
Staying with the same topic but on a slightly different note, here's an interesting article (SOA breaking down reusable-code barriers) highlighting the fact that SOA is about shared reusable services and how we're trying to get to the "holy grail" of reusable code. Not sure I agree with the bit about reuse by subclassing though, particularly since it doesn't mention the many other techniques that are available!
