01/25/08 :: [SOA] Inter-action DLs and PLs [permalink]

Proceed to the next section if you don't want to read my quick update on the REST discussions (my usual rant on REST).

Tim did not provide any explanation to his post on WSDL. Not surprising but sad.

Bill Burke asked me to reconsider my comment on the "super-fluid" logic that Steve and Joe Gregorio applied to conclude that WSDL is bad. I have re-read their statements and unless I am mistaken (sounds a lot like the Obama / Clinton rhetoric) I have described their train of thought appropriately: (true) people do code generation with WSDL, (true) code generation is bad therefore WSDL is bad.

Fortunately there are great people in the REST community like Stu Charlton, Subbu Allamaraju, John Heintz or Teo Hui Ming (and I am sure many more) who genuinely are trying to create an understanding of how REST really works and make progress in the meantime. They are the crowd I would like to belong to. They are the league I wish I could play in. And I mean it. These people are really smart. They have an extensive knowledge and the right attitude. I am certain they, collectively, can turn REST in something even greater.

Here is Teo's response to my question on how to create an approval step in APP. Teo also provided a pointer to a great discussion based on yet another great series of posts on REST: Business Functions | the REST dialogs from Duncan Cragg. This series of post is a REAL attempt to explain how REST works. This is the best I have seen so far.

My favorite quote:

a resource can do any 'real functions' just by watching resource changes via GET or receiving resource data via POST on its URI and then mechanically transforming itself according to its internal rules - as defined by standard, convention or agreement.

Data operations are enough to enable much more than just data operations, as long as you have the internal transformation rules in place that animate the data in the face of current state.

so what's the point of using only data operations? That sounds a lot like invoking an action if you ask me except that your action signature is expressed as a combination of data schema and rules of invocations described somewhere in a document (otherwise you would not know what changing the value in a data field means). Semantically, what is the difference? Don't you think some smart-ass is going to create a framework that does code generation for that?

You will also appreciate the implementation of REST's event mechanism "by watching resource changes via a GET". I start to wonder who is the rebel and who is the evil empire.  Wouldn't there be an evil empire which aims to keep us in the maelstrom of poor & sloppy application semantics? If there was actually a programming model that would make the development of information system easy, wouldn't this evil empire loose all its power? That being said, I like Duncan's posts because he really talks about REST.

Sorry, just can't stop this discussion. Back to the topic of this post.

Inter-action Definition and Programming Languages

Mike Edwards wrote an introduction article on SCA which was published on InfoQ. I felt that this article was illustrating my point very well about inter-action definition languages and inter-action programming languages.

OO's interface definition mechanism (and pretty much all IDLs) are uni-directional. So how do you describe inter-actions with an OO language? well you use two interfaces as Mike explains. Here is his Purchase Order Request/Response definition:

public interface OrderService {
    public void placeOrder( OrderRequest oRequest );  
} 
public interface OrderCallback {
    public void placeOrderResponse( OrderResponse oResponse );
}

And here is the corresponding "port type" definition, yeap, you have to use both interfaces in the definition of your port type (service in SCA -just to confuse anyone):

<service name="OrderService">
         <interface.java interface="OrderService"
                                callbackinterface="OrderCallback"/>           
        <binding.ws/>
</service>

And Mike gives us the skeleton of the service implementation:

public void placeOrder( OrderRequest oRequest ) {
        // …do the work to process the order…
        // …which may take some time…

        // when ready to respond…

        OrderResponse theResponse = new OrderResponse();

        callbackReference.placeOrderResponse( theResponse );
    }

This implementation looks trivial, but in reality it is not. As Mike points out in his article we live in an asynchronous world. When you click the purchase button on your shopping cart you don't have a sub-second delivery, nobody is at your door ringing with the goods you just ordered. Basically, this Java skeleton is flawed. The order response will not be in general in the thread that processes the order request.

I feel that I am saying something really trivial, but in the light of the discussions with Steve Vinoski, the comments from Tim Bray on WSDL and the fact that Nick does not want to talk about the programming model as a factor in reusability, I feel that I have to say this:

  • WSDL is an inter-action definition language. It is not great, ok, it is broken (outbound bindings but SCA has fixed that), ok. Give me something better and I'll use it, but give me an inter-action definition language. No more callback insanity.
  • BPEL is an inter-action programming language. It is not great, ok. Give me something better and I'll use it.

The programming model that "some" will never let go is flawed, terribly flawed, tragically flawed. The very reason why "re-use" is not possible is simply because "things" that can be re-used "inter-act". They are not nicely layered in tiers that invoke one another but as peers that invoke each other.

The Client/Server model is deeply and totally artificial.  SCA is on a mission to fix that deeply and totally. It has still some progress to make, but it is on the right path. In particular, it enables the definition of inter-action interfaces from languages like Java and it allows you to use an Orchestration language such as BPEL from any language. This means that these programming languages don't need to be retrofitted to deal with either. This is a major step forward in the realm of computer science.

So, I am sorry, Steve, Tim and Nick, you don't think you see the elephant in the room. You are holding us back, way back. The future can be seen, if you decide to look...

|