SOA: libraries and services: could a library be a better option?

Question

I work with WCF 4.0 and have a good understanding of how to create services from a technical point of view. I have been working with WCF for 3 years now.

Despite this, I and others, I have different ideas about what should be the unit of software that makes up the service and what does not. Many people with whom I speak believe that services should be details. Indeed, my previous company spent a lot of time turning some of its Meetings into Services (as I was told).

In many cases, I don’t see how the service is better ... and maybe it doesn’t always have to be. I will give you an example: in our system we have a great service that has really grown to fulfill two different independent tasks. I am going to split it into two services for two reasons: performance and isolation from failure (we are hosted on a Windows service without IIS). The fact is that, despite servicing two independent business processes (one service may not be available without affecting the other), both have a fair chunk of common business logic.

Now they tell me that this common logic should be divided into a third service under the direction of SOA and consumed by two new services. As I see it, this only partially cancels out the benefit of sharing a large service in the first place: we have introduced a performance bottleneck and a single point of failure. If the host process of the third service is reduced, 1 and 2 can no longer do their work. This is happening to us now that we have a “deep” structure of many services. One of them exits, and any dependent services drag out the network timeout, since their calls never answer.

Now, if common logic was just a library, not a service, we get the benefit of code reuse, no bottlenecks, and isolation as each service executes its own copy of the assembly in its own memory. There is also no overhead for serialization.

What do people think about this? Is there a rule, or a general rule, when you need to decide when something should be a service or library? Any other tips?

Thanks michael

Answer 1

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

You can then run several services to perform your “core” functionality. You get redundancy and reliability (you could even route your process 1 and 2 to separate instances if you need, but prefer load balancing), but you get free communication and support for individual services.

I believe SOA is a great principle, but it requires a very thorough architecture and it is very easy to make a mistake. And if you make a mistake, the consequences can be terrible.

Answer 2

Probably two key factors are important to me: whether to weigh the library or service is the best approach for this problem.

Firstly, potential consumers: if they are completely under your control, and it will be appropriate for them to be placed in the process, then the library will be a legitimate approach. If there is no possibility of external consumption, then this is probably the best choice, since the costs of design, development and testing are likely to be significantly less than the equivalent service.

Secondly, this is the "granularity" of the API. Services should be designed to reduce chattiness — a good service tends to have powerful operations whose behavior is adapted based on message content. For instance. Addorder (msg) vs CreateHeader (h), GetCustomer (c), AddOrderCustomer (h, c), AddOrderLine (p, 1), etc. The first is what I would expect from a service operation, while the latter would be more typical of a library. If the problem is not amenable to this style of the API, or you cannot invest the necessary effort to properly create this project, then the library will be more suitable.