Middleware Matters

In my previous blog entry I began a discussion of multi-port web service references. Read that first if you haven't already done so, otherwise the following might not make sense.

There are at least four approaches to dealing with this problem:

1. Augment the EPR with additional optional port information. One way to do this is to add an abstract property (using WS-Addressing specification terminology) for additional ports. This would essentially amount to including WSDL port information by value in the EPR.
2. Standardize a policy assertion that could convey additional optional port information within an EPR. Sanjiva came up with this possibility, based presumably on WS-Policy. This might work, but suffers from the problem that WS-Policy is not an actual standard and so can't be referenced from the WS-Addressing standard. (Over in his blog, Sanjiva also discusses the somewhat related failed attempt to add service references to WSDL 2.0.)
3. Create a separate structure that can hold one or more EPRs. "Multi-port EPR" is a bit of a misnomer, since "endpoint" and "port" are somewhat synonymous. This approach leaves the existing EPR as it is, and creates a separate container capable of holding them. This container would hold information for a service's multiple ports by value, and could be passed around. It's thus almost identical to a WSDL service element.
4. Use WS-MetadataExchange (WS-MEX) instead. With this approach, a consumer uses a service's advertised EPR to retrieve the service's metadata, which in turn contains additional port information. From talking to Don, I believe this is the approach Microsoft takes.

What it ultimately comes down to is whether you can pass the multiple port information around by value, or you pass a reference that can be used to indirectly obtain info about other ports. The "by value" approach is reminiscent of CORBA interoperable object references (IORs), which long ago proved the viability and usefulness of having a reference structure that can hold connectivity details for any number of protocols and transports. And no, the fact that I mentioned the IOR doesn't imply that I'm trying to turn web services into distributed objects. I'm not. All I'm talking about here is service references, and I mention the IOR because it's conceptually similar to what I'm looking for from WS-Addressing.

Approach 4 listed above would of course work, but it suffers from a couple of drawbacks. First, it requires network operations to retrieve the port information, which may be fairly expensive. Second, it's not a good approach for existing legacy services that can't be rebuilt and redeployed to support WS-MEX. You could introduce a separate WS-MEX service process for such services, but that just adds management and provisioning overhead within a production system. Because of these limitations, at IONA we use an approach similar to WS-MEX only when absolutely necessary. I still therefore prefer an approach more like 1 or 3 above.

Stay tuned, still more to follow.

Lately I've been posting thoughts here about multi-protocol endpoint references (EPRs). Jim Webber comments that he prefers a single kind of endpoint per EPR, i.e., having one or more SOAP endpoints in an EPR would be ok, but having a SOAP, MQ, and IIOP endpoint in the same EPR, for example, would not.

Seems like a needless restriction. Jim says we should just "accept that Web Services are about SOAP not WSDL." If the EPR or the WS-Addressing spec becomes extraordinarily complicated by adding optional support for things other than SOAP, then I agree, let's not go there. Fortunately, that doesn't need to happen. There are a boatload of existing and valuable services in all the enterprises out there that, with a suitable approach, can be brought forward into the service-oriented present in an economically viable manner without requiring them to be rewritten, retested, requalified, and redeployed just to make them speak SOAP.

Web services are not so much about SOAP as they are about messages and contracts, rather than being about ubiquitous object models and specific infrastructure implementations as with prior approaches. SOAP is certainly a good way to encode such messages, but it's not the last good way we'll ever see. WSDL is, however, a great way of describing and abstracting services, one that can last for quite awhile because it's a step removed from specific technologies. It supports SOAP, but does not require SOAP. Through its extensibility, WSDL can also support the older protocols and message formats that are still important in today's enterprises. As underlying technologies like SOAP come and go, and they surely will, WSDL and its extensibility can accommodate them.

Look at CORBA IDL. It was defined years before IIOP, and was used with a variety of vendor-specific protocols and transfer syntaxes before IIOP was created. What's interesting is that IDL didn't change at all when IIOP came along. It worked for IIOP-accessible systems and yet continued to work for all the older vendor-specific protocols too. This allowed vendors to support the then-new IIOP interoperability standard as well as continue to support their own protocols, all without requiring their customers to make any application changes. CORBA would likely have died in the mid 90's if not for this fact, and yet here we are ten years later and it's still going strong.

Now, let's not get into yet another "WSDL is not IDL" argument. I'm not talking about objects vs. services, statefulness vs. statelessness, or any of those kinds of arguments. That's not my point. My point is that, just like with my business card analogy, what matters is the service and its contract. How I access the service might change over time, or might even change from one day to the next. What I'm ultimately interested in, and what ultimately provides business value, is the service, not the pipes leading to it. In other words, it's the end, not the means, that matters.

It all comes down to which word of the two words in the phrase "web services" you focus on. Jim, I would guess, focuses on the "web" part, hence his opinion that SOAP is all that matters. My colleagues and I, OTOH, focus on the "services" part, because most "web services" work today occurs within the enterprise, where a variety of protocols and message formats are a fact of life and will be for quite some time. There's no reason that I'm aware of that WS-Addressing can't serve both of these viewpoints equally well.

My brother Jim has just started blogging over at "Steady Earl's Rant." Jim is not a computer geek like me, so don't look there for middleware or distributed computing discussion. Instead, his blog contains a lot of political commentary, making it more like Chris Ferris's blog (also coincidentally containing the word "rant" in the title).

It appears, though, that Chris and Jim differ widely in their political views, which of course gives me a great idea: since all three of us live in the Boston area, I'll take Jim and Chris to lunch or dinner, introduce them, and just say, "Hey, how about that Iraq war?" or "Man, Karl Rove sure is my hero!" or even simply utter the phrase "gun control," and then sit back and watch the ensuing debates! I'll gladly pay for the whole meal, given what's sure to be the best entertainment I've seen in awhile! :-) Chris, Jim, when are you free?