This is the second article in a series designed to help the reader better understand the value of a service-oriented architecture (SOA), and to assist in developing a realistic plan for evaluating your current infrastructure and migrating it to a true service-oriented architecture. It is intended that, after reading this article, you will understand why it is claimed that a SOA is the best platform for carrying existing assets into the future, as well as enabling the rapid and correct development of future applications. Further, you should have a better understanding of the major considerations in planning such a migration.

Part 1 of this series described some of the forces driving consideration of a SOA, and also covered the requirements that might be placed on the architecture. Part 2 continues now with a discussion on services and interfaces.

The Nature of a Service

What then is a service? As previously stated, typically within a business environment it refers to business functions, business transactions, and system services. Examples of business functions might be getStockQuote, getCustomerAddress, or checkCreditRating. Examples of business transactions might be commitInventory, sellCoveredOption, or scheduleDelivery. Examples of system services might be logMessageIn, getTimeStamp, or openFile. Note the difference in the types of services. Business functions are, from the application's perspective, non-system functions that are effectively atomic.

Business transactions might seem like a simple function to the invoking application, but they might be implemented as composite functions covered by their own transactional context. They might involve multiple lower-level functions, transparent to the caller. System functions are generalized functions that can be abstracted out to the particular platform — for instance, Windows or Linux. A generic function such as openFile might be provided by the application framework to effectively virtualize the data source and used regardless of the type and location of the real source of the data.

This might seem like an artificial distinction of the services; you could assert that, from the application's perspective, all the services are atomic, and it is irrelevant whether they are business or system services. The distinction is made merely to introduce the important concept of granularity. The decomposition of business applications into services is not just an abstract process; it has very real practical implications.

Services might be low-level or complex high-level (fine-grained or course-grained) functions, and there are very real trade-offs in terms of performance, flexibility, maintainability, and re-use, based on their definition. This process of defining services is normally accomplished within a larger scope — that of the Application Framework. This is the actual work that must be done; that is, the development of a component-based Application Framework, wherein the services are defined as a set of reusable components that can in turn be used to build new applications or integrate existing software assets.

There are many such frameworks available today; within IBM, several frameworks, such as EWA, JADE, and Struts (from Jakarta) are being used in customer integration scenarios. Taking EWA (pronounced "Eva") from the IBM Software Group Advanced Technology Solutions team, for example, at a very high level, the framework looks like Figure 1 below. Within this framework, a configuration defines an application, describing the components of the application, as well as the sequence and method of their invocation. Input is received and passed to the application in a source-neutral way.

So, for instance, the addition of an Internet connection to a bank application with existing ATM access is transparent to the application logic. The front-end device and protocol handlers make that possible. The core provides system-level services, and special-purpose access components enable connection to backend enterprise applications, so that they may remain in place, or be migrated over time. While EWA is fully J2EE-compliant, it can connect to external DCOM or CORBA component-based systems.

Click here for a larger image.

Figure 1. EWA Block Diagram

Today, EWA contains over 1,500 general and special-purpose components, thus greatly reducing the amount of code that must be written for a new application. Another article in this series will examine Application Frameworks in detail, along with what a user might expect in the process of developing one.

Page 2: Addressing the Old Problems