46,213,000,000.00 things to fix

This is classic ongoing · $46,213,000,000.00. Several years ago evaluating a J2EE servers I found this to be so true, downloading, installing and running test program for JBoss - under 10 minutes. While WebSphere the download was 14 times as big and getting running was days (i.e. call IGS). Is WebSphere so much more capable than JBoss - I doubt it and given IBM's recent purchase of GlueCode they might have seen some of the light.

Dissolving boundaries - inside and outside

Phil Wainwright comments on dissolving boundaries Loosely Coupled | Dissolving boundaries | May 6th 2005 2:12pm. I think we need to make a clear differentiation between inside and outside boundaries.

Inside the enterprise the CIO has some degree of the framework between the silos and can manage the necessary change to define the fabric to achieve loosely coupled services architecture.

Outside the enterprise the CIO has little control (but has economic power) of the fabric. Here though is where there are compelling economic benefits for a CIO to use external services (see: Why Integration as a service?) or consider the economics of Salesforce versus Siebel. The long term winners here are going to be the providers of business services that destroy the previous economic models. The tools vendors need to change their POV from being the center of the universe (or single religion) and become enablers of wide scale service integration that provide dramatic economic benefits to the enterprise.

Resedel - Updated

John Cowan's entry into service definition language Recycled Knowledge: Resedel. Looks good I think as I am better with Schema than RelaxNG. (Update - thanks to trang here is a XML-Schema version of Resedel resedel.xsd)

Biggest question is why translate HTTP-GET et al explicitly into CRUD - expose the URL verb, another layer of abstraction can be confusing.

Service Descriptions - Just the docs?

Couple of interesting posts: Dare Obasanjo aka Carnage4Life - On Replacing WSDL with Something Simpler and Mark Baker- ongoing - SMEX-D.

Both make the point that having an interface language for services should not do very much. From my POV I want primarily a means of getting accurate documentation on the interface (and also providing it to consumers of services). For all its warts Javadoc was a great step forward as it provided a way for developers to provide documentation will minimal effort. Until Javadoc the best examples of standard docs that I had experienced had been man pages, and some Lisp environments.

For services to be propagated widely there is a need to provide documentation that is easily created and kept up to date. Perhaps this is the starting point for a service description?