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