Is WSDL an IDL? Does it matter?

Stefan writes Even more on WSDL vs. IDL (apparently as a follow-up to Jim and Mark).

According to Jim, The killer differentiator is that for a given WSDL portType (or soon "interface" in WSDL 2.0) there is no implication that the portType is "implemented" by a specific class at the back-end.

Why precisely does he think there is such an implication for IDL?

In my opinion, IDL (in cooperation with the actual wire format specs like IIOP and COM/DCOM) only defines that something will receive messages of some form and produce others.

In a pseudo protocol, a message
  "invoke operation add with the parameters int 3 and int 5"
is guaranteed to be replied to with a message of the form
  "result of operation add is int x"

I don't think IDL specifies that there will be an actual object with the method named add that will be invoked because what exactly is an object? I can code such a beast in machine language and it will still work even though my machine language has no notion of objects.

If there is any difference between IDL and WSDL, it's that WSDL is more explicit about not depending on what the implementation looks like, and Web Services have much lower entry barrier than, say, CORBA or COM.

Posted at 1409 on Wed, Apr 7, 2004 in category Ideas, Work | TrackBack | Comments feed
Comments

Hi Jacek,

Isn't the implementation dependence exactly the point? IDL (CORBA IDL at least) does not stand alone, it's accompanied by the appropriate programming language mappings. And the OO variants (C++ and Java, and maybe others) invariably define that the implementation is handled by an object. That's why I think Jim has a point here.

As to the lower entry barrier, I believe this is not because of a conceptual difference, but because tools in general have become much better. If Systinet were in the CORBA business, I doubt a "CORBA Developer" plugin for Eclipse would be any harder to use or a server harder to deploy than the WASP versions.

Posted by: Stefan Tilkov at April 7, 2004 2:25 PM

CORBA IDL is IMHO separable from the language bindings, the point of the standard bindings only being that CORBA applications should be vendor-independent. If there was a binding for WSRF in JCP, I bet they would be using objects for resources, even though that's not strictly necessary.

I see the lower entry barrier mainly in the use of XML and in the readability of the core specs (stop hitting me with a printout of WSDL 2, please!), not in the tools. Many more people can create web services than CORBA services without the need to get a vendor's package.

Posted by: Jacek at April 7, 2004 2:43 PM

The XSD spec would work just as well (for hitting, that is ;-))

I agree that if the toolkit is taken out of the equation, you are right.

Posted by: Stefan Tilkov at April 7, 2004 2:49 PM

I know it's late, but ...

I'd say that the implementation of the operation isn't the important part. What's important is the shared expectation between client and server about what the request and therefore the response, means. With IDL, and as I'm hearing is still the case with WSDL, there is such a shared expectation. Jim, Savas, and myself argue that this is suboptimal (to be polite 8-).

Posted by: Mark Baker at April 20, 2004 7:25 PM

Mark,

I believe the shared expectation is always there, even if the web defers it to the human user and only leaves a very vague meaning for the methods. Wherever we want to automate some processes, the parties (automata) need to "know what to invoke and why", I'd say. That's where IDL is necessary.

Again, for human-oriented applications and for apps where the necessary semantics is limited (e.g. only cacheability information is necessary), the meaning communicated by the IDL will be limited, e.g. the operation POST adds the representation as a subordinate resource.

I still want to be able to create my interface in which the operation add adds two integers, for I still believe it's useful where intelligence isn't present.

Posted by: Jacek at April 21, 2004 5:09 PM

You're right that sometimes this is the case for human/machine interactions on the Web. For example when I enter my email address into a form and hit the submit button, it is done with the expectation that I will be subscribed. But that's not always the case, nor is it necessarily the case for automata.

Consider that what the Web encourages, even for machine to machine interaction, is for parties to put their expectations in essentially two forms; that you'll process a document at my request (POST), and that you'll give me a document when I ask for one (GET). It works, in practice, like this;

Agent A;
- listens via Rendezvous ...
- for some RDF which declares ...
- that there exists a resource of type CertainKindOfDataConsumer
- so it sends some to that resource via HTTP POST

while Agent B;
- comes on line
- takes inventory of its own capabilities
- announces those capabilities via RDF/Rendezvous
- one of those capabilities is a data processor of type CertainKindOfDataConsumer

Agent A and Agent B share no knowledge of one another, and in order to communicate, only need to know HTTP, URIs, RDF, Rendezvous, TCP/IP, and what a "CertainKindOfDataConsumer" is. So the only "shared expectation" is that provided by those standards, specifically where HTTP says that POST is a way for the client to request that the server process the data. Agent A may not know or care what Agent B will do with the data; all it needs to know is that B accepts the data for processing, which is what a successful response to an HTTP POST tells it.

Posted by: Mark Baker at April 21, 2004 6:02 PM

Blah, missed a line there. Regarding the form example, I meant that it was a form for subscribing to, say, a newsletter, and that I need only enter my email address to subscribe.

Posted by: Mark Baker at April 21, 2004 6:03 PM

Mark, I actually think this discussion is touching on a fundamental point - both for all of the REST stuff, as well as that strange SemWeb thing both of you are so fond of :-)

Taking the dependency - the shared expectation - out of the networking, communication, middleware layer (whatever you want to call it), just moves it up to another layer, IMO. It doesn't remove it altogether.

Posted by: Stefan Tilkov at April 21, 2004 10:58 PM

Yup, exactly Stefan, there's no escaping it. The Web/REST argument is that a single shared abstraction provides enormous(!!) benefits. To their credit, Web services are aiming for those exact same benefits (loose coupling, etc..), and doing it via the exchange of documents, but they just punt on the shared expectation problem.

Application protocols embody the notion of shared expectation, unlike transport protocols. Hence my focus on the transport vs. transfer and protocol-independence issues for the past few years.

Posted by: Mark Baker at April 22, 2004 3:29 AM