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):
|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.