·:[ Integrate This ]:·
• • • • •

Coactus is back!

We’re currently running at about 50-60% capacity, so the kind of work we can take on is somewhat limited, but not too much so. Anything that doesn’t involve travel assignments longer than a week would be fine.

Unfortunately, for personal reasons I have to put Coactus on hiatus, for at least a couple of years. I’m now actively seeking employment.

I’ll keep this site around indefinitely, but I haven’t decided if I’ll keep posting to this blog. We’ll see. You can always follow my personal blog.

… is the title of a
presentation I crafted – ably presented by Makoto Murata in Japan last week – about how the Web is already a platform for network based services, without the “help” of Web services related specifications.

A common technique in software development, but particularly in distributed software development, is the “separation of interface from implementation”, whereby software components are developed to have dependencies only upon the interfaces (the connectors, in architectural terms) of other components, and not their implementations. The purpose of this technique is to isolate the impact of a change of implementation to just the changed component, thereby reducing coupling between components. The technique is so pervasively referenced and evangelized, that it’s practically axiomatic.

Unfortunately, it’s not commonly practiced.

Many who claim that they’re using this technique will tell you that the use of a description language, such as IDL or more commonly nowadays, WSDL, does this for them. It does not.

As mentioned, the purpose of the technique is to isolate the impact of implementation changes. Yet this WSDL contract for a new home buyers database places extreme restrictions on how the implementation can vary because it is so specific to, well, a new home buyers database. Need an interface to an historical database of home purchases, or one to a database of recent automobile sales? Too bad, you need a new interface, and therefore new code to use that service. So much for that separation of concerns!

The lesson here, I suggest, is the following;

True separation of interface from implementation requires designing broadly reusable interfaces.

Adam Bosworth has published a great article in ACM Queue titled Learning from THE WEB. As you might expect, it’s very much in the vein of previous missives from Adam, where he highlights the advantages of Web based development, much as we espouse here.

As surely comes as no surprise to my regular readers, I largely agree with the points Adam makes in this article. But rather than focus on those points, I’d like to instead make an observation about his writing style, and the descriptors he uses for the Web, since I feel this makes for an interesting contrast with my own style.

Adam uses words like “sloppy” to describe what I would describe as the principled application of must-ignore style extensibility (as seen throughout Web architecture). It’s not that either descriptor is “better” or “worse” necessarily, just different sides of the same coin … which isn’t recognized nearly enough IMO, by those who promote “better” alternatives to Web based development, e.g. Web services. But then that’s the same point Dick Gabriel was getting at with his schizophrenic and self-contradictory ramblings on Worse is better.

Update: the one part of the article I took issue with – the critique of the Semantic Web – is well countered by Danny Ayers.

(Sorry, my personal blog (and the machine that runs it) died while I’m on the road. I should have it up again Sunday or Monday).

Some sage advice from Steve Ballmer on services;

Ballmer also suggested that the corporate network and the Web shouldn’t be thought of as two entities that get searched separately and that the two should be tied together to provide one seamless search experience.

which happens to jive nicely with some recent advice from the W3C TAG to the WS-Addressing working group, which were one of the outcomes of an issue I raised;

Web Architecture dictates that resources should be identified with
URIs. Thus, use of the abstract properties of an EPR other than
wsa:address to identify resources is contrary to Web Architecture. In
certain circumstances, use of such additional properties may be convenient
or beneficial, perhaps due to the availability of QName-based tools. When
building systems that violate this principle, care must be taken to weigh
the tradeoffs inherent in deploying resources that are not on the Web.

Here’s hoping that this might serve to motivate Web services proponents to realize the Web meets their requirements – for a loosely coupled, document oriented, platform independent distributed computing framework – better than Web services themselves.

If you’re interested in the use of XML in compound documents, I’ve started writing a semi-regular “column” on the xfytec community site (specifically, the news section, but the site’s going to be restructured to make news more prominent).

