Zenning

If we want to throw open the road ahead,
We must first push down the wall that’s facing us.
- Hong Yuan (~1533)

Pig Piling

WS-xxx, SOA, ... pig pile!

I agree with Sean. Carlos last few articles have really been a blast reading.

Then over on the other side of the room, speaking of blasts, James is pointing to Jonathan Schwartz's blasting away at WS-xxx hell as well.

From Herr Schwartz...

Web services may collapse under its own weight. No one at the conference said this. Those are my words. I'm beginning to feel that all the disparate web service specs and fragmented standards activities are way out of control. Want proof? Ask one of your IT folks to define web services. Ask two others. They won't match. We asked folks around the room - it was pretty grim. It's either got to be simplified, or radically rethought.

As you know, I also believe simplicity and volume always win - and that today's web services initiatives are in danger of vastly overcomplicating a very simple (really simple) solution.

Marketing

Kurt Cagle comments (to Sean Mcgrath)...

SOA is destined to become the has-been term of 2005, no doubt to be replaced by some other bit of marketing wizardry that is just as meaningless.

(Kurt Cagle works and writes about many things to do with XML.)

Steering

Ron Jeffries writes...

What is fascinating is that there is no aspect of life or business where things work perfectly, the first time, on time, without any cost. And yet they ask us for that. I believe that it is because, historically, they've had no way to steer, so they don't recognize right away that now they have one.

Languaging

Bill de hÓra writes...

You can think of it this way - if Lisp and Smalltalk represent some kind of maxima for expressivity in programming languages then speech act languages like KIF and FIPA-ACL represent a maxima for expressivity in Internet application protocols.

I guess I'll have to figure out what those are.

Enough research and experimentation has been conducted on software agent communication languages over the last twenty years to gives us an inkling of how this might work. The primary problem with this option is social - my guess is that it's more difficult to innovate with application protocols than content models since app protocols tend to be baked into the infrastructure as of the beginning of the 21st Century. And we do tend to think of protocols in engineering terms (interfaces, structures. bits, wires) rather than as linguistic phenomena. It's not called the Internet Language Task Force after all.

Hmm. Interesting. I've been of the mind that there are a small number of application protocols and then another level of protocols could evolve as sequences. (Kind of using DNA bases and sequences as metaphors.) So we need a basic technical structure that will enable a socially acceptable process for evolution.

Minimizing Obligations

Sam Ruby writes...

I personally like conclusions that minimize obligations for all concerned.

Interestingly, Sam is writing about legal issues, but this applies equally well to purely technical design issues.

The REST of Radovan Janecek's List

I've commented on one item from Radovan's list already. Now for the REST...

any other metadata has to be referenced from the representation of the resource

This is good. Semantic nets typically connect data (e.g. "frames" and "slots") and metadata (e.g. "facets" of a slot) directly. I would expect this to be so for a semantic web as well.

use of REST is not always appropriate (even if theoretically it can be used almost everywhere)

This is almost certainly so. But I suppose it is more broadly appropriate than its current range. And less clear is what is more appropriate in those other cases. Certainly there are cases where pre-existing systems are more appropriate. But what of the up-and-coming distributed systems technologies?

REST might be inappropriate especially if the integrated legacy system defines its own non-RESTful abstractions (e.g. SAP's BAPI).

Certainly there will be these cases. But I'm not sure SAP R3 can be put in that category. First, SAP has provided at least a couple of web-services-like interfaces to R3 and newer components. This is settling into the Netweaver/XI integration platform.

I don't know much about this yet, but I don't see why REST would be incompatible. One of the best presentations at OSCON 2003 was convincingly about a Perl and REST interface to R3.

use of REST is especially appropriate for generic system-level services that are expected to be used by robots (registry, security, management, reporting)

I think you are underestimating what a "robot" (i.e. an "interpreter" of semi-structured information) can do. See the Experiments with OVAL paper for a variety of examples using very modest software.

REST is appropriate for hypermedia, of course ;-)

Maybe a good discussion could be about what is suitable for representation as a hypermedia?

building REST applications, WS-* should be used wherever possible to ensure interoperability

Maybe this should be turned around a bit to say that WS-* should be defined to be compatible with the web.

RDF/OWL is more important for REST applications than it seems today

I think generally we need to learn how to build more evolvable application-specific semantic web interpreters. I know a little about RDF and less about OWL, although I am familiar with older semantic net languages. I think this statement could be so. But again referring to OVAL, a lot can be accomplished without getting to deep into heuristics.

Resources

Danny Ayers has a new blog on grid computing and such. One of his first posts is a look at WS resources and RDF. He lays it out nicely and has some good questions around how these seemingly related approaches might actually be compatible, or not.

Semantic Web Interpreters

A couple of inspirations come to mind that I periodically reference here for multiple reasons. Thinking about semantic web interpreters bring these to mind today.

• Adaptive Object Models
• OVAL by Malone, Fry, and Lai

