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?

Services, Schmervices

Service-oriented architecture (SOA) was flagged as the "most-despised" buzzword in a survey by Network computing. I can understand that. "Service-Oriented" is to a system as "High Definition" is to the latest consumer product. We have high-definition television, high-definition radio, high-definition phones, high-definition linoleum, and even high-definition dishwashers. It seems that in the last year or two, every minor new product from software vendors is the answer to every problem you've ever had developing your own service-oriented architecture.

But developing software with services, or better yet, software as a service, really is different. There isn't a lot of good guidance out there. You'd think after twenty or twenty-five years of figuring out how to develop distributed systems, somebody would have the answer.

About a dozen years ago, distributed objects were the way to go. Client-server was so yesterday. You just had to throw a system together from CORBA or DCOM components, and you were cool. The problem was that it wasn't easy, and it was really hard to get the granularity right so the system would scale and perform. Here we are a dozen years later, and service-oriented is the way to go. The web is so yesterday. You just throw a system together with some web services and an enterprise service bus, and you're cool. The problem is that it isn't easy, and it's really hard to get the granularity right so the system scales and performs. Hmm, does anybody see a pattern here?

But this time it's different....

Let's restart this

It's been far too long since the last post. Since I last jotted anything down, things have changed a bit. We finally brought someone in to dedicate time to our production support team, so I quickly handed things over to him. And he's done a great job, bringing our backlog down and keeping it down.

I've moved into a new role where I'm now focused on IT strategy. My employer is probably the best around at execution: when we make commitments, we keep them. But we often think so much about the current project, the current quarter, the current problem, that we lose sight of the direction we're supposed to head.

So the posts will head another direction. I'll be looking at service-oriented architecture, business process management, web 2.0 & enterprise 2.0 stuff. And since I get to think about this stuff full time now, maybe I can get myself to post a little more frequently.