SOA vs. the Long Tail

Phil Windley on SOA.

Knowing about the financials process in some detail, I can attest that spreadsheets are involved in all aspects from forecasting to closing the books. Even when enterprise software is applied, there is a good bit of export to Excel, do the work, import to the enterprise systems.

Now, tie this in with recent efforts like Jotspot, Smallthought, and 37Signals, et al. where they are trying to address that "long tail" of software in a better way than Excel, Access, etc. (Note: in some cases incorporating Excel. Side note: all three of these efforts have embraced dynamic languages.)

This is where the big enterprise companies like SAP, Peoplesoft, etc. could focus some attention. Those of us working with these enterprise systems spend a lot of time at the interfaces of those systems with the rest of the enterprise. They do not support the "long tail" that exists within the enterprise, and moving to J2EE, Indigo, SOA, "portals", etc. is not addressing the *real* problem either.

We don't need a high-tech SOA as much as we need better "long tail" support. SOA is more for geeks than for enterprises. The enterprise vendor that figures out how to make SOA just a bunch of uninteresting plumbing underneath really good "long tail" support could end up a *big* winner.

Announcing json-py

Updates from the comments:

Ian Bicking suggests doctest would be more appropriate than unittest. I would have to agree, if I were enough of a Python programmer to know to use doctest. Each unit test is a couple of lines long, so I should move them to doctests with little trouble.

Eric Thompson wonders about support for tuples. The JSON array syntax looks like Python's list syntax, so I chose read to produce lists. JSON only has "objects" (dictionaries) and "arrays" (could be lists or tuples) for data structures. The write function could accept either lists or tuples and produce JSON arrays. Currently only lists are implemented. I'm open to suggestions.

End Update

I wrote a JSON reader and writer in Python over the last few days. Today sourceforge approved and created the project, and the files are ready for download.

It's "pure" Python 2.4 and has no other dependencies. Most of JSON is implemented, which is not much, coming in at about 200 LOC. The missing piece is the \uXXXX notation for hex Unicode characters. There's probably some missing functionality in the writer, e.g. writing escaped characters correctly, because I've mostly needed the reader so far.

There's one other Python implementation I know of and I think this new one is a good bit more correct and complete. There are 40 some unit tests, just enough to get my needs met. They do not exhaustively stress the specification yet.

There are several implementations in other languages. JSON can be used in AJAX-based systems in lieu of XML. In my case I've been using JSON for simple, yet expressive, configuration files. (I had set out to use YAML. Although simpler than XML it is still a good bit more complex than JSON.)

[Update: Jeremy Kemper points out in a comment that JSON is a subset of YAML. I think it is a sweet spot.]

Not as feature-rich as XML, I think the intent is to keep JSON per se as simple as it is, and layer conventions using JSON itself to represent more complex information (datetime, location, customer, etc.) and "metadata" (version, author, etc.). Don't let the "O" in JSON throw you. An "Object" in JSON is simply a dictionary in Python (and Map in Java), i.e. a set of name/value pairs.

https://sourceforge.net/projects/json-py

The Architecture of the Mobius Strip

Phil Windley and Don Box are wondering about levels of indirection. But are "levels" the best metaphor for where we are in networking today?

"the costs and benefits of indirection layers are well understood"

Generally I agree we can say there are costs *and* benefits, and we know what to look for in terms of "coupling loosely" and measuring impacts.

But in this case is SOAP *another* level of indirection vs. HTTP or just an *alternate* level of indirection? i.e. should we perhaps expect HTTP in more places than we have it today if we look at HTTP as an application protocol rather than a transport protocol?

For example, consider the Java peer-to-peer sockets project. Any application protocol implemented using sockets can run on some peer-to-peer topology. We seem to be in a world that is more like a mobius strip than the expected seven-layer model!

Is HTTP itself a level of indirection, and is it sufficent for machine-machine coordination on the web? If so, then the cost of SOAP (and so some or all of WS-*) as another level of indirection may have a cost that is too high, actually unnecessary.

More Evidence of Sanity in the World

Spain: Gay Marriage Will Soon Be Authorized
Le Nouvel Observateur

Wednesday 21 April 2005

The Congress has adopted a proposed law authorizing marriage between persons of the same sex as well as adoption. Senators are also expected to give their approval. It is anticipated that the law will be implemented this summer.

Symposium on Dynamic Languages

In conjunction with OOPSLA...

ACM Symposium on Dynamic Languages
October 18, 2005, San Diego, California

The goal of this symposium is to provide a highly visible, international forum for researchers working on dynamic features and languages. We explicitly invite submissions from all kinds of paradigms (object-oriented, functional, logic, ...), as can be seen from the structure of the program committee.

More steam.

Angles

Ryan Dawson ponders Tiger and Longhorn...

Business is consistently coded in angle brackets--where platforms don't matter... we need people who find the real problems... How many times have you read the Clue Train Manifesto?

AJAX + CANVAS = Good enough?

Apparently Mozilla (and so Firefox) are getting the element (similar to Safari) and adopted by WHATWG (and so Opera). Whence IE?

(Via Sam Ruby)

Web Algebra

Murray Spork writes in a comment on Bill de hÓra's blog...

I've been saying for a while now that what the Semantic Web needs is more algebra and less logic. - for example the "additive" and "subtractive" qualities of RDF that Bill talks about.