CORBA vs Web Services
Comparing Web services with Middleware on the whole
A significant difference is however that webservices aim at preventing incompatibilites of different application only. This is an advantage substaintiated by the application and platform independent nature of web services.Distributed systems utilize middleware services for communication, coordination, control transactional support, presentation management, information management, computation and system management. Additionally, middleware ensures reliability, scalabiltiy and performance to enterprise system. It also provides high-level primitives and thus hides the lower-level primitites of network operating systems and makes distributed systems design much easier and faster. In this respect, middleware services successfully tackle these problems; the Web Services on the other hand, have a long way to go, in order to reach the same success. Their future development should aimed at maintain the consensus among different applications, so that incompatibilites between implementations are avoided, and to leverage and support extensively existing concepts and technologies like middleware.
Comparing Web services with CORBA
Web services are currently used for simple interactions but this is about to change enabling creation of complex web services this might have already changed since the resources were written. The programming model for Web services will be vastly simplified relative to CORBA.CORBA is a true object oriented component framework, in web services there is no notion of objects they are centered around a message passing paradigm. Moreover in CORBA the interaction between client and server can be done directly with no need for further intermediation. The client obtains a handle to a corba object and applies a method on it, the result of the call is possibly another CORBA object on which it can apply another methods. In web services everything is decoupled. The client sends a message and receives a message: the response does not give an immediate access to the next step.CORBA use optimized connection oriented communications protocols that are either language specific or have detailed rules defining how data structers and interfaces should be realized. In contrast, Web Services are based on the technologies that have grown up to support www services. Communications use HTTP. HTTP is universally supported and HTTP traffic can normally pass through firewalls.
Semantics and security
To assure data consistency, the infrastructure should provide semantics that guarantee against multiple executions of the same client request on the server. While CORBA ORBs are required to provide at most once semantics, in Web Services the message semantics are defined by the protocol underlying SOAP CORBA applications can obtain the desired scalability and reliability by combining the Portable object adapter(POA) policies with the Fault-tolerant CORBA features and the Load-balancing CORBA service. In web services these issues are left to the components. For example an application server like IBM's WebSphere implements its own mechanism to handle scalability and reliability. This can sometimes be favourable as its easy to define the extend of reliability and scalablity needed by an application.CORBA security service supports a wide variety such as encryption, authentication, delegation, auditing etc. Web Services do not provide any standardized security services, although some aspects of security can be dealt with at transport protocol level. In particular, SOAP does not specify any security feature but rather makes it possible to exploit Internet technologies such as XML-Signatures or SSL to achieve maximum interoperability. In this aspect it is better to use CORBA as security services are a necessasity and it is easier to use the ones implemented.
Serializability and Thin CLient
Serializability impacts various issues such as persistence, performance, extensibility and ease of interoperation with other frameworks. The CORBA objects-by-value specification provides a language-independent equivalent of Java language's serializable functionality. The valuetypes specifination enables features such as reverse Java-to-IDL mapping that allows Java RMI to interoperate as CORBA objects; and the XML/Value mapping that allows XML documents to be represented as native CORBA types. Web services on the other hand allows for user-defined serialization mechanisms. The built-in SOAP encoding is XML-based and provides some advanced features like sparse arrays to reduce transport costs. With wireless web millions of users will be able to communicate with each other with services. These users carry thin clients with limited memory and computing power.CORBA imposes an all- or -nothing approach. An thin client willing to speak CORBA will have to support the ORB libraries. SOAP on the other hand does not require much. The contract is to be able to send and receive SOAP messages. In some cases one can imagine that the parser is fine-tuned to support only the kind of messages specific to the application.
Conclusion
CORBA value lies in CORBA services, platform and language independence, interoperability and they are more mature. Web Services is an emerging technology it was only invented two years ago. Web services wants to replace CORBA but represents a limited subset of what CORBA already offers today. It currently has no support for transaction, persistence, security, load-balancing. But we cannot be sure about how developed web services are since our sources would have been printed at different times and both CORBA and Web Services would have added functionality which are unaware off. On the whole we see that web services and CORBA are complementary. Web services are capable of combining existing middleware technologies into internet accessible service-oriented business services. So that the problems that cannot be solved by neither can be solved together by both.