Jabber and SOAP

I was just finding my way around the "new" blogger tools. Until now blogger could not upgrade my blog given all the old cruft I guess. That's been fixed and so I hope to find interesting features. I think it handles uploading better.

Aaaaaaaanyway.

I was poking around a big long list of drafts the new tool made easier to find. Then I went to my oldest posts and browsed around.

Here is one that is short and sweet from April 15, 2003...

A question: if you have Jabber, do you need SOAP?

That SOAP thing has really taken off since then, hasn't it.

Cruft

Steve Loughran notices there's some cruft in there...

On a related note, the JRE is full of unwanted legacy cruft like an inadequate CORBA runtime, AWT, etc. While something like an XML parser is ubiquitous and stable, choosing SOAP is itself a decision, and choosing Sun's SOAP stack over more popular alternatives is a serious decision. Hard coding Sun's client may seem like a good thing, but in fact just makes it that much harder to upgrade to JAX-WS 2.1

Whole Value

This piece on getters and setters by Allen Holub...

...is a reminder to use the Whole Value pattern if you have an object-oriented language.

Ward Cunningham observes...

I see people refuse to use the abstracting capability of their language and then say that objects don't really work that well. Grrrr.

PL/I

I saw this in the Programming Language News blog...

PL/I for GCC 0.0.14 has been released. It is a PL/I front-end for the GNU Compiler Collection.

I wonder who's using it for what. Which computers ran PL/I in the past? IBM had an implementation for mainframes. Maybe for other mid-range systems as well?

PL/I was the systems programming language for Data General's mini and supermini computers. That's where I used it. I understand this was not quite *all* of IBM's PL/I specification. The language is fairly large.

It is somewhat more attractive than COBOL from my limited experience with both languages. It was straightforwardly procedural and recursive, with a reasonable exception handling mechanism. I'm not sure why PL/I did not win out over COBOL, unless it was the shear momentum of COBOL before PL/I was ready.

Update

Doug Landauer adds some interesting history in the comments. I forgot about Gary Kildall and PL/M.

End

One More Thing

Dan Creswell writes...

the last thing to do is to extend the language

He's speaking about Java in particular but it could apply to all kinds of languages that were never intended for much extension.

Do you want extension? Use Lisp, or Ruby, or Smalltalk. They've proven themselves very well for extensions to one degree or another. Certainly Lisp.

Otherwise choose a reasonable language(s) and use them. Don't pile more stuff on them than they can bear.

Squeeze Box

Another piece on the squeezing of everything into a language and/or a runtime, neither of which were designed well enough to take them on. Keep trying, but this quickly is becoming such a very wrong path.

There's got to be a better way. In fact I know there is.

Just Because You Can

In a subsequent post to the one I mentioned below, Steve Loughran writes...

The only place SOAP survives is in the enterprise, because if you can control both ends of the conversation, you can use the same toolkit and eliminate interop. The key selling point of most SOAP stacks -reverse generation of WSDL from your classes- is actually viable in this context...

He goes on to provide his own hypothetical position statement if he were to attend the aforementioned "Oh Really?" conference...

1. How to provide a client programming model that accesses REST endpoints with the same ease of use as same-stack-SOAP-development?

2. How to integrate Atom feeds and APP into the enterprise as an alternate communications pattern; polling over posting?

3. What is the best programming paradigm for this. Ruby on Rails shows how a dynamic language with continuations and the ActiveRecord database binding makes server-side web development easy. What can we do with clients?

4. How to keep Web 2.0 style applications providing a back end 'service' architecture that meets the needs and business models of providers and consumers.

5. How best to transition legacy middleware -including SOAP systems- to the new world

So what is so great about #1 even within the enterprise? (I've not seen much evidence in a small number of data centers I've seen). There is always a community of IT people fascinated by shiny code generators. IDE support for SOAP is just that. There is no more "architecture" built around these code generators than the CASE tools of the past.

Still on #1, from what I've seen of the SOAP/WSDL approach to using HTTP is total ruin. HTTP is a dynamic, duck-typed approach to "messaging" (ok, "resource transfer" -- HTTP says some things about what's been transferred but that's independent of this point).

Figuring out how to place a code generator for a static language in between the HTTP client and server will likely just gum up the whole works. Better to figure out how to develop HTTP applications in various languages and libraries as simply and *dynamically* as possible.

Which leads to #2. There is a lot of room for HTTP and XMPP to develop in the enterprise. Meanwhile there are open source tools for using these and more API/language-centric tools for coordination/messaging in the enterprise. The real big key is to allow various parts of the enterprise to evolve independently. If the data center can generally be updated incrementally without unduly updating too many parts at once (unlikely from what I've seen), then incrementally moving HTTP and XMPP into the data center should not be such a big deal.

