In a perfect world, the implementation of a service oriented architecture (SOA) in your organization will help better align IT services with those day-to-day business processes in which your colleagues, customers, and partners engage. Yet, in order to reap the promise of SOA, the prudent CIO must wrangle both organizational and technology oriented challenges—keeping an eye out for common pitfalls.
In our years tackling SOA engagements for clients, we’ve learned a lot about what to watch for. Here are some of the most common sticking points:
1. Overlooking security inconsistencies. To assume vendors’ and developers’ security products will work together is to risk the safety and security of the corporate data around which you are building your SOA.
Case in point: in the course of a project integrating Apache’s WSS4J with Infravio’s SOA governance stack for a large client, we were asked to enable Web Services Security (WS-Security) for a range of services, from encryption to signature verification.
WS-Security, as you may know, is broadly accepted among open source developers as a security framework, and WSS4J is a popular implementation of WS-Security. We successfully enforced security at the intermediary level until we routed to a secured .NET service. It turns out that service expected an encrypted message. While we had the required certificate, every time we hit the service it returned a fault. Why was this? Well, WSS4J, in compliance with WS-Security, uses “xmldsig” in the name space—but the .NET service expected “xmlds.”
It’s but one example of a small inconsistency with big implications.
2. Assuming standards are in place. Yup, another “Gotcha”. Not all open source products comply with Web Services Interoperability (WS-1), though it is the broadly accepted industry standard. This is problematic, because the basic concept of SOA is built atop a foundation of standards compliance. Until the day comes when true adherence is the law of the open source land, be on the lookout for clashes.
Another example: in one of our SOA projects, we used
Pay close attention to the evolution of SOA specifications by reading trade journals and talking with peers at other organizations also working on SOA implementations. Such research will tip you off to potential problem areas.
3. Using poorly thought out naming conventions. Here’s another one where thinking ahead can save time down the road. In an SOA, multiple versions of the same services are consumed simultaneously by users all over the organization that may refer to one business process, e.g., one “service”using different terms. That’s why it’s critical that you decide early on how you will include the following parameters in the name-space of a service and propagate your chosen naming conventions across the development team handling your project:
▫ The business domain the service belongs to;
▫ The service name that explains the business function; and
▫ The major version of the service.
4. Relying on sub-par data. Many of the failures we’ve observed in SOA enablement projects originate from poor quality data. Careful cleansing of data sources would alleviate many of these issues and ensure information is accurate and standardized (e.g., “