ABOUT | COPYRIGHT

Service Oriented, Process Centric, Model Driven Heresies

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

01/17/08 :: [SOA] Inter-Action Definition Languages (IADL) [permalink]

Steve has started a discussion arguing that an IDL is bad, human consumable documentation is enough. His argument is that if you give an IDL to a developer, code generation will pop up and code generation is what makes distributed systems brittle.

We agree on the second point, actually my model of Loose Coupling predicts that: if C_i is generated from P_i, then if you change P_i, it will require a new code generation and it will break (in general) the implementation that is relying on C_i.

I have demonstrated that the "uniform interface" is a pure myth. If you still doubt, please consider Joe Gregorio's bookmark example (I am not even talking about actions here).

GET [user]/bookmarks/all

If you don't have the same user key, you need a key mapping and if your "wildcard" keyword is any, you are out of luck.

So when Steve says

for a client to invoke a REST service, it must understand only that service’s specific data contract: the interface contract is uniform for all services.

It is incorrect, widely incorrect. In "pure" REST where the URI is a series of character it would be true, but you would have to "search" for the URI of interest before you can do anything and you would have to maintain a huge indeces to relate your code to arbitrary URIs.

REST has simply found a way to avoid "code generation" for QBE APIs. I can expand my API footprint without breaking existing clients. Yes and WSDL can do that too. Not as simply, granted, but it can do that just as well provided you don't implement the "Big Bang" versioning approach recommended in WSDL 2.0 (I don't know who ever wrote that, but this is outrageous that such a recommendation could make it part of the spec).

Now, in response to John's comments. While talking to Mark Masterson a couple of weeks ago, I changed a bit my position about REST and loose coupling in the context of actions. I asked Stefan to give me his best guess at the way he would model actions in a resource representation, and this is what he told me:

(This is the equivalent of href for HTML - and human centric interactions)

Again, this link would be embedded in the resource representation. This means that all the loose coupling code between the resource representation could be implemented with XSLT, even the invocation of the action, i.e. the HTTP request could be entirely be generated by an XSLT transform. This is not as bad as I originally thought, I am ready to say that it is just as much coupling as WSDL, however, I don't think the REST community is using this implementation pattern today since they don't have explicit links in any ways otherwise they would have let me know. This pattern would work well with XSLT intermediaries too.

So when John writes (in Steve's comments):

A RESTful client application should be able to rely on some interaction engine to make application coding easier. (Not code-generation! That’s certainly not what I mean.)

I totally and fundamentally agree with him. But please, make these interactions bi-directional, please. I don't care if it looks like WSDL (metadata is very easy to transform and manipulate). All I request is that it is an "inter-action" definition language (IADL), otherwise we are back to the 90s. Be assured that the old guard is still there and they will convince you that you don't need it, please don't be fooled.

At the end of the day, I am a wsper guy, as I said, I don't care who wins, I want to be able to do my job as an architect. If GWT can teach you anything is that when something is too powerful (people can shoot themselves in the foot at every line of code) to be used by developers, then you need to create a "development" language and a "runtime" language. You need the runtime language because it is easier to write the virtual machine for this language than it would be for the development language. This is wsper is all about.

Now WS-* has three technologies that REST-* does not have yet:

WSDL is an IADL (I use the term "surface" instead of interface to really describe the fact that an IADL interface is round, it wraps the component entirely, in all directions, it is not flat).
WS-BPEL is a programming language where interactions (and interaction handling) are explicit
SCA provides an assembly mechanism to "wire" inter-actions of otherwise slightly incompatible surfaces

If you give me that, I'll become a very strong REST advocate.

I feel that we have made tremendous progress.