X
Business

Six ways to make SOA services more reusable

Achieving service reuse is a multi-dimensional problem that ties into technical approaches as well as business governance. In my last post, I surfaced some of JP Morgenthal's concerns about the reusability of services in their current state (or statefulness).
Written by Joe McKendrick, Contributing Writer

Achieving service reuse is a multi-dimensional problem that ties into technical approaches as well as business governance. In my last post, I surfaced some of JP Morgenthal's concerns about the reusability of services in their current state (or statefulness).

But there are steps that can be taken to ensure that services that are put out there are as reusable as technically possible. In a new article over at SOA Magazine, Vijay Narayanan explains some of the elements that need to be considered when building a service intended for reuse. (Which, in an SOA context, should be most of them.)

Vijay provides the following guidelines to developers of what will hopefully be reusable services:

Decouple the Physical Transport from the Service Logic: "This will ensure that the service can be bound to additional transports gracefully and provide flexibility offer transports on an as needed basis."

Provide Standard Interfaces for Service Access: This provides "the flexibility to change implementations over time or offer multiple implementations based on [service level agreement] requirements."

Offer Standardized Publications of Your Business Processes and Entity Services: Make sure messages aren't too specific to technologies, or to consumers. "These standard publication messages need to reuse your business schema data types, object definitions, as well as underlying service components."

Create Service Adapters for Backwards Compatibility: This approach ensures that the code base is thinner due to the reused service logic; isolates and encapsulates the service adapter layer for easier replacement; makes the adapter reusable across transports to avoid custom solutions; and modularizes adapter itself.

Apply Cross-Cutting Concerns Horizontally: "Never put logic for capabilities in a single service because chances are you will surely need them for another one."

Ensure that Your Services are Interoperable: "Take no chances and ensure that the WSDL document can be consumed successfully by the major technology platforms and that your target consumers can generate proxies and XML data bindings from the WSDL."

To ensure reuse, Vijay urges developers and architects to make sure "their design decisions are made to decouple services from transport, distribution channel, access pattern and standard messaging interfaces."

Editorial standards