These sources should be absorbed as fundamental background for building RESTful interpreters.

Good Enough

Carlos Perez on SOAP and REST...

If WS-Security is rarely used, HTTPS is good enough and interoperable web services is via XML Schema validation of documents then it becomes less clear what exactly SOAP brings to the table.

SOAP adherents say REST can't be made reliable. However, argue that point with Bill de Hora who recently published HTTPLR a reliable way of transmitting messages via HTTP. The spec is consistent with HTTP semantics rather than extending or abusing them. In otherwords, reliability without the extra baggage of SOAP.

Moreover

There are a couple threads that could be tied together.

Radovan Janecek writes about REST...

A resource has to return not only 'data' but also a contract that tells how to work with this resource further - i.e. what to POST and when. In case of browser-based applications, this is somehow solved by HTML. Otherwise, I think WSDL can be used.

I don't think this is quite so. The browser is interpreting representations at runtime. WSDL will present a description of the shape of the runtime data, but the application using the WSDL will still have to do the interpreting.

The choice is definitely not confined to a browser interpreting HTML or something else interpreting WSDL. No, there are many potential examples of other runtime interpreters. I think a good example is a "workflow engine" that interprets workflow descriptions. Let's say a workflow is stored on a server somewhere. The engine GET's a description of the workflow. Let's say the representation is a collection of RDF triples, some of which describe the orchestration of the workflow. Others describe the procedures being orchestrated, and still others may describe some of the work-in-progress.

The workflow engine, like the browser, is a runtime interpreter of state representations. The browser interprets HTML pages. The engine interprets workflows. The browser understands HTML. The engine understands the orchestration triples. When a procedure is encountered the engine interprets that by invoking the procedure at the given location (or perhaps just abstractly "on the grid") with the given work-in-progress triples as parameters of the procedure.

The RDF triples are runtime state representation, analogous to HTML. The workflow engine is the runtime interpreter, analogous to the browser. An infinite variety of runtime interpreters is imagineable. Mapping engines to interpret locations, ledgers to interpret sequences of transactions, purchasing agents to interpret items for sale.

So are there an infinite variety of state representations. The interpreters will vary by purpose, but their interfaces should be fairly constrained (i.e. RESTful). The state representations will be more broadly useful if they too are somewhat constrained, i.e. if your restful interpreter and mine can understand some of the same state then they can cooperate. This is the idea behind these interpreters sharing partial ontologies or even being able to translate parts of one to another.

Meanwhile Mark Baker quotes Hugh Winkler and then notes...

"When you sit down to write a description language for REST services (a IDL or WSDL for REST), you discover that doing so is unnecessary." Absolutely. The application state machine needs describing (at runtime), not the services (at design time).

The web is a dynamic, distributed runtime. We need to act like language designers and we need to understand dynamic languages.

Classic Rock

Paul Beard uses The Doors as his canary. Tim Bray uses Pink Floyd's The Wall.

Those both work for me. We have (at least?) three Classic Rock radio stations in my area, so I can bounce around those to avoid commercials as well as worn-out music (and beyond into jazz, community radio, progressive politics, sports, etc.)

The best station though has the weakest signal. Two of the stations are here in Portland. The best one comes out of Corvalis where I suppose there is less commercial pressure, or maybe they're just not owned by a conglomerate with a corporate play list.

In fact the Corvalis station, KLOO-FM, reminds me a lot of early 1970's album-oriented stations that don't just play the "hits". They play the songs they want, wherever the song shows up on the album.

Me too and eight-track tapes

Sam Ruby writes...

I'm old enough to remember when relational databases were controversial.

Me too. Sometime talking about the computer industry in the 21st century feels like talking about the iPod vs. eight-track tapes with my kids. (Not to mention reel-to-reel. Remember those?)

Commonality and Variation

I comment on Ted Neward's observations...

SOA as just another paradigm for commonality and variation... just so, even more generally. SOA is a new term, but people were arguing RPC vs. asynchronous message passing 20 years ago, not just in the labs but in production.

I used Apollo Domain workstations and their Aegis OS at Boeing and Mentor Graphics. In the late 1980's I was in discussions about their built-in distributed OS and mailbox channels vs. the emerging broader standards for RPC. People were arguing about RPC parameters vs. sending ASN.1 data structures (i.e. flexible trees of property/value pairs). Not much new in this SOA world but the terms and new standards which look a good bit like some of the older ones!

QOTD

"Intuition leads scientists astray every time."

A Secure Scheme-based OS

When I read this...

• A type-safe abstract instruction set (MSIL) as the only system binary interface.
• A unified extension mechanism for applications and the OS.
• A strong process isolation architecture.
• A ubiquitous metadata infrastructure to describes code, data, and communication.

(via this), I think of this. Obviously one has a large, ambitious team and the other represents work by a few people in a more narrow area. But a comparative analysis where they overlap would be worth reading.