Why SDO Implementations Should be Lightweight and Distributed
Tim Bray (famous for writing the XML specification and the first XML processor) has published an interesting article on grid technology that is maily focussed on Tim's specialist area of XML and Web technologies. One of the most interesting comments Tim makes is that:
Memory space and compute cycles are pretty cheap. Disk space is effectively free. Moving data around in large quantities is expensive.
So why what has this got to do with SDO implementations?
There are two architectural approaches to implementing a product based on SDO: the centralized platform approach or the lightweight/distributed approach.
The SDO Data Services Platform
The 'platorm approach' where there is a central SDO platform. This is the approach used by BEA's SDO product, the Aqualogic Data Services Platform. The central SDO server handles all incoming SDO requests and has multiple Data Access Services for multiple types of data. The benefit of this approach is that BEA's starting price is $20,000 per CPU, which is great for large enterprise size sales. A key drawback of the platform approach is that it means moving data in a network via a centralized hub. This is the same hub-and-spoke architecture that is used in traditional EAI products. If you have data at point A in the network and an application that needs to access that data in point B, the request needs to pass through the centralized data platform. That means moving a lot more data around the network, which Tim Bray has pointed out is very expensive.
The Lightweight and Distributed SDO
-'distributed approach' where the SDO implementation is lightweight and generally is highly focussed on the type of data is handled. This approach implies that you deploy the SDO implementations throughout the network beside the datasouce and application (if possible), or alternatively beside either the data source or application. There's no centralized SDO server and therefore no data traffic to third-party servers.
The Vendor Dilema
A problem with the centralized platform approach is that it becomes a performance bottleneck. Of course, you could distribute the centralized data services platform everywhere you need data access, but that's not lightweight (a larger deployment footprint, for example, will leave less memory available for the actual application, reducing overall performance) . Selling an entire platform rather than a lightweight component does have the advantage of generating lots of extra revenue for product vendors like CodeFutures. After all, it's always profitable to insist on a higher price because you sell functionality that is not going to be used.
PJ Murray
CodeFutures Software