SOA principles, encapsulation and autonomy

Question

We are developing multiple web services in C# using WCF, but we´re new doing it.

So, for what we have read and learnt, this is our approach:

• We have a class library that we called CommonLibrary that has a few classes that are going to be used on all our services (language stuff, type of user connected and a common object that all the services are meant to return).
• We have another class library called SecurityLibrary which validates the user that is consuming the method.
• At the moment we have 2 services that are almost at 90% finished, both of them use CommonLibrary and SecurityLibrary.

Now the questions:

• Is this a bad approach?
• Are we violating the SOA principles of encapsulation and autonomy by using common/shared library with each of our services?
• A third person told us to copy all the code of those libraries on each of our services so we have a 100% autonomous service, is this the right way? I think is hard for maintenance and shows a lot of duplicity. Any update made on one has to be replicated or merged on those other services...

Thanks for your time helping us to clarify this.

Answer 1

My company use this approach (we are a Java/Maven/Jenkins shop). We use a webclient-common library in 4 or so web clients, and a webserver-common library in 3 web server projects. Just what advantage a "cut and paste" approach would add to this is a mystery to me.

As with using any common code, good release management and version tagging practices are essential. When we upgrade the common libraries, the multiple projects using them don't see the upgraded version until they are recompiled with their dependencies updated to pick up the latest version. Maven handles this brilliantly, and I expect C# has a similar tool.

So in my humble opinion, you are doing it dead right.