Services are very different than points of information production or consumption because they denote behavior. Indeed, they are application functions that you may extend from one application to another by leveraging some type of service delivery standard such as Web services.

Having said that there are many that still view the ability to expose information, albeit through services, as service-oriented. This is a common mistake, and we must keep in mind that the notion of SOA and SOI is all about the ability to share behavior and information bound to those behaviors, and not just information. The rise of messaging technology with Web services interfaces have lead to this confusion, while they are indeed leveraging services they are doing so to move information across a queue, not aggregate and manage remote application functions.

Services are a bit more complex to expose due to the intricacies of the native interfaces, if they indeed exist. Thus, how you expose existing services requires some creativity and perhaps some good technology. For our purposes I like to classify existing services in one of these categories:

- Existing-and-Exposed
- Aggregated and Single Transactions
- API Services
- Recast Standard Interfaces
- Ported Services

Existing-and-exposed types of services, are just what they sound like. They already exist and are already exposed as Web services. Examples of this include the newer versions of SAP and PeopleSoft that have redone their interfaces as Web services, and thus are ready to plug into a SOA. In some instances you may have to do some fine tuning for compatibility, but the idea is that your major enterprise software vendors do the service-enablement work for you. This, of course, is the best case scenario and least expensive and least risky.

Aggregated and single transactions are transactional systems that are exposed as services. Examples of these types of existing services are CICS, Tuxedo, and even J2EE transactions that are seen as Web services externally, typically through software provided by transactional container vendors. For instance, in the case of CICS, IBM's WebSphere is able to expose these transactions as services and almost all J2EE tool and container providers also offer Web services capabilities. This tends to be more of a natural 1-to-1 fit, since transactions are well defined and granular, and so should be Web services. This is less costly and less risky.

API services are APIs that are "wrapped" so they appear as services. This means leveraging an API-to-Web services translation layer, such as mechanisms some middleware vendors provide, or creating a translation layer on your own. The translation layer needs to manage the mediation between the exposed Web services that represent the API, and the API itself. This includes exception handling, reliability issues, as well as security.

Recast standard interfaces, like API services, means that we're looking to leveraging an existing standard interface, such as JMS, JCA, ebXML, RMI, etc., and expose them as Web services. In essence you’re recasting one standard for another, and the same problems that you solve when considering API services you need to solve here, including managing the mediation between the standards and exposed services, as well as all operational aspects.
The cost and risk tradeoffs are the same as with API services.

Finally, ported services, the last resort, is a rewrite exercise where you take existing application functions and rewrite them as Web services. This means a new architecture, as well as hand coding the existing interfaces so they appear as true Web services. As you may have guessed, this is the most risky and time consuming of all of these categories since you must suffer through the redevelopment, testing, and redeployment of the systems just to support Web services.

Posted by Dave Linthicum on October 4, 2006 06:43 AM