Pages

Friday, November 30, 2007

Joseph Conrad

A wonderful article on Conrad in the Guardian, which contains this quote from the man:

"Fiction, at the point of development at which it has arrived, demands from the writer a spirit of scrupulous abnegation. The only legitimate basis of creative work lies in the courageous recognition of all the irreconcilable antagonisms that make our life so enigmatic, so burdensome, so fascinating, so dangerous - so full of hope."

An enlightened grade 10 teacher made us read Heart of Darkness - and it was way beyond us - yet how could we not feel the depth of his style, his circling of the story and the way the words were like ruminations of the subconscious. Re-read it several times since, and it never ceases to bring forth strong emotion. And this is not a sensual book, but almost a pure intellectual one - wrapped around a journey - a river trip.

And don't miss - in the same issue - an interview with Richard Ford.

Monday, November 26, 2007

More on automated interfaces

  • UNIX philosophy of universal read, write, create (sic), seek verbs is akin to financial transactions, where bytes are analogous to money
  • HTTP extended this with POST and made it stateless - so it becomes a client-server protocol (a good alternative to X-Windows by the way)
  • The universal currency is data, and it can contain anything, it can buy anything. Putting meaning to it is really the difficult part, and the notion of objects is really an attempt at creating a philosophy of data
  • Right now we have an inflation of data, too much currency, and its value is being balkanized, some currencies are more precious than others, security related ones, and maybe some video or music bytes. Copyright is an attempt at increasing the value of bytes through currency control.
  • So if an object defines the methods we can use to manipulate it, then one way to have objects communicate more easily (ideally automatically) is to constrain what objects can do to a machine manageable set. This may not be much of a constraint, only one that promotes efficiency through consistency.
  • Or we can take the idea behind types to heart and have a huge catalog of types and ensure that they can play together - real types which map to useful objects
  • For example, a user at any terminal could drop select from a list of things like ADDRESS CHANGE, VALIDATE ID, SUBMIT CLAIM, BUY, COMPLAIN, CHANGE FIELD, etc
  • This is the "naked object" philosophy taken one step further. No need for a graphical interface, just a nice "no error" interface - where all choices that work are shown. The "trie" of possibilities would reduce itself as transactions are chosen to interact, limiting the choices the more you decide
  • In short, modeling. Can this work in an ad-hoc world? Maybe the modeling should be automated through affinity and tuple-space approaches to ad-hoc property lists
  • This, coupled with a hierarchy of state machines (like game play AI) would go a long way to creating automated interface coupling.

Friday, November 23, 2007

That SOA thing


Here is the definition from an authoritative vendor-neutral body:

The World Wide Web Consortium’s glossary defines Service Oriented Architecture (SOA) as

"A set of components which can be invoked, and whose interface descriptions can be published and discovered"

Note that the definition does not talk about the type of transport, it is all about interface descriptions – Web services are therefore a subset.

As in all such interface standardization efforts discovering the service (semantics) is key.

How to make apps talk to each other meaningfully (semantics and syntax) without a human in the loop is a problem old as operating systems.

This has been and remains the “holy grail” of integration. Getting apps to talk across their boundaries has been a staple of data processing since I can remember.

We have had shared memory, files, networking, RPC, CORBA, and the now the latest idea is to re-use the Web servers connected to apps as Web services by parsing the HTML or XML to understand the context of the data across HTTP [We seem to be adding layer after layer of code to do this for some reason. Maybe with the hope of adding some sort of “intelligence”, maybe not…]. When we only use TCP/IP interfaces instead we generalize and call it SOA. This tells us that TCP/IP is now a commodity layer. It is all about commoditization moving up the stack.

In all cases we need to make the plug for the socket and make sure the voltages are OK; i.e. the syntax and semantics have to work across the boundary.

The Web has given us a new way to think about this.

Links – URI and URL’s

SOA is the idea that an app can “choose, click on, and follow a link” by itself to get a job done – and sometimes fill forms too.

There are 4 major verbs we can apply to URI’s and URL’s: GET (click), PUT (put up a resource), POST (fill-in a form mostly), and DELETE (get rid of a resource), plus a few more: This is HTTP. It is meant to stateless (except for cookies and URI-held sessions ….) because the state is supposed to be held by the user – and when the client becomes an app, that can complicate things greatly – all of a sudden you have servers talking to each other with state.

Still, we have not progressed to semantics at the app layer – this is transport and syntax.

We have always depended on humans (programmers, analysts and users). We have been doing this – imperfectly – first through command line, shell scripts, GUIs, and now Web pages and forms.

When you cut and paste, when you embed a table or a picture into a document and when you save a file to be retrieved by another app you are doing inter process communications. Windows and GUI’s allow us to do this more easily, with visuals– it may be their most obvious value proposition – the basis of the MS empire. The Web is similar, we press on links to hop among and between servers and apps.

Computers, on the other hand need to be rote taught. They can crawl web sites, but they have difficulty making them inter operate without humans writing the glue. Web 2.0 is about doing this more easily – “mashing up” service interfaces using XML and HTTP and the smarts of a browser scripting language – ECMAScript (JavaScript)

SOA ideals say that we can publish somewhat constrained specs that will allow machines to automatically selects forms and links and act on them, even when that they may never have seen before.

The more realistic approach is to say that we will need humans to guide the machines, but that the molding of sockets and plugs will get less onerous – we are attempting to standardize the interface syntax and restrict the semantics to a published, well managed, machine-discoverable set. In the interim, it helps us integrate stuff with less work.