Considering the scholarly argument that web services are not necessarily a better way of doing things over CORBA, it has become necessary to examine instances where WS is more suitable than CORBA and vice versa.
ADVANTAGES & DISADVANTAGES OF WEB SERVICE OVER CORBA
One area where WS is more suitable than CORBA is in message validation. During SOAP message validation, involved checks are much finer grained that those of CORBA’s IDL (Gokhale et al, 2002). Simply put, XML Schemas are more definitive and expressive than IDL especially in terms of identifying syntactic and semantic checks, which IDL cannot define.
Another advantage of WS over CORBA is that SOAP/HTTP client is easier realized than CORBA’s IIOP client (Jong, 2002). All that’s needed to be done in SOAP is pipe XML to port 80 and wait for reply. However in CORBA, ORB is not usually present on systems that want to use IIOP.
Furthermore, WS firewalls through HTTP’s ubiquity, allow inbound and outbound HTTP traffic, thereby making SOAP messages able to cross firewall boundaries. CORBA also through its Firewall Traversal specification allows requests to be routed through firewalls. This is however only supported through proprietary solutions and not by ORB vendors (Gokhale et al, 2002).
As an advantage over CORBA’s com¬plexity especially as regards its APIs, WS are simpler; in the case of RESTful WS, API is not even required. Lots of CORBA’s APIs are larger than needed; object adapter functionality for example, can be provided in about 30 lines but has additional 170 lines which only add compli¬cate program interactions with the CORBA runtime (Henning, 2006).
A demerit of WS over CORBA is that WS lack standard language mapping while CORBA defines strict language mappings between IDL and one’s choice of language. In WS, there is no single way to map program’s data model and objects to SOAP. CORBA on the other hand through its IDL, offers a platform and language independent interface (Jong, 2002; 4). This flaw of web service can be seen in the instance when one is to change from WS of one vendor to another’s; the rigor of rewriting the codes ensues because of the differences in the toolkit and API of the vendors.
Another demerit of using WS over CORBA is in the area of security. CORBA supports various security features including authentication, authorization, encryption, data integrity, delegation, non-repudiation and auditing (Chiarabini, 2004). WS technology stack on the other hand has no standardized security services except that SOAP exploits Internet technologies like SSL amongst others.
Another disadvantage of using WS over CORBA is that XML reduces system performance. XML is simple but consumes time and CPU memory when compared to CORBA’s alternative. This problem becomes worse when the XML documents have to travel across the network, it results in staggering performance, wasted memory and huge consumption of bandwidth (Jong, 2002). However, there are emerging XML parsing/indexing technologies, such as VTD-XML, that is aiming to address this issue of performance.
SUMMARY
From the foregoing, it can be deduced that WS is just a reinvention of the CORBA wheel. Amidst their advantages over CORBA, WS are yet to fully solve CORBA’s problems or overcome CORBA’s limitations. WS have matured and are maturing into a phase where application integration would be infinite and easier through standardization of API. Meanwhile, Web services and CORBA could be used interchangeable to achieve the same result(s) and there are situations where web services are better used over CORBA and vice versa.
