transparent distributed computing
If i want to build a centralised database its pretty simple. Which SQL RDBMS do I choose oracle, MySQl what?However if I want to have more than one physically seperate data store, suddenly my problems increase. Which location has a hold on which segements of the data. If I am selling cars at two locations, should the DB at location X hold the details for cars at location x?
There are lots of answers to such questions but there are no *correct* answers. Only compromises, and these compromises mean that the users cannot have a transparent system, that the UI must at some point reflect the distributed compromise made (perhaps only "I am sorry but I cannot sell you that car untill the sales person at location X stops trying to sell it to their customer")
The same applies to distributed Object systems.
Corba v Soap v XML-RPC. It does not really matter. CORBA has solved most of the stateful problems SOAP and WS-* services are wrestling with. But it has not (IMHO) and cannot solve the basic problem - if you are using serrvers in Texas, Lahore and london to complete the same transaction, the architecture, the exception handling, the design of that transaction *must* take into account possible network failure, location of data and so on.
Simply saying the message broker will ensure safe delivery does not count. Physical distribution punches holes right through the OSI layers and we must be mindful of that at the top layers.
If I can dream up better examples I will post them. Probably
posted by paul @ 5:37 PM
0 Comments:
Post a Comment
<< Home