Services in a Service Oriented Architecture

This post is the second in a series about the application of the Service Oriented Architecture (SOA) system design pattern to library services. The first post in this series focused on defining "Service Oriented Architecture" using the analogy of a transportation network. This post goes into some detail about what makes a "service" in this architecture and offers an example using a hypothetical use case: a union library catalog (Open WorldCat) making a statement about the availability of a book.

Why are we even looking at SOA?

This is a good question to ask before we get much further. SOA adds a new layer of complexity on top of existing systems and services, so — other than being a neat new set of buzzwords — there had better be a good reason for investigating and adopting pattern for designing systems. Answering this question also helps us in defining what a "service" is in an SOA. The most concise answer can be found in OASIS Reference Model for Service-Oriented Architecture:

SOA is a means of organizing solutions that promotes reuse, growth and interoperability. It is not itself a solution to domain problems but rather an organizing and delivery paradigm that enables one to get more value from use both of capabilities which are locally “owned” and those under the control of others. It also enables one to express solutions in a way that makes it easier to modify or evolve the identified solution or to try alternate solutions. OASIS Reference Model for Service-Oriented Architecture, Committee Specification 1, dated 2 Aug 2006, lines 175-179. The document was retrieved from http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf on 18-Sep-2006.

The first sentence is a statement that reflects SOA position as the latest step on an evolutionary path from monolithic to modular computing. In the really old days of electronic computing, every sequence of processing instructions was defined from scratch — you programmed the computer to do everything. Very quickly one realized that the programming code being written contained a lot of redundancy, so "code libraries" were formed that held all of the repeated instructions; no longer did everyone have to write and debug their own code routines to get the current date or write out a character...you used the supplied code libraries.

Gradually, as systems became more and more complex, the computing profession came up with more code libraries and developed higher levels of abstraction to deal with the complexity. "Objects" as programming entities were introduced in the 1960s via Simula 67, a programming language designed for making simulations, and Smalltalk, a programming language developed at Xerox PARC in the 1970s, introduced the term Object-oriented Programming (OOP) to represent the pervasive use of objects and messages as the basis for computation. OOP became the dominant programming methodology during the mid-1980s largely due to the influence of C++, an extension of the C programming language, but for the most part the applications developed using the OOP methodology remained as applications running on a solitary computer system. Summarized version of "Object-oriented programming." Wikipedia, The Free Encyclopedia. 19 Sep 2006, 18:27 UTC. Wikimedia Foundation, Inc. 19 Sep 2006 http://en.wikipedia.org/wiki/Object-oriented_programming&oldid=76627897#History.

OOP and SOA are similar in that each seeks to encapsulate activities to an abstract level at which point the abstractions can be reused as building blocks to larger applications. Where they differ, as explained by the OASIS Reference Model for Service-Oriented Architecture OASIS Reference Model for Service-Oriented Architecture, Committee Specification 1, dated 2 Aug 2006, lines 243-259., is at the level of abstraction: in the OOP paradigm the focus is on packaging data and operations whereas in the SOA paradigm the focus is on "the task or business function &mdash getting something done." Or, if you will, providing a service.

Definition of "Service"

In the SOA sense of the word, a service is a set of capabilities offered by a service provider through a service definition that makes the capabilities discoverable by a service consumer. The implementation of the service is "opaque" to the consumer, and the invocation of a service itself may seek out the SOA-defined capabilities of another service provider. The real-world consequences of a service invocation can be: 1) information transferred from a provider to a consumer (e.g. "read"); 2) a change in the state of information at the provider (e.g. "write"); or 3) a combination of both.

The amount of information received and/or changed per service invocation can be rather small, and the transaction itself can be rather light-weight. For instance, in an ACM QUEUE interview Werner Vogels, Amazon's Chief Technical Officer says that when "you hit the Amazon.com gateway page, the application calls more than 100 services to collect data and construct the page for you." "A Conversation with Werner Vogels." ACM Queue. 4(4): May 2006. 19-Sep-2006 http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=388 If it took seconds rather than miliseconds to respond to a SOA query, Amazon's architecture would clearly be unsustainable.

Back up to the quotation near the top of this post, the second sentence ends by speaking of "capabilities which are locally 'owned' and those under the control of others." SOA, by defining this abstract notion of service and focusing on the semantics surrounding a service, promotes the exchange of services across organizational boundaries. This is the subject of the following hypothetical use case.

Hypothetical Use Case: Reflection of Local Library Holdings in Open WorldCat

So, you might be asking yourself, what does this mean for the systems and services delivered by the library community? (The first post in the series generated a lot of hits that, judging by the quantity and the HTTP referrer strings, are not from the the library community so you might be asking "who cares about libraries?" Welcome to DLTJ — a blog about the application of technology changes that are disruptive to the library community status quo...and you may have thought that libraries are boring...) Suppose for a moment that you decided to replace the public interface of your local library catalog with that of, say, Open WorldCat — you like the design and functionality better than what is offered by your library automation vendor plus Open WorldCat offers the very neat find-a-copy-in-a-nearby-library feature. (Again, for those coming in from outside the library community, WorldCat is a combined database of the holdings of thousands of libraries worldwide offered by a not-for-profit cooperative called OCLC. You can, no pun intended, read more about it. A database of, at the time of writing 68,338,776 works represented by 1,081,317,008 distinct holdings in libraries. Still think libraries are boring?)

You are all ready to proceed with this plan, For the record, please note the word "hypothetical" sprinkled liberally throughout this example. WorldCat cannot now do the things that are described in this post, the screenshots are unauthorized adaptations of WorldCat web pages, and, to the best of my knowledge, OCLC is not planning on doing anything like what is described here. Although it would be really neat if they could do it.... but there is one sticking point: your local public catalog displays the status of the item ("available", "checked out", "lost", etc.). And WorldCat, although it contains the combined holdings of thousands of libraries, it doesn't know whether any particular item is available or not — the only thing stored in the WorldCat database is whether an item is owned, not whether it is checked out. The status of the item is only known to the local catalog system.

Enter a Service Oriented Architecture. The local catalog system makes known a service whereby an service consumer can ask for the status of an item. What is returned by the service provider can be as simple as a string of text that is a spelled-out version of the item status or it can be as complex as an XML schema with attributes for "checked out" or "lost" and parsable date fields and so forth. Remember, though — these SOA exchanges need to be processed quickly. As WorldCat is generating the screen of the search results for the user, it calls back to the library catalog system to find the status of the item and then displays it for the user. The result might be something like this:

Okay, but is That What the User Really Wanted?

I have my wife to thank for the next part; she, too, is a librarian yeah, yeah -- I can almost hear the sharp-witted speculations about our dinner-time conversations from those outside the library community. and as I was describing this scenario she was most emphatic about the relative uselessness of the status display. After all, if your question is "how can I get this item?" does the answer "due back on..." or "declared lost" or even "available" answer that question? What if we were to really answer the question; the answer might look something like:

We're translating the raw status information from our inventory control database following these rules:

Available Online

If we see in the description of the item that it is on the web somewhere. In this case, the word "Online" can link right to the item.

Available Onsite; Delivered in 1-2 days

This item is physically held in the library and the inventory control aspect of the library system says that it is available. So the choices to the user are "onsite", which could link to a page that describes which library holds the item and the approximate location of the item within the library, or "delivered in 1-2 days" for a user service that will pull an item from the shelves and deliver it to an office or home.

Delivery on or about...

This item is checked out. A hold has been placed on it, and when the item is returned (hopefully no later than the original due date) it will be turned around to the next user.

Delivered in 3-4 weeks

This item was declared lost, so the 3-4 week delivery statement represents the estimated time to get the item from another library through interlibrary loan. Ultimately, does the user really care if the item was declared lost? Probably not — they just want to get to the item!

Layers of Services

Here in Ohio we can actually do one better than those last two. In addition to our local catalog systems, Ohio academic libraries have a combined catalog of their own and a requesting/delivery service that can move an item from one institution to another in a matter of days. What would this mean in terms of our emerging SOA? The service provider that WorldCat asks for the local item status doesn't have to be the local catalog system. Instead, it could be an intermediary service that would first ask the local catalog system if the item is available. If not (such as in the "checked out" or "lost" examples), the intermediary service would query the OhioLINK combined catalog service provider to see if the item is available at any other OhioLINK member institution. If so, the display might look something like this:

Here again is the translated message:

Delivered in 2-3 days

The item was not available at the local site (so we don't see an "on-site" link) but it is available from an OhioLINK member institution. The average turn-around time for an OhioLINK physical delivery request is about 2 to 3 days. But again, the user doesn't care at this point where the item is coming from — their local library or one somewhere across the state; the only thing the user likely cares about is how long it would take to get the item if he or she asked for it to be delivered to their home or office.

But What of the "Integrated Library System"?

If you read closely and have your internal sensors calibrated to such things, you may have noticed the juxtaposition of "inventory control system" with "local catalog system" in the descriptions above. That is no mistake — in the next posting of this series we'll take a look at the disaggregation of the traditional integrated library system in a SOA environment.

The text was modified to update a link from http://en.wikipedia.org/wiki/Object-oriented_programming&oldid=76627897#History to http://en.wikipedia.org/wiki/Object-oriented_programming?oldid=76627897#History on January 13th, 2011.