During the past decade, distributed computing has become an important means of maintaining interoperability among increasingly decentralised computing resources. But the disparate nature of the OSes, networks, and programming languages at play has turned distributed computing into a costly game of overcoming complex interoperability issues.
RPCs (Remote Procedure Calls) are now the most common means for communication within distributed systems; but the options for distributing the application pieces across multitiered, component-based architectures remain limited.
But times, they are a changin'. The Internet has infused distributed computing with new potential and has shackled it with new requirements as yesterday's business applications ramp up to be tomorrow's Web services.
Microsoft's .Net, underpinned by SOAP (Simple Object Access Protocol), is bubbling with the potential to ease RPC implementations and to pave the fast track to interoperability.
The Object Management Group's (OMG's) Corba has been the recognised standard in middleware interoperability for enterprise-scale distributed computing environments, particularly on Unix platforms and proprietary mainframes.
Although the OMG did a good job maintaining the promise of Corba during the past few years, it is now under the gun to assimilate more recent standards. Meanwhile, customers are left wondering whether SOAP portends the demise of Corba as a viable distributed computing model for the enterprise.
But comparing Corba to SOAP is a bit like comparing apples to oranges. Unlike SOAP, Corba is not a markup language; rather, Corba serves as a go-between, facilitating the connection between distributed, object-oriented applications and enabling communication regardless of the platforms on which the applications reside.
For large-scale enterprise projects, in which managing complexity and ensuring reliability are major concerns, Corba offers a solid, comprehensive development platform and ensures top-notch transaction rates and fail-over capabilities.
All that power comes with additional overhead. Corba is notoriously difficult to develop and deploy. Depending on the size and scope of the project, using Corba can be overkill; for smaller projects, the additional costs and effort Corba requires for code development often don't outweigh its performance benefits.
Although Corba provides great functionality, it requires opening network connections to transmit data, which presents a security problem for the corporate firewall. In contrast, SOAP provides a simple solution for making RPCs via HTTP that circumvents firewall security issues and makes data readily available.
Microsoft cleans up
SOAP has become an integral component of Microsoft's .Net strategy, enabling COM+ components to communicate competitively with Corba and Java standards.
With the release of the XML-centric BizTalk Server 2000, Microsoft began to fill a hole in its business-to-business line of products by bridging platform boundaries. By deploying SOAP in products such as BizTalk Server, Microsoft has achieved a level of interoperability that takes the wind out of Corba's sails. The move also allows Microsoft shops to hoist anchor because SOAP is not limited to Windows, Java, or enterprise-only environments.
Microsoft's .Net technology also makes it easy for developers to make use of SOAP interfaces. Any Visual Basic developer can expose application objects over the Internet without becoming an XML/SOAP expert.
On the downside, unlike distributed object architectures such as Corba, SOAP is a wire protocol. SOAP lacks the activation elements, security, and state management that Corba provides, and it does not alleviate the need for additional middleware.
Although SOAP offers the benefits of simplicity, it does so at a cost: The XML data inside the SOAP envelope must be extracted and parsed, thereby degrading performance. And in comparison to Corba's binary data, SOAP's text-based messages consume significantly more bandwidth in transit. Unlike the relatively stable standards behind Corba, SOAP and XML are still evolving, with the World Wide Web Consortium still in the process of cementing the standards. Early adopters could find themselves reworking development initiatives to bring SOAP and XML components up to code.
Up to the challenge
Corba is far from being wiped off the developer's road map. The OMG has taken important steps to ensure compatibility between Corba and budding communication protocols. As a result, there are a number of bridges, including open-source projects, capable of translating SOAP requests into Corba invocations.
In the field of Web services, Corba may even provide a temporary advantage with language bindings and service APIs already in place. Corba's IDL (Interface Definition Language) serves as a service and syntax description mechanism, similar to the way WSDL (Web Services Description Language) is used in the Web services model.
More importantly, Corba still addresses the component-based development and EAI (enterprise application integration) requirements of enterprises realising the critical need for streamlined, object-level communications.
Corba is not going away anytime soon. And as it continues to benefit from SOAP and Web services adaptors, it will remain a top choice for large-scale projects in which performance and reliability are critically important.
Nevertheless, SOAP is poised to improve interplatform capabilities where Internet accessibility and ease of setup are paramount. As processor and network speeds increase, many of SOAP's limitations will become less important, making SOAP a better all-around consideration for a broader variety of enterprise projects.