Services are the building blocks of SOA, and like building blocks of a house or a building, the quality will define the value of the finished product. In this case, the SOA itself. Thus, spending...

Once upon a time, whenever we connected application A to application B, or applications A and B to an integration server, we had to interact with those applications using some sort of interface that (hopefully) the applications provided. Interfaces into applications and databases varied greatly, including everything from simple, well-defined APIs to complex and cryptic exit calls, or perhaps something one level above screen scraping.

After hand coding the interfaces to the middleware layer a few hundred times, in essence creating mini-applications between the source or target applications and the middleware layer, middleware vendors began to pitch the notion of adapters.

Adapters are layers between the integration server and the source or target application. For example, an adapter could be a set of “libraries” that map the differences between two distinct interfaces   the integration server interface and the native interface of the source or target application and hide the complexities of those interfaces from the end user or even from the application integration developer using the integration server.

An integration server vendor may have adapters for several different source and target applications (such as SAP R/3, Baan, and PeopleSoft), or for certain types of databases (such as Oracle, Sybase, or DB2), or even for specific brands and types of middleware. Over time, adapters have become more sophisticated. They began as a set of libraries that developers had to manipulate, and evolved into binary interfaces that require little if any programming. Adapters are also getting smarter, with intelligence placed within the adapter, and with adapters running at the source and target systems in order to better capture events.

Two types of adapters exist in the context of SOA; thin adapters and thick adapters.

Thin Adapters

Today’s most popular SOAs offer thin adapters.  In most cases, they are simply API wrappers, or binders, which map the interface of the source or target system to a common interface supported by the integration server. In other words, they simply perform an API-binding trick, binding one API to another.

Thin adapters have the advantage of being simple to implement. With no additional, “thick” layer of software between source and target applications, there is greater granular control. However, thin adapters have a number of disadvantages. Because using them accomplishes nothing more than trading one interface for another, thin adapters impact performance without increasing functionality. And a fair amount of programming is still required. To complicate matters, the common APIs that are being mapped are almost always proprietary.

Thick Adapters

Unlike thin adapters, thick adapters provide a significant amount of software and functionality between the integration server infrastructure and the source or target applications. The thick adapter’s layer of abstraction makes managing movement or invoking processes painless.  Because the abstraction layer and the manager negotiate the differences between all the applications requiring integration, almost no programming is needed. 

Thick interfaces accomplish this via the layer of sophisticated software that hides the complexities of the source and target application interfaces from the integration server user. The user sees only a businesslike representation of the process and the metadata information as managed by the abstraction layer and the adapter. In many cases, the user connects many systems through this abstraction layer and the graphical user interface, without ever having to resort to hand-coding.

In addition, several abstraction layers may be created around the types of applications to be integrated. For example, there may be an abstraction for common middleware services (such as distributed objects, message-oriented middleware, and transactional middleware). There may also be an abstraction layer for packaged applications, and another layer to address the integration of relational and nonrelational databases. This structure hides from the end user the complexities of the interfaces that each entity (middleware, packaged applications, and databases) employs.

Another feature of a thick adapter is the ability to think and process information on its own, independent of the integration server.  Processing performed by thick adapters may include

• Simple transformation of application semantics, such as the transformation of a native format to a canonical form.
• Exception-handling routines.
• Information queuing and restart in case of integration server outages.
• Direct routing of information that may not need service from the integration server.

David S. Linthicum (Dave) is a managing partner with Zapthink, LLC a consulting and advisory organization dedicated to excellence in SOA planning, implementation, training, mentoring, and strategy. Dave is an internationally known application integration and SOA expert. In his career Dave has assisted in the formation of many of the ideas behind modern distributed computing including Enterprise Application Integration, B2B Application Integration, and SOA, approaches and technologies in wide use today. Dave keynotes at most major SOA and Enterprise Architecture conferences, maintains one of the most read SOA blogs, is the host of the weekly SOA Report Podcast, and is the author of 10 books, 3 on integration and SOA topics. You can reach Dave at david@zapthink.com.

Back to Articles, including SOA, BPM & BA