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 challengeskeeping an eye out for common pitfalls.
In our years tackling SOA engagements for clients, weve 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 Apaches WSS4J with Infravios 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 spacebut the .NET service expected xmlds.
Its 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. Heres 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 serviceusing different terms. Thats why its 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 weve 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.,