Services as an Explicit Abstraction

Viewing enterprise applications as having three logical parts—data, logic, and presentation—has been the standard approach for many years. Each part has a dominant abstraction that most of today’s applications use: relations for data, objects for logic, and graphical user interfaces for presentation. This tripartite breakdown proved to be exactly right for the web era, and it’s been very successful.


But it’s not the right way to think about the service-oriented world that we’re moving to. Service-oriented applications certainly have data and logic, but they also include an explicit logical element—let’s call it access—that uses services as the dominant abstraction. These services let various clients, such as user interfaces or other applications, make use of this application’s logic. The figure below shows how this looks.

To understand why a service-oriented world implies an explicit role for access, think about why these different parts of an application exist at all. Arguably the biggest reason is that each uses a different abstraction, and so crossing from one to another requires mapping between these abstractions. For example, moving between data and logic typically requires translating from relations to objects. This translation—restructuring data from tables into objects and mapping from SQL types to programming language types—is a well-understood, if still painful, problem.

Back in the 90s, as the idea of objects swept the industry, plenty of companies made a valiant attempt to use objects for storing data. The primary result of these efforts was a great deal of lost venture capital money. Relations proved to be a better abstraction for working with data in the great majority of cases, and so object databases didn’t achieve substantial market share.

Similarly, there were also attempts to use objects to hide the reality of access. One of the best examples of this was Microsoft’s Component Object Model (COM) and Distributed COM (DCOM). The laudable goal of its creators was to make access to an object on another machine look just like accessing a local object. And to a large degree, this goal was met. With DCOM, the very same code could in fact be used whether the COM object and its client were on the same machine or on different machines. But the truth was that remote access was still different: performance was different, reliability was different, and security was different. Accessing software across machine boundaries just isn’t the same as accessing software on the same system. Even if the code looks identical, as with COM and DCOM, this reality is inescapable.

The service-oriented approach, typically implemented today using web services, makes this difference explicit. Rather than trying to hide the reality of access, services provide an abstraction designed for this purpose. Accessing logic requires mapping into and out of this abstraction, as shown in the figure below. This mapping is analogous to mapping between relations and objects, although (thankfully) it’s much simpler. Here, the mapping is between objects and the interfaces and messages used by services. Translation between type systems is also required, as with the object/relational mapping. Objects use types defined by whatever programming language the logic is written in, such as Java or Common Language Runtime (CLR)-based languages such as C#, while services most commonly send messages using XML types. The consumer of the service, such as the logic of another application or a portal providing a user interface, must then map from the abstractions of the service into its own abstractions, whatever they are.

How the mapping between objects and services gets done varies. In Microsoft’s forthcoming Indigo technology, for example, this translation is done by software that’s part of the .NET Framework itself, so no explicit software tier is required. But however it’s done, trying to hide the realities of access under the comforting blanket of objects doesn’t appear to be the best solution. It’s more accurate to view services as the abstraction that provides access, then explicitly map into and out of these services. Thinking of the translations as happening between distinct logical parts of the application provides a clear model of what’s really going on.

• Services as an Explicit Abstraction
   

David Chappell is Principal of Chappell & Associates (www.davidchappell.com) in San Francisco, California. Through his speaking, writing, and consulting, David helps information technology professionals around the world understand, use, market, and make better decisions about enterprise software technologies. David has given keynotes at conferences and in-house events in the U.S., Europe, Latin America, and the Middle East, and his seminars have been attended by tens of thousands of developers and decision makers in thirty-five countries. David's books have been translated into ten languages and used in courses at MIT, ETH Zurich, and other universities. His consulting clients have included HP, IBM, Microsoft, Stanford University, and other technology vendors and users.

© Copyright 2005 David Chappell and Associates
All rights Reserved.