Blog post

Libraries vs. Services

By Eric Knipp | March 20, 2013 | 2 Comments


While attending the Gartner BI Summit in Grapevine, TX yesterday I had a meeting with a client that made me facepalm a little.

The client in question was telling me about his need to educate his development staff in a number of critical areas, ranging from application lifecycle management, to data access patterns, to SOA governance, and on. The organization he works for is in the middle of a major hiring binge, and within the 200+ IT group there are few technologists with more than a year’s experience inside the company. This is a challenging situation, even when you can assume (as you should be able to) that most of your programmers know the difference between a library and a service! Many of the programmers in this organization prefer to create code libraries rather than services, and most of them don’t understand why they should build a service instead of a library. So, let’s get into that here.

In a nutshell: a library is shared code that you compile into your application. A service is a shared capability that you access from your application:

I am a (mostly) strong proponent of relying on services whenever possible, instead of building custom code libraries for inclusion in many programs. The agility, reuse, and transparency benefits of a service are just too hard to ignore. Having said that, I recognize that there are specific cases where creating libraries could be more appropriate:

  • When you’re building an application that will be deployed to a device with inconsistent network access (making remote service consumption unreliable)
  • When you’re building an application that will be hardened with wrapper technology for security reasons (and network access to remote services is seen as an unacceptable compromise)

A few more details that I quickly came up with which you might find worthwhile (let me know if you have any to add here):

Library Service
Characteristics Executes locally inside of your program Executes remotely outside of your program
Distributed/deployed with your program Exists independently of your program
Internal compilation dependency for your program External consumption dependency for your program
Cannot change unless you recompile/redeploy your program Versioned independently of your program
Instance used in your program is used only by your program Can be shared with many remote programs
Access to library routines cannot be mediated Access can be mediated for security, QoS, or other reasons
Access to library routines cannot be audited Access can be logged and audited by a mediator
Strengths Program cannot be inadvertently broken by a dependency change Many programs can benefit from service reuse and improvement
Programmers can easily understand all project dependencies Service mediation can provide many benefits
Compiled program is entirely self-contained Service-based design is more flexible to unanticipated changes
Weaknesses Library improvements can only be used at program recompilation Service oversubscription creates an availability bottleneck
Multiple versions of the same library can be used in many programs Service mediation is a black art to most programmers
Patterns of library consumption are not clearly visible at runtime Services may not be modeled with the right level of granularity for reuse

A final word.

Ever thought about being an analyst? You’re in luck! I am hiring two analysts in the UK (preferably the Greater London area) to join the Application Platform Strategy (APS) team. If you think you’d like to cover application design, development, and delivery for fun and profit, have a look at this link.

Comments are closed


  • MDILLENB says:

    – white box from outside the application (other app knows the code behind)
    – no contract (just docu)
    – API with code (java, php, javascript, C#, etc)

    – black box from outside the application (other app doesnt know the code behind)
    – contractbased (WSDL, WADL, etc)
    – API with application protokol, dataformat (JMS, HTTP, XML, JSON, etc)

  • Eric Knipp says:

    @MDILLENB: Thanks for the comment. You’re quite right with the above and I will add to my list. Thanks!