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.
"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.
Thursday, April 06, 2006
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.
Tuesday, April 04, 2006
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...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:
Unfortunately, it didn’t work as well as was hoped.
- 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.
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.
Monday, April 03, 2006
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.
- ► 2011 (19)
- ► 2009 (40)
- ► 2008 (402)
- ► 2007 (388)
- ▼ 04/02 - 04/09 (4)
- ► 2005 (335)
- ► 2004 (534)
- ► 2003 (286)
- Patrick Logan
- Portland, Oregon, United States
- I'm usually writing from my favorite location on the planet, the pacific northwest of the u.s. I write for myself only and unless otherwise specified my posts here should not be taken as representing an official position of my employer. Contact me at my gee mail account, username patrickdlogan.