It is a historic fact that technologies which evolve are more often accepted than those that are revolutionary. Evolution has been the success story behind Microsoft's distributed architecture (DCA). It started with the simple Windows Ole model and has evolved through Com into the distributed Dcom model. It is still far simpler than Corba, but the only thing which has halted its progress is the dependence on Windows 2000. Distributed systems must leave the door open for inter-working of various platforms. A 'middleware' architecture is far superior if it is multi-platform, which is the key strength of Corba.
The arguments over the need for pure object models with inheritance and polymorphism, compared to the simpler component model, which only supports encapsulation, will rage for years. But before we commit to the distributed models of Corba or DCA, it is worth noting that remote procedure calls, with a thin client PC calling stored...
server-side procedures is simple, and has a lot going for it for some years yet. RPC mechanics need a connection to be established, and are not suited to complex systems in which components or objects can be distributed across multiple nodes.
Corba goes further, in using a broker to establish the location of components at run time, while DCA uses internet addressing mechanisms based on URL's. These models are thus more dynamic than the simpler RPC techniques, and can cater for situations in which resources are moved, added, or removed (load balancing for example). But while such systems are needed, there are an awful lot more that are simpler! In particular, the RPC model can be used to call the execution of procedures in legacy applications, without the complexity of adding Corba or DCA nodes.
XML has also added a degree of confusion. XML is only a mark-up language, and it is ideally suited to constructing self-defining messages from raw data. It is therefore of importance to any system which interchanges messages. Messages can contain data or commands or both, XML supporting the meta-data needed to create the flexibility of modern multi-discipline systems. XML then is simply the language to add meta-data to data messages, defined for specific applications by relevant schema.
The Java community is also defining standards which enable Java components to be distributed. Sun's RMI is a common technique in which a Java applet in a browser can invoke an object in another JVM. There is also (and obviously) strong support for Corba through IIOP, which enables a Java applet to invoke any Corba compliant object.
But now there is a new and very interesting initiative for distributed systems called the Simple Object Access Protocol (Soap). To quote, 'Soap is a lightweight protocol for exchange of information in a decentralised, distributed environment'. The accent is on lightweight and if history is repeated this is the key to a major acceptance of Soap. Soap uses XML to define messages, which have three basic parts:
l. An envelope which defines what is included and what to do with the message;
2. A set of encoding rules (schema) for application defined data, and;
3. A convention for representing remote procedure calls and responses.
The latter will enable programmers to interface with other systems, making Soap applicable to a very wide range of applications, both new and legacy.
A very surprising feature of Soap is that it derives from a Microsoft development (a big XML supporter), but the proposal, which I hope will become a standard, has been drawn up by a team which includes IBM and Lotus representation. According to reports, the IBM input is serious, and has been welcomed by Microsoft.
Soap is a message based protocol, but it supports either back-to-back messages or simple response protocols to exploit interactive applications, so that it could be married to both asynchronous and synchronous systems. The key feature of the Soap protocol is that it is independent of underlying protocols. The proposal document (http://static.userland.com/xm1RpcCom/soap/SOAPv11.htm) only defines bindings to HTTP, but the intention is obviously to bind it to MSMQ, MQSeries, and a host of RPC subsystems, probably including TP monitors such as Cics, MTS, and Tuxedo.
The simplicity of Soap is extremely attractive, and unlike DCA it is not tied into Windows 2000. Microsoft, and to a lesser extent IBM, deserve praise for such an aggressive and realistic solution to the needs of the bulk of simpler multi-disciple, multi-platform, distributed systems. I have a feeling Soap will be a major success.