Enterprise Software

Six ways to make SOA services more reusable

Developers can take steps to ensure that services that are put out there are as reusable as technically possible. Vijay Narayanan provides developers with six guidelines of what will hopefully be reusable services.

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

Justin James
Justin James

I would imagine that if someone couldn't reuse their SOA stuff, then they don't have "SOA", they have a Web service designed to work only with one application. J.Ja


People just throw around the word "SOA" like it's some form of magic that is going to resolve world hunger. "SOA" is an encompassing term for a wide range of technologies, people need to learn to be more specific when they're talking about technologies related to Service Oriented Architecture. Another thing that bothers me is that people assume everything SHOULD be reusable. For sure, there is a lot of value gained from reuse, but not when you're trying to make the round peg fit in the square hole. A lot of the trouble with SOA these days is people think they should be able to use previously written services for anything, when in fact, that was not their purpose to begin with. It's OKAY to write services for a particular task, and slap someone's hand if they want to use a web service that checks stock prices to determine the geo-orbital position of a satellite.

Tony Hopkinson
Tony Hopkinson

fixing the mess? :D What can we SOA today. It's just another crappy view of the componentisation resuse issue. Make something a component and it's resuable. The fact that it's good for nothing else, was missed by management when skipping round their desk, fingers in their eare singing la lal la la.

Editor's Picks