Web Service vs. Shared Library

Question

This question has been asked a few times on SO from what I found:

When should a web service not be used? Web Service or DLL?

The answers helped but they were both a little pointed to a particular scenario. I wanted to get a more general thought on this.

When should a Web Service be considered over a Shared Library (DLL) and vice versa?

Answer 1

Library Advantages:

• Native code = higher performance
• Simplest thing that could possibly work
• No risk of centralized service going down and impacting all consumers

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.

Answer 2

My thought on this:

A Web Service was designed for machine interop and to reach an audience easily by using HTTP as the means of transport.

A strong point is that by publishing the service you are also opening the use of the service to an audience that is potentially vast (over the web or at least throughout the entire company) and/or largely outside of your control / influence / communication channel and you don't mind or this is desired. The usage of the service is much easier as clients simply have to have an internet connection and consume the service. Unlike a library which may not be so easily done (but can be done). The usage of the service is largely open. You are making it available to whomever feels they could use it and however they feel to use it.

However, a web service is in general slower and is dependent on an internet connection.
It's in general harder to test than a code library.
It may be harder to maintain. Much of that depends on your maintainance and coding practices.

I would consider a web service if several of the above features are desired or at least one of them is considered paramount and the downsides were acceptable or a necessary evil.

What about a Shared Library?

What if you are far more in "control" of your environment or want to be? You know who will be using the code (interface isn't a problem to maintain), you don't have to worry about interop. You are in a situation where you can easily achieve sharing without a lot of work / hoops to jump through.

Examples in my mind of when to use:

You have many applications in your control all hosted on the same server or two that will use the library.

Not so good example, you have many applications but all hosted on a dozen or so servers. Web Service may be a better choice.

You are not sure who or how your code could be used but know it is of good value to many. Web Service.

You are writing something only used by a limited set of applications, perhaps some helper functions. Library.

You are writing something highly specialized and is not suited for consumption by many. Such as an API for your Line of Business Application that no one else will ever use. Library.

If all things being equal, it would be easier to start with a shared library and turn it into a web service but not so much vice versa.

There are many more but these are some of my thoughts on it...

Answer 3

Based on multiple sources...

Common Shared Library

1. Should provide a set of well-known operations that perform common tasks (e.g., String parsing, numerical manipulations, builders)
2. Should Encapsulate common reusable code
3. Have minimal dependencies on other libraries
4. Provide stable interfaces

Services

1. Should provide reusable application-components
2. Provide common business services (e.g., rate-of-return calculations, performance reports, or transaction history services)
3. May be used to connect existing software from disparate systems or exchange data between applications

Answer 4

Here are 5 options and reasons to use them.

1. Service

   • has peristent state
   • you need to release updates often
   • solves major business problem and owns data related to it
   • need security: user can't see your code, user can't access you storage
   • need agnostic intereface like REST (you can auto generate shallow REST clients for client languages esily)
   • need to scale separately

2. Library

   • you simply need a collection of resusaable code
   • needs to run on client side
   • can't tolerate any downtime
   • can't tolerate even few milliseconds of latency
   • simplest solution that couldd possibly work
   • need to ship code to data (high thoughput or map-reduce)

3. First provide library. Then service if need arises.

   • agile approach, you start with simplest solution than expand
   • needs might evolve and become more like "Service" cases

4. Library that starts local service.

   • many apps on the host need to connect to it and send some data to it

5. Neither

   • you can't seriously justify even the library case
   • business value is questionable

Answer 5

Ideally if I want both advantages, I'll need a portable library, with the agnostic interface glue, automatically updated, with obfuscated (hard to decompile) or secure in-house environment.

Possible using both webservice and library to turn it viable.