Lambda the Ultimate

While the problem as Sjoerd describes it may be real, it is definitely solvable. As an example COM Automation supports calling methods in a typed interface from untyped script (provided the types are from a certain limited set.)

I think the main problem is the inverse: the generation of the WSDL. The WSDL syntax is just to complex for manual generation (at least for projects of any consequence.) Even if you did do it that way, you would risk generating inconsistencies as your project evolves. WSDL is designed to be generated automatically, which is easy if your language/environment supports reflection. But since WSDL is typed, your source code must also be in a typed language.

Taking it even farther, WSDL espouses a model where the services are static: they are fully described at build-time. Scripting environments propose a more dynamic model.

As to XML-RPC and SOAP vs. CORBA (or DCOM), I think the proponents have two main arguments:

1. XML vs. binary - XML provides better interoperability than a (proprietary) binary representation. While you may argue the technicalities, you can't argue the fact the SOAP is the very model that may actually work well with Java, UNIX and Windows (.NET)
2. HTTP based - I sat at a presentation given by Don Box (great speaker BTW) where he basically said: IS is out the get the developers (because we make more money). IS only lets pron through the Firewalls, not stuff like RPC packets. So we must make our RPC look like porn.

Let's say I have a python method dosomething(aString, aNumber). You have to explicity cast types in Python (unlike Perl?). So if aString is "3" and aNumber is 4, I can't add the two without casting the type of one of them.

Once both operands are the same type then addition or concatenation is done as appropriate.

But there's no way to tell, just from the function definition, if the types are going to be treated as strings, numbers, or any of a bajillion types of objects.

And there would only be one combination of acceptable types (String,Integer) in the general case. If the function itself did something like aString = str(aString) internally then many more types would be passable for the first argument... but again there's no way to tell whats going on inside the function without a lot of awful analysis of the actual bytecodes.

With the newer versions of Python it's probably possible to store argument type information in function attributes, but there isn't any agreed upon way to do this, so I don't think it helps yet with the WDSL problem.

Yeah. I kind of figured these are the main points, and explained them. The response was "Well, CORBA can do more, right?"

CORBA is great if you have complete control over the specifications of the application's end-points and medium. Indeed in such a homogenous scenario CORBA is superior to SOAP (or XML-RPC) because of its tried and tested infrastructure and the performance benefits that a binary specification has over a textual one. If, on the other hand, you are dealing with a heterogeneous environment where you have little or no control over the end-points and medium (this being more-or-less the definition of a web service), CORBA (or DCOM or RMI) is out of the question.

Despite having been around for several years, with several vendors providing ORB implementations, CORBA has failed to garner a large following. While DCOM and RMI are newer specifications, I believe there are more applications using them than CORBA (note I'm saying "more", not bigger or better.) And in the short time it has been around SOAP has generated more furor than all three combined (though I'm still waiting to see some truly useful SOAP-based web services ;)

I do think SOAP has a good chance for success, WSDL limitations notwithstanding, as it is supported (actively) by Microsoft, IBM and Sun and by various development communities (Perl, Python).

Notice that I wasn't really asking about all this (though the discussion turned out to be interesting). I was asking if anyone knows of a good summary. Something to explains all the important points that were raised here (text vs. binary, homo/heterogenous, granularity etc.)

BTW, the "first language debate" is very important for CS educators. It is not really a language issue. The question is what you want students to know after taking the course. Since CS is a young discipline you tend to want them to know a bit of everything, instead of teaching them a unifying approach. Why? Because there is little agrreement on what such an approach means.

For example, I like the idea of teach how to reason about algorithms, equational reasoning and other proof techniques. Other want students to know about objects, while other want them to be able to program little programs and that's about it. In practice it is hard to achieve all of these, and indeed admirers of one approach usually find the other approaches completely inappropriate. (Yes! I don't think OOP as such is so great in the first semester).

(I agree that the Oz/Mozert work is worth checking out for anyone interested in this stuff. It was disucssed here a few times).

The problem, however, is that if you don't have control over both ends, the software can become brittle in unexpected ways. As a provider, you end up having no control over the other end of the wire - meaning you don't know the dependencies between you data structures (XML) and the behavior (RPC) that you are authoring and the software that is using these loosely coupled object mechanisms. You have two solutions - either keep the same protocols and get locked into a non-optimized solution. Or change the protocols and risk breaking everyone elses software.

I do think that text based RPC gives one a bit of freedom in not having to recompile and redistribute the IDC at each and every software release. But the idea that this results in getting rid of problems associated with coupling is a bit optimistic.

Quick poll: How many LtU readers are actually using SOAP/XM-RPC etc. in the real world?

http://pobox.com/~oleg/ftp/Scheme/Request-Language.html http://zowie.metnet.navy.mil/~spawar/JMV-TNG/Request-Lang.html

An article "Speaking HTTP" http://www.usenix.org/publications/login/2000-4/features/speaking.html

argues that HTTP by itself is a flexible remote procedure call protocol. The functionality provided by a SOAP envelope seems rather redundant then.