I'm happy to report that last week in Montreal the OMG Technical Committee voted to issue the CORBA binding for WSDL RFP. This RFP calls for submissions that propose a standard way of expressing connectivity to CORBA objects for WSDL-based applications.
On a related note, Savas responded to my previous posting regarding a CORBA binding for WSDL. He makes some good points -- at least from an architecture point of view. Let me try to address each of his points.
- "In object-orientation we have objects and that suggests, to me at least, that we have state (even if we don’t see it), an interface to that state, and a reference to that state." Well, distributed objects do not imply state any more than distributed services do. I've seen plenty of stateless distributed objects in my time. An IDL interface is no more an interface to state than HTTP verbs are. And references to state? A reference to a distributed object is no more guaranteed to be a reference to state than a URI is. I must be missing something here.
- "It is my belief, though, that object-orientation (please note that I am separating the architecture from the implementation technologies and I am concentrating on the former) is not the best model for building internet-scale applications." I wouldn't argue with that. In fact, I don't believe anything I've said or written in the recent past even implies anything to the contrary. Either way, a CORBA binding for WSDL has nothing to do with this.
- "I am not an expert in CORBA so I am ready to be corrected from heavyweights like Steve but I thought that CORBA encourages an architecture that is object-oriented in nature. It encourages the creation of distributed applications where the abstractions are the objects and the way of 'communication' is the method invocation (again, I am talking about architecture abstractions and not implementation details)." True, but somewhat immaterial. CORBA method invocation is largely a programming language abstraction that allows people to write objects and applications in a syntax with which they're comfortable. On the wire, it's some headers, a target identifier, and data that's passed to the thing processing the request. That's why I talked about CORBA object "virtualness" in my last posting. But I'm not sure what Savas's point here has to do with a CORBA binding for WSDL. The fact that CORBA runs a lot of mission-critical systems out there that aren't going away anytime soon, and the fact that, for business purposes and to achieve return on investment, those systems have to be integrated with non-CORBA systems, is why creating a CORBA binding for WSDL is a good idea. Trying to analyze whether the existence of a standard CORBA binding for WSDL somehow mars or destroys some utopian uniform architecture seems like a waste of time.
- "I have no problem with describing message exchanges using WSDL and then binding those message exchanges to various underlying transports or other distributed objects technologies." Excellent! Because that's precisely what this RFP is about -- nothing more, nothing less.
- "What I am afraid of is how such bindings are going to be (mis)used when building systems that directly expose their implementation details because that will be the easy thing to do." To which I say: who cares? Try your best to prevent such misuse, and I guarantee you that someone somewhere will find a way around it and use it to create a mess. I've seen blatant disasters created in every technology I've ever worked with. No amount of worrying about architectural purity will fix this.
- "Is there anyone who doesn’t see tools emerging which will be generating CORBA objects stubs in Java from WSDL documents?" Sorry, but such tools already exist. FWIW, though, the RFP explicitly states that generating CORBA artifacts from WSDL is explicitly out of scope.
Architectural purity was not on my mind as I pushed the RFP through the OMG. Rather, I knew that CORBA bindings for WSDL have already been proven in practice to facilitate the integration of CORBA systems with other systems. From what I've seen and experienced, doing it this way works better than other approaches I've tried or seen others try.