Thursday, June 14, 2007

Service-oriented Standards

I've been thinking about standards for service-oriented architecture after a discussion with architects in our CTO team and our IITS division (IITS was formerly known as IDX). If you're working on service-oriented architecture, the sheer number of standards you have to be aware of is astounding.

Of course, you'll need to be aware of the basic XML standards, XSLT, XPath, etc. On top of that, you have to worry about security, where the WS-Security standard plays an important role, as do SAML, X.509, WS-Policy, and possibly WS-SecureExchange, and WS-Federation. Once you have a handle on security, you'll need to start thinking about data exchange standards. Specifically, you should probably pay attention to the WS-MetaDataExchange standard, as well as standards from organizations like OASIS. In the long run, meta data will be the toughest nut to crack. Once you've defined an approach for managing meta data, you'll need to start paying attention to business process specifications. In this realm, the leading standards are the BPDM, BPEL, and BPDM standards. These in turn, are based on the ubiquitous WSDL standard. So you've now read through more than a dozen standards documents, involving thousands of pages of specifications. And you haven't created a service yet.

When you're thinking about implementation, you'll need to worry about messaging and transport. So you'll need to look at various messaging standards, depending on your implementation environment. If you're in a Microsoft shop, you'll probably need to work with BizTalk, Windows Communication Foundation, and .NET. If you're working in a Java shop, EJB might play a role, as might the JAX standards, JMS, and maybe even JBI.

The JBI (Java Business Integration) standard has emerged to provide some level of compatibility between enterprise service bus implementations. The newest standards on the block are the Service Component Architecture (SCA) and the Service Data Objects (SDO) standards.

If you believe the press, everybody is doing SOA. We have all done the neccessary ROI analysis, and are realizing the agility, flexibility, and reuse that SOA provides. Not. We're too busy trying to figure out how to apply all these standards, or how to find a single vendor that supports enough of a subset of the standards so that their own products work together. Or even worse, we're trying to find products from multiple vendors that work together using the same version of some subset of these standards.

There are simply too many standards to worry about. Is SCA the answer?