23

Let's say you're looking at breaking up your applications into services. Are there any good reasons to adopt a SOA approach vs. just creating a library API that can be loaded by the applications that need it.

Nate Reed
  • 341
  • 1
  • 2
  • 6
  • 6
    Hey Nate, read [Stevey's Google Platforms Rant](https://plus.google.com/112678702228711889851/posts/eVeouesvaVX), it provides great insights on the platform (services) vs product (library) question... – yannis Oct 22 '11 at 17:13

6 Answers6

12

The difference may be subtle between both. For example in .NET world, you may have an application which would feel like monolithic to an end user and which will work on a same machine, but inside, would be separated into a bunch of WCF services. You may also have architectures where libraries are not strongly linked (addins/plugins) and are just following a protocol when talking to each other.

If we avoid talking about those intermediary cases, and deal only with strongly linked API library vs. a separate REST service, then you may want to consider following points:

  1. A library API is called on the same machine. Services can be hosted anywhere and be called from anywhere. If you're counting hosting the application on multiple machines for performance/scalability/security reasons, chances are you'll need to use services.

  2. The situation is similar when it goes to using one service by an application deployed on several machines. For example if you're doing an application for a bank doing some financial computations, one way is to deploy the whole large application to every desktop, and be forced to do large-size updates to every client every time; another approach would be to host computation part on servers, and deploy to the desktops only a lightweight app with just a UI and a bunch of calls to those servers.

  3. If you're hosting a REST service, anyone can use it: a Mac user, a person who uses Linux, etc. If you've created a C# library with Visual Studio and you distribute it as a DLL, forget about users (customers?) who don't have Windows.

Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513
12

Another advantage of services is that when you update the service, it is immediately deployed to all consumers of the service. So if you fixed a bug, or performance issue, everyone gets the benefit as soon as the updated service goes live, instead of having to distribute an update that people may choose to ignore.

Mike O'Connor
  • 441
  • 3
  • 6
  • 1
    True, but this can also be a disadvantage. When you make a change in a service that multiple applications depend on, you can unexpectedly break functionality in one or many of those applications. This is not to scare anyone away from services, just be aware that you need to ensure all consumers of the service still work whenever you change a service. Even better is to leave the legacy service methods alone once they have been deployed and create new methods when you need to change the implementation. – Lews Therin Aug 29 '18 at 14:52
9

Library Advantages:

Service Advantages:

  • Everyone gets upgrades immediately and transparently (unless versioned API offerred)
  • Consumers cannot decompile the code
  • Can scale service hardware separately
  • Technology agnostic. With a shared library, consumers must utilize a compatible technology.
  • More secure. The UI tier can call the service which sits behind a firewall instead of directly accessing the DB.
sleske
  • 10,095
  • 3
  • 29
  • 44
Cory House
  • 233
  • 2
  • 6
  • "native code" does not really make sense here: a) a service can use "native code" too, and b) just-in-time compilation often provides the same performance as native code. – sleske Oct 21 '14 at 07:44
  • Point taken. What I'm referring to when I say "Native code" is that a library is an "in process" call. There's no service layer overhead (e.g. HTTP if making a Web API call) – Cory House Oct 21 '14 at 16:37
  • Yes, the call overhead should indeed be lower. I took the liberty of editing your answer, to replace the mention of "native code" with "lower call overhead". Feel free to re-edit if you disagree :-). – sleske Oct 22 '14 at 07:28
  • What i like to add is the usage of **transactions**. It's typically a lot harder to make transactional work across service boundaries, than it is in a shared library. – c_mart Apr 07 '16 at 07:21
2

A SOA approach allows the various services to be hosted and maintained separately. In addition to code, deploying a particular service may require a lot of special configuration (passwords, ports, certificates, etc). Consuming a REST service has a finite amount of complexity that can be clearly documented and easily understood. It's also more secure because it means you don't need to grant access to DBs or other resources to clients.

jiggy
  • 1,590
  • 11
  • 15
1

If there is a change to an SOA service, then that SOA service will have to be redeveloped, retested and redeployed. All applications that consume that service can continue to do so. A change to a library in a DLL will mean all consumers of that library will have to be redeveloped to reference that DLL, they will all have to be retested and they will all have to be redeployed. There is also the danger this may not happen properly, and different applications will have different versions of the DLL. Sometimes this might not be a problem - perhaps every system should have the version of the library that was present at deployment time (you may have updated your logging system to have helpful new features - do you really need to update every system with it?) in this case a library is fine. But say you have a service for calculating tax rate, and the tax laws change. You don't want to have to update every system to incorporate this change, it would be better to do it in one place. In this case a service is a better option.

Paul T Davies
  • 3,144
  • 2
  • 22
  • 22
0

There are several good answers but I would like to add more things to the given answers:

The API library method is very useful when you want to interact with things with as little overhead as possible. The consequence is that there is a higher coupling between API and the applications using it. Sometimes, this is okay for application and even necessary, however if you have a very distributed system or you think interoperability is a huge issue, you might need to go one step up the abstraction latter and use other ways of communicating. Especially, if you want to have a distributed system, SOAP is kind of the next step in SOA, but you will still be left with the dependence between the units, since they have to know each others procedures. REST takes it to a new level, by allowing a machine to learn something about the content on the other services in a unified way.

In your case, if your application is not distributed I don't see any reason to transform you application into SOA.

aagaard
  • 101
  • 2