SOA: Libraries vs Services: Can a library be a better option?

I work with WCF 4.0 and have a good idea of how to build services from a technical standpoint. I have been working now with WCF for 3 years now.

Despite this I and others I talk to have different ideas about what should be the unit of software that makes up a service and what should not. Many people I talk to believe that services should be granular. Indeed my previous company has spent alot of time turning some of their Assemblys into Services (so I have been told).

In many instances I can't see how a service 开发者_如何学Cis better...and maybe it's not always supposed to be. I'll give you an example: In our system we have a large service that really has grown to perform two different independant jobs. I am going to split it into two services for two reasons: performance and fault isolation (we self host in a Windows Service, no IIS). The thing is, despite serving two independant business processes (one service can be down without affecting the other), both have a fair chunk of common business logic.

Now some advise me that this common logic should be seperated into a 3rd service under SOA principals and be consumed by the two newly split services. As I see it, this just partially undoes the benefit of spliting the big service in the first place: we have introduced a performance bottleneck and single point of failure. If the host process of the 3rd service goes down, 1 and 2 can no longer do their work. This happens to us now where we have a "deep" structure of many services. One goes out and any dependant services up the chain timeout as their calls are never answered.

Now if the common logic was just a library rather than a service we get the benefit of code reuse, no performance bottleneck and fault isolation as each service is executing its own copy of the assembly in its own memory. Also there is no serialisation overhead.

What are peoples thoughts on this? Is there a rule or general guideline when it comes to deciding when something should be a service or a library? Any other advice?

Thanks Michael

---

This is a fair argument against using services, but the correct approach is probably to use a service bus.

You can then run multiple services to fulfil your 'core' functionality. You get redundancy and reliability (you could even route your process 1 and 2 to separate instances if you needed to, but prefer to load balance), but you gain the loose-coupling and maintainability of separate services.

I believe SOA is a great principle but takes very careful architecture, and is very easy to get wrong. And if you do get it wrong then the consequences can be dire.

---

There are probably two key considerations for me in weighing up whether a library or service might be the better approach for a given problem.

First the potential consumers: if they are going to be entirely within your control and it is workable for them to be hosted in-process then a library would be a legitimate approach. If there is no possibility of external consumption then this is probably the better choice because the design, development and testing effort will probably be substantially less than the equivalent service.

Second is the 'granluarity' of the API. Services need to be architected to reduce 'chattiness' - a good service tends to have powerful operations whose behaviour adapts based on message content. E.g. Addorder(msg) vs CreateHeader(h), GetCustomer(c), AddOrderCustomer(h,c), AddOrderLine(p,1), etc. The former is what I would expect of a service operation, whereas the latter would be more typical of a library. If the problem doesn't lend itself to that style of API, or you can't invest the necessary effort to get that design right, then a library would be more appropriate.