WS-Misunderstood

Eric Newcomer writes in the SOA yahoo group...

Web services specifications are misunderstood and not implemented correctly. JAX-RPC is the kind of "poster child" for this.

Steve Burbeck and Multicellular Computing

Jon Udell has an interesting session with Steve Burbeck (who's only apparent career blemish appears to be the design of UDDI 8^).

[Update: Steve explains his role with UDDI in a comment on this post.]

Burbeck's history goes back to that Tektronix Smalltalk community here in Portland that spawned Ward Cunningham, Kent Beck, Rebecca Wirfs-Brock, Gemstone Smalltalk, Digitalk Smalltalk, etc. The work Cunningham, Burbeck, and others did at Wyatt with a Smalltalk-based trading system is a gold mine of ideas barely tapped, yet more relevant than most enterprisey systems built since.

Someone could write a book on Tek Labs and the direct and indirect influence it had not just in popularizing Smalltalk, but design patterns, agile programming, etc. It's reach is far and wide and largely unrecognized.

Back to Burbeck... the current references are to his work on multi-cellular computing. Apoptosis is an increasingly recorgnized pattern, e.g. from the Erlang community the idea that small components should give up quickly and allow a higher-order component handle the fault.

Stigmergy is interesting... it's not really found in Erlang, except I guess it is in a sense what the Mnesia distributed database is for. It's also a key aspect of the Linda tuple spaces / Javaspaces model, and the idea of "blackboards" in artificial intelligence.

Linux Fest Northwest incl. Tim Bray

Linux Fest Northwest is on April 29 in Bellingham, WA. That's a beautiful part of the state in the north Cascades not too far from Vancouver, BC. Admission is free.

I hope I can make it up there. Tim Bray is scheduled to talk on things non-enterprisey...

"XML, Open Source, Complexity, Simplicity"

There are a number of other interesting presentations scheduled.

WWW2007 in the Canadian Rockies

Mark Baker is helping with WWW2007, which will be held in Banff. I will what I can to be there. The Canadian Rockies is in the Top 5 of my favorite locations in North America and I could use any excuse to go back there.

Oh, I'm sure the conference will be interesting too.

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)

It's Enterprisey!

Overnight this new term and meme has taken hold. Would that I were not familiar precisely with that that it implies.

It's enterprisey!

Update:

Bill de hÓra writes in lesscode that the term now has among other things, a wikipedia entry, and a wonderfully animated architectural illustration with its own theme music.

Da-da-da-da-dadadadada! It's enterprisey!

Paul James on REST/HTTP

I don't think I've seen these before. Paul James has a number of useful REST articles on his site.

I believe heavily in developing web applications using the KISS principles of "less is more".

One Method Too Few or Too Many?

Ethan Fremen writes in a lesscode comment...

The main way in which the additional verbs are really helpful in an application is whenever you want to manipulate multiple resources at once. Of course, in most cases where you’re doing that, you’re using even more of those ‘useless’ verbs, like MKCOL and PROPFIND etc.

To me it’s like you’re arguing that the only methods anyone ever needs on a class are gettr and settr methods.

I don't think the comparison with an object-oriented programming language is helpful. Classes with only getters and setters are brittle in their context (very small amount of state that changes often, very closely located to collaborating objects within a single OS process, one or a few developers working together modify most of those classes, short release cycles).

On the other hand with a distributed system it may be that the more methods in a system the more brittle in that context (very large amount of state that does not change often, very remotely collaborating systems across multiple network boundaries, many developers who know little if anything of each other, long release cycles)

A mechanism to "manipulate multiple resources at once" in the latter, distributed HTTP context may be to construct a resource that represents the collection of resources and then manipulate *that* resource using the smaller number of verbs.

The hurdle I've mostly climbed over to the level I currently understand REST, HTTP, URIs, Atom, etc. is that this is not an object system. This is an application protocol (and architecture, formats, etc.) for distant collaboration. The challenge is to understand what are the conceptual pieces in this system and how to map ones needs into this system.

Most of the heavy computational lifting of those resources *does* take place in object systems (or functional or...) where there is a rich processing vocabulary. The distributed part is just about moving representations around in a coordinated fashion to enable the heavy compuational lifting at the appropriate time and place. The architecture for one is most likely not going to serve the characteristics of the other. The more they are considered distinct the better.

That said, I cannot clearly articulate when to create a new method except that the resistence to adopting that new method will be great so the time spent thinking about how to use the existing methods will more likely be the time well spent.

My second articulation would be to suggest that if you want to create a new method or two, then probably so do I and so do several others reading this. Before long we would be drowing in a sea of new methods. There may be a Cambrian Explosion of new collaborative techniques if we focus on how better to combine the pieces we already have. Inventing another nucleotide should be a very high bar.

Update:

In another lesscode comment Paul James confirms this approach...

You don’t need new verbs to manipulate multiple resources at once, you just need another resource that represents all the resources you want to manipulate together and to then manipulate that with your existing verbs.

TSSTTCPW

Good news for Java programmers seeking the simplest SOAP stack that could possibly work...

I am back implementing Alpine. This has no dynamic redeploy, no ease of use features, no Java1.4 support, no annotations. It's going to be so simple I will have it working before I fly off to the Alps for my ski trip

The Coming Breakage: Minimize Dependencies

Steve Loughran writes about old binaries running (or not) on the next version of the Windows OS...

Now, making old apps work bad may finally create incentive for people to upgrade their office suite, but it will also break every single IT-written win32 app out there. That's serious, and going to become and ongoing issue, I suspect.

Fortunately, there is a workaround. Don't write Win32 binaries. Code in Java, Python, Ruby, Squeak or other interpreted language, and trust the runtime to be signed by the time vista ships. You sneak past the security problem without having to go to any effort, and you avoid being at all dependent upon the OS and any more delays.

If you want to take advantage of some specific OS, framework, library, or whatever... why would you not code the independent 80% part, well, independently? Writing software to your advantage is always about minimizing unnecessary dependencies.

$100

Don Box has a couple of interesting posts on Microsoft's support for REST/HTTP. I don't know a whole lot about the products, but there's a long list.

He asks a good question: how would you dole out $100 in support of REST/HTTP within Microsoft. Since I cannot really address specifics within their current product line, I'd consider something like this:

• $25 toward furthering their current investments in open REST technology, e.g. Atom and APP support in various systems and frameworks.
• $25 toward open RESTful "push" technology, e.g. XMPP and mod_pubsub.
• $25 toward a RESTful coordination technology above HTTP per se. Something like Rogue Wave's defunct Ruple XML tuple space, but using REST/HTTP. Deliver this as a live service (i.e. like Amazon's S3 but with somewhat richer associative memory than just keys or URLs (a URL is just a key, right?)) as well as a framework that others can deliver on their own systems and customize.
• $25 for better treatment of dynamic languages at Microsoft. I believe REST/HTTP/XMPP/etc. are to distributed systems generally as dynamic languages are to programming languages generally. To be fully RESTful I think you have to be as simple as possible and fully dynamic. Doing this will stimulate more RESTful ideas within Microsoft. I know they have a number of Ruby programmers... turn that amp to eleven.

LAMP on a Grid

Mark Baker writes...

Finally, the Web's getting its due.

Ok, so who wants to break the news to the Grid folk? 8-)

The most interesting vendor at the Infoworld Executive SOA Forum last week was ActiveGrid, a LAMP-based grid for various purposes.

The Same Old Place

Or was that the old Same place? Nevertheless...

I'd sure like to understand this claim and prediction from Eric Newcomer of Iona...

Now with customers deciding on the approach independently of technology, the roles are reversing. Customers are starting to tell vendors what kind of technology they need by creating their SOA based designs independently of their technology decisions.

This strikes me as a very good trend, and appropriate for where we are in the evolution of the software industry, helping to lead us to a place of resolution for the current frustrations with enterprise software.

I see a lot of people putting blind faith in WS-* because the industry has told them to. But then the industry says WS-* interop is not ready and there is no standard for a full service bus, so you have to make an investment in a specific vendor.

Same old story from what I can see. Anyone that wants an agile enterprise can get it using technology that is ten years old or more. There is *no* need to invest in WS-* or an ESB. I think an ESB could be a good investment in some cases but not because of any promise of a "standards-based platform".

Software Development *Is* Program Transformation

Let's celebrate another post from Ralph Johnson...

I do not say that program development *should* be program transformation, I claim that it already is. Most work on software is after the first released version. The purpose of work on existing software is to transform it to the new version. Since almost all work on software is converting version N to version N+1, almost all work on software is program transformation...

I do not claim that program transformations are easy, or that they can be automated, or even that we can always understand them. I am claiming that thinking of software development as program transformation is likely to lead to improvements in how we develop software.

BS-Transfer?

Mark Baker writes...

I'm calling bullshit on WS-Transfer. Please join me.

Favorite SOA Observation

My favorite observation from Infoworld's Executive SOA Forum last Thursday came from The VP of Enterprise Architecture at Sony Pictures Entertainment. Pointing out that SOA is nothing new, he had first encountered the idea in Tandem's shared nothing messaging capability. (pdf)

The same observation was made by Alan Kay in the 1960's about the Burroughs B5000 and contributed to his invention of Smalltalk. And then there's Erlang and other shared nothing systems.

You wanna make fourteen dollars the hard way? (WAV)

-Rodney Dangerfield, Caddyshack

But Will It Be Compelling?

James Robertson makes an observation that will please my 13 year old (a dyed in the wool Nintendo fanatic)...

Sony's release dates for the PS3 are starting to look like the planning for Longhorn