On the other hand if the data center is typical then there are all kinds of unnecessary dependencies preventing *anything* from evolving efficiently. This is the bigger problem that should be addressed first.

Number 3 is a doozy -- the browser has to come around to reality -- it is a *platform* for applications. Multiple, concurrent, independent, and secure applications. Unfortunately even under the best of conditions, the most modern browser is a half-assed piece of work. Coming to terms with that is crucial. Nothing proprietary though.

Dynamic coordination protocols still require contracts. They just aren't used for code generation. So #4 implies the need for contracts that support understanding and change, but clearly not WSDL that only pretends to be a contract.

Finally #5, the transition. See my response to #2. Ease of transition is the key any sort of data center sanity, which explains why the data center is so insane, nine times out of ten. Isolating crap like SOAP and ultimately removing it are steps toward sanity and successful transition.

The Oh Really? Conference: Or, I know a dead parrot when I see one

Steve Loughran lists some of the presentations at an upcoming "Web Services: Not Really. Oh Really?" conference. Look at the list.

The big SOAP boys are now admitting they f'd up big time.

Let's see how they try to make a dime off of HTTP and other really open and already proven and relatively simple technologies. Good luck with that.

That Sinking Feeling

Bill de hÓra writes about the umpteen billion dollars sunk into Vista...

more backseat driving - does anyone outside MSFT understand what it takes to get the OS done at all?

I don't think it is a matter of comprehending how difficult the work is. It is a matter of comprehending the value of doing that work. They are on the wrong track. There is little value in what they've done. The real losers will be those who will have no choice but to fork over big bucks to MSFT.

Far and away MSFT will recover its costs through "update-by-force" rather than "update-by-choice".

I would hate to have *that* as my customer base.

(Update: fixed broken link to Bill's post. Thanks James.)

None Too Soon

Don Box closely reflects my stance on JSON, Lisp, and XML...

JSON has actually eclipsed S-expressions for me as the most obvious way to structure data. JSON effectively gives into the lure of alists and commits to them in a pretty obvious way.

Also, in both JSON and S expressions, the concrete syntax is so trivial (and orthogonal to the model) that it doesn't really get in my way.

I can't say the same for XML.

Although he thinks more favorably about XML than I do. XML could not go away soon enough for me.

Surprisingly I do prefer JSON as an exchange format that Lisp (sexprs). For the reason Don gives above... it is very easy to see the alists and the arrays (true lists) in JSON than it is in Lisp.

So while I would dearly prefer to program in Lisp (Scheme) than any other language, I would want to exchange data via JSON.

Not a problem... in Common Lisp, Gambit Scheme, and several others, the neat thing to do is create the read-table syntax for JSON.

Late To The Table Again

Update:

The evidence this time has caused Microsoft to withdraw the patent over the last few days. The BlueJ Java people, who already credited Smalltalk, had been in recent contact with Microsoft prior to the application and were very upset about the patent application. Bad press was visibly having a negative affect.

Would that it were this way with the less direct instances of prior art. No kudos to Microsoft here -- this is a case of one's back to the wall and the spotlight shining down from the police helicopter -- you're about to be on a reality show.

End

James Robertson writes about another Microsoft patent application in the 21st century that consists of prior art from the 1990s if not earlier.

Here are some other candidates for prior art from what I can tell. (I can only read so much about Visual Studio and then I begin to lose my lunch.)

• The Smalltalk "diagramming debugger" is from the 1980s. Ironically the author, Ward Cunningham, worked for Microsoft for a few years.
• The Smalltalk "Object Explorer" is currently included as a goodie with VisualWorks Smalltalk I think. This is by Kent Beck and goes back to the same time frame when Ward and Kent were at Tektronix.

Maybe someone more at peace with Visual Studio can say whether these diagrams resemble what has been patented. (I am sure the newer tools have much more suckage.)

Diagramming Debugger

Object Explorer

Semantic Agnostics?

There's a comment over on James' blog stating a key part of the Microsoft patent may be it's "language semantics agnostic". Get over it. All the languages that can participate in this diagrammer have to share the dotnet object model and enough of the dotnet runtime to get the bits to the display. If that's not "semantics" then what is it? Well, it's actually pretty *bad* semantics to make all these languages use the same (pretty awful) object model.

Fighting The Good Fight

Fuzzy has a good idea: a site for bad software patents with the details, prior art, etc.