Home page of John McDowall
Just had to comment - Orwell would have been so proud, what is next the RIAA suggesting that we need to reduce the price of CD players to eliminate file sharing?
A major source of complexity in implementing distributed systems today is in the persistence of data. The core of any system is the ability to process information and hence the need to persist information is key.
Unfortunately the majority of mechanisms to store and process data assume that they are the center of the universe and that moving the data in and out is not important, and hence should be done in bulk.
Even modern solutions such as XML Databases (at least the ones that I have worked with require reading all data into an in memory object and then storing). Many years ago I worked on a data analysis system that was based on the idea of infinite object streams - this made everyone think about what was the minimum object and design distributed processing objects naturally.
Short of writing a new stream based XML store myself,anyone got any ideas?
To follow up on my previous post about information services it is interesting to look at what creates value in a network based offering.
The value comes from four characteristics, producers of the data, consumers of the data, value of the data, and depth of processing.
The value of the users (producer and consumers) is dramatically increased if they are registered users and there is some form of tight coupling between them (think Google versus eBay). The value of the data is around how unique and how hard to reproduce/migrate to another service. Lastly the value of the processing of the data, companies such as SalesForce have built significant expertise in processing data for CRM which is hard to reproduce.
Applying this to a few real world examples. Google has a very low number of registered consumers, so has low value their, while the data it uses is also freely available, each individual piece has low value but they make it up in volume. Their processing of the data has very high value as they have built deep expertise and infrastructure around search. Another example is eBay here they have very strong ties to both consumers and producers which creates significant value. The value of the data is also very high as it is hard to reproduce (and they defend it from scraping etc) the value of the processing is somewhat lower.
I really believe in the service model on information processing but as I have tried to show it does need to be applied to the correct problems to create lasting value. Companies such as Google, eBay, SalesForce are creating lasting value by emphasizing different parts of the model.
David Temkin CTO at Laszlo has made the gutsy move to Open Source. The is the first rich client application that has a chance of widespread adoption and can change the way we deliver client applications
It has two significant features going for it (or soon will have apart from Open Source) that will enable its success. One is the upcoming serverless model, this is critical for scalability and ease of deployment. The second is the use of a plugin to deliver high quality rendering and features that are just not possible with other approaches using DHTML. Using Flash 6.0 plugin ensures that Laszlo applications will run in any browser and can take advantage of platform independent features that DHTML applications just cannot.
The last piece of the puzzle is making it Open Source, I can now recommend that we take full advantage of the platform and know that we do not have any major risk of the technology going away. I fully expect a strong and vibrant community to build around this new client delivery platform. I wish them every success.
Web Things, by Mark Baker responds to my comment about interfaces. While I agree with his next post around document interfaces I feel strongly that the formalism brought by WSDL allows the specification of public interfaces and requires little else. The public interfaces can be document or rpc style both have their place but the need to have a standard human/machine readable interface description is necessary.
I do however share his and others concerns that WS-xxxx is heading into the same pit of complexity that CORBA descended into. At the time of CORBAs brief hay day I was at Tibco (then Teknekron Software Systems) building loosely coupled self describing message based systems. The lack of interoperability and describable interfaces was a drawback - so we built our own dynamic object language, and our own security etc.... Standards are useful to ensure we all use compatible tools but the tools (standards) should not be over designed as the art is in the wielding of the tools not the tool itself.
While I have been a strong advocate for software as a service I have recently begun to modify my views. It is not software that is the driver but rather the information that is processed on behalf of the customer that is critical. Software is just a tool - if we processed the information faster, for less cost and more reliably using a slide rule no one would really care.
To do the job better as a service you need to build deep domain knowledge and continuously develop best practices based on customer involvement. This provides the economic model to make a service model work, not providing software.
As we move into this world software is going to become a non issue as it is becoming essentially free (or close to as a percentage of overall costs), it is now a well defined tool. The number of options for tools and platforms is large and the differences are shades of grey.
The real value of a service based model is going to come from those companies who build services to process information faster, cheaper, and more reliably by using the tools more effectively to process information not the builders of tools and platforms.
For the past several weeks I have had my head down coming up to speed on .Net and getting new customers up and running. The most interesting thing I have noticed about being heavily involved in real world large scale complex integration is how we naturally approach interfaces.
For most private interfaces we stay with XML Schemas and essentially REST style interfaces for simplicity and ease of development. For customer facing interfaces we always go with SOAP style web services for formalization of definition and reducing the impendance. If you communicate that your are exposing web services that comply with the WS-I basic profile it eliminates a lot of discussion. Similarly if we consume services that are defined the same way it reduces discussion.
Perhaps REST versus WS is really about private and public interfaces.
