The evolution of loosely coupled systems

As always Joel Spolsky makes very good points in Joel on Software - How Microsoft Lost the API War but I think he missed a couple of critical issues in the "war" between the two forces within Microsoft (The Raymond Chen Camp (Win32) and the MSDN Magazine Camp (DLL Hell).

While I admire and respect the efforts that the WIN32 camp go to making everything backwards compatible, we as users of current systems are cursed with an overly complex system that is hard to evolve as its roots go back 20+ years. On the other hand the MSDN Camp believes that the evolution can be through shared libraries and that applications should share code and evolve through DLL's. As DLL's were not implemented well for evolution (VMS and UNIX did a lot better job even before Windows), we are stuck with an incompatible mess. From these two approaches one can see the evolutionary branching of tightly and loosely coupled architectures. The tightly coupled WIN32 approach is made to work through shear hard work, as Joel notes in his article the enormous lengths the Win32 team go to for backwards compatibility, any other company would go bankrupt from this level of effort. On the otherhand because the MSDN Camp does not have strong versioning and hence cannot provide developers a stable platform we have a loosely coupled mess.

As Joel goes on to point out this battle is really over and most of us have moved on. Whether you use, Java, Python, .Net (including Mono) we are getting further from the operating system, when I move Java code from Windows to Linux it typically runs unchanged providing I have set the properties files correctly and a few other details, the same is true for most other high level languages. The next challenge is as we move beyond loose coupling through DLL's and Shared Libraries to services defined in the network we do not repeat DLL Hell and ensure that we can version and reuse services through shared infrastructure. As more shared services run in the network the platform they run on will be all but irrelevant to the users of the services. What will be relevant will be availability, functionality and responsiveness.

What will be relevant will be the client technology, currently the ability to deliver web interfaces using DHTML is state of the art, but it is not progressing, and is too complex. Other, better solutions are starting to appear that are leap-frogging the current browser technologies, they still use the browser as an HTTP pipe but that is all. They are in the desktop but require a minimum from the desktop and are easy to develop and deploy. Solutions like XUL, DreamFactory, Flex, Avalon are going to be where the next war for control is going to be fought. As these solutions are completely decoupled from the backend services there will be a completely new loosely coupled development approach but we should remember the lessons from DLL Hell and consider how to version and evolve service interfaces

New look

Seemed time for a new look and to use bloglines for my blogroll. It is interesting that one of the most significant impacts of blogs is the ability to create web sites that have new content without a huge investment in infrastructure and people. Truely putting the web in the hands of the people.

Service Ecology

A part of the issue around boot strapping SOA and web services is the need for an ecology of services to exist.

Without the ecology in place it is hard to create solutions. Some markets are starting to get critical mass and they will take off first.

Change is good

I do not usually post about personal events in my blog but there are exceptions. I have decided to leave Grand Central and take some time off. I am still going to be onthe advisory board and I still believe strongly in the vision of the company and I am very bullish on the prospects for the company.

Hopefully I can get back to blogging regularly and work on some personal projects and think about what is next. I think we are in new period of innovation and creation and I looking forward to building on the new world of software as a service.

Strongly typed message properties and weakly typed messages

Having used both REST style programming and SOAP I see that the difference is how the semantics of the message properties (metadata?) are specified. The ability to specify strongly typed message properties in a well defined and standard format (WSDL) is what separates REST from web services for me. If I am working in a closed community with a high degree of communication and a low rate of change in messaging semantics then REST is fine. However if you are working in a network that participants that are changing independently and there is a poor communication (i.e. people in different organizations that do not even know each other) then web services provides the common framework to express your messaging semantics.

As an example this is a link to POST WSDL for Grand Central that I created. Looking at the WSDL is can be seen that the headers are strongly typed while the message body is a simple XSD:ANY. This allows a user to post any message to Grand Central and route it to its destination using nothing more that the message properties. It is optional to add a strongly typed message.

This approach allows significant extensions through adding more message headers, the second example is STORE WSDL. This example takes an arbitrary message and either stores it in an XML Store or queries the XML Store with XPath gets the results. The only major changes to the wsdl are a new header addressed to the XMLStore service and a new destination. While I freely admit that the WSDL needs some work and some better comments the intent is fairly clear, and with come TLC could be very clear and obvious. As in both cases the message is a XSD;ANY there is a high degree of loose coupling as neither the recipient or sender needs to have apriori knowledge (if they want they can) but the semantics of the message delivery are still well defined. The Grand Central POST Header is an early version of WS-Addressing and WS-ReliableMessaging, and WS-Security is also supported, therefore the message properties are very strongly typed and defined in a way that everyone can read and more importantly understand. This is not possible in REST systems.

To create loosely coupled systems we need to be able to interact at the messaging level and specify the shared semantics as tightly as possible while keeping the business interactions as loosely coupled as possible. Used properly Web Services does this.