As you might expect from the brilliant, intrepid (and largely neutral) technologist/writer, Jon Udell, when it comes to Web services and the “REST vs. SOA(P)” debate, he looks for the middleground;

Today’s most visible exemplars of WS-Lite — Amazon and eBay — use Web services in a point-to-point way. In that mode there’s not much difference between SOAP/WSDL APIs and REST APIs, so it’s not surprising that developers who work with these platforms overwhelmingly prefer the REST flavor. But when you do need to flow your XML traffic through intermediaries, SOAP and WSDL suddenly make a lot more sense.

When a rich intermediary model is what is required, I agree wholeheartedly that SOAP’s is superior to that of vanilla HTTP. But I have two concerns with that last sentence.

The first is to point out that SOAP’s intermediary and processing models are RESTful, as they respect REST’s self-descriptive and layered constraints. I fear that Jon’s readers might interpret his statement as implying a false dichotomy; that the use of SOAP excludes the use of REST. I don’t know whether this was Jon’s intention, of course.

My second concern, related to the first, is the mention of WSDL. WSDL was designed primarily for the purpose of describing service interfaces, therefore implicitly suggesting that services need different interfaces. But what’s not often recognized is that an intermediary model such as SOAP’s (i.e. an application layer one) only makes sense with an architectural style where interface constraints are used, as only by constraining interfaces does composition become tractable.

I applaud Jon on his efforts to find a middle ground, primarily because in doing so he his giving the Web-friendly RESTful approach much needed respect and visibility. But I think that middle ground is to be found further from the WS-* end of the spectrum than he seems to believe.

I’ve confirmed that I’ll be speaking at CommerceNet at their Thursday Tech Talk this week. However, the previously mentioned subject has changed; I’ll now be talking about the use of XForms for RESTful service description.

Ian Foster, well known Grid Illuminati, wrote an interesting draft paper titled
“How do I access state? Let me count the ways” (Google’s cached HTML version) earlier this year (which somehow evaded by radar), that discusses various approaches to handling state in four alternative architectural styles (or parts thereof) vying to be the base style to make the big picture Grid/SOA visions a reality.

It’s an interesting paper, with a fairly solid introduction to the issue that I agree with almost entirely. It’s also flattering (for the whole REST community, not just myself) that REST is even considered. Unfortunately, the conclusions fall short of the high standard set by the introduction, as REST is misrepresented.

The first indication of problems is the title of the first concluding sub-section; “Implementation Architecture as a Nonissue”. Prima facie this seems questionable, as the study of software architecture tells us that the architectural style one choices is critical in determining the resulting properties of a system. But let’s dig a little deeper;

It has been argued that some interfaces permit more reliable or efficient implementations than others. However, this argument is discredited by the fact that the messages transmitted across the wire in each approach contain essentially the same information.

The emphasis on “essentially” is mine, because the fact is that the messages described earlier in the paper do contain different information, and, as it turns out in this case, that information is critical to fully appreciating REST (and other document oriented architectural styles, though the paper doesn’t get into any of those).

Though there are several claims in the paper that misrepresent various aspects of REST, as well as confusing the Web, REST, and common practice using both, the following from the summary is probably the single most significant misrepresentation, and I’d guess the cause of the belief that lead to the problem described in the previous paragraph. It reads;

In contrast, what we call the State Id and REST approaches adopts a domain-specific encoding of operations, on top of SOAP and HTTP, respectively.

In a RESTful use of HTTP, HTTP provides the operations; there is nothing more to be encoded, domain-specifically or not. Only the data payload – the document representing the state of the job, or whatever it might be – is required, as I previously explained . It’s an odd oversight, because Table 6, which details the RESTful messages, makes no mention of any operation other than the HTTP ones.

I’d be interested in Ian’s comments about how this might impact the paper’s conclusions. I’d also be happy to provide a more detailed response to some of the other claims about the REST approach that I disagreed with, if requested.