When *Everything* Is An Object

James Robertson explains how "the control stack" is just an object in Smalltalk, and what you can do with that. This is what enables systems like Seaside to be so simple for the application developer. Seaside grabs stacks, saves them, applies them again later, etc.

Due Recognition

Jon Udell gets some due recognition. Jon is an observant and curious (in a good way!) person, qualities I admire.

I recently met Jon and several other Infoworld people at their SOA Forum in San Francisco. They were all a fun group of folks, and I was fortunate to have some time to talk with them about all kinds of things beyond the industry.

WS .LT. CORBA

Andrew Townley provides very good evidence that WS-* is significantly *worse* than CORBA. He explains that CORBA (eventually) realized they need to specify the end-to-end world from language-specific API to interface description to protocol...

CORBA is... relevant here because it took the position of defining its own, end-to-end world: an interoperability-focused transport protocol in IIOP, interoperable operation interface specification in IDL and interoperable programming API specifications in the various language bindings. In all, it covered a lot of ground and was quite ambitious. However, I think the people behind CORBA knew that they wouldn’t really have portable distributed objects without specifying all of these things...

Unfortunately, it didn’t work as well as was hoped.

The majority of Andrew's post exposes a huge gap in the WS-* approach by comparing WS-* based reliable messaging to the Java Message Service API for reliable messaging, as well as to CORBA as quoted above. Specifically, the differences boild down this way:

• JMS provides an API for Java only, but not a wire protocol. (Interoperability across JMS implementations typically done by bridging API calls from one implementation to another.)
• CORBA provides an API for various languages and a protocol.
• WS-* provides a protocol but not an API. Each vendor is free to give their customers whatever proprietary API they desire, locking you into their API along the way. Isolating these dependencies is up to you, but this is not a problem the vendors are overly concerned with, and certainly not something they need you to be aware of.

Andrew provides code examples in Java using different vendor APIs to implement the same protocol.

The... 3 examples are supposed to all accomplish the same thing: reliable delivery of a message from point A to B, or in WSA-speak: between a requester agent and a provider agent. However, if you were the one implementing the service, or in our case, a simple Messaging Bridge between JMS and something else (maybe another JMS implementation), your code is intrinsically tied to the vendor implementation. Change vendors, change your code. You’ve just inverted the JMS interoperability problem and have interoperability without compatibility rather than compatible interoperability.

OOPSLA 2006 in Portland

I have not attended an OOPSLA in five years. But this year the conference returns to its original 1986 location: Portland, Oregon. This will be the third OOPSLA in Portland.

OSCON and OOPSLA both in Portland this year.

The day before OOPSLA will be the Dynamic Languages Symposium. (via Steve Dekorte)