Every day, CIOs and the architects and developers that work for them are presented with a daunting challenge. Even though their enterprise computing environments might deliver incredible business value, many of these environments have evolved into systems of complex heterogeneity. These CIOs are continually being asked to generate even greater value and achieve broader integration within enterprises that have grown complex through merger and acquisition, autonomous purchasing decisions at the division level, deployment of homegrown middleware, and other technology decisions. Over time, such systems become increasingly difficult to maintain and extend in a cost-effective manner.
One of the technologies found in many enterprises is CORBA. And whatever your opinion of CORBA, its success is undeniable: it has been powering numerous critical applications within the world's largest enterprises for the past decade. The extraordinary reliability and performance of these applications means that they will not be replaced anytime soon. How, then, can an enterprise maintain the advantage it has gained from CORBA while taking advantage of newer technologies such as web services?
A forward-thinking approach to adding web service capabilities across your enterprise is to move integration to the edges. Using WSDL, you can make your service endpoints and consuming applications capable of speaking multiple protocols and handling multiple message and data formats over multiple transports — avoiding gateways, bridges, and intermediaries entirely — without trying to shoehorn everything into a SOAP-only solution. A service can then freely expose a logical WSDL contract, making it available using whatever physical bindings it chooses to provide: the service consumer infrastructure simply chooses the appropriate binding to call or invoke the service. With this approach, consuming applications depend only on the logical service contract, and are not polluted with physical details about protocols, transfer syntax, or transports. The result is that existing services, like those implemented in CORBA, can become part of your bigger enterprise services picture without any need to replace them, modify them, or even stop and restart them.
Why use WSDL for contracts, rather than the myriad interface definition languages and programming languages available and in use in many enterprises? In fact, why not use CORBA's own IDL (interface definition language)? To me, the answer is clear: WSDL can represent a service completely, including its contract, its physical bindings, and any qualities of service and policies it wishes to advertise. A service has a single logical contract independent of its physical communication details. By describing that single logical contract in WSDL, any application code has to deal with only a single service model regardless of the underlying physical bindings. This is a significant benefit because it avoids the need for the developer to try to cram multiple technologies and models into an application just to integrate the various middleware systems that comprise the enterprise. The logical service contract is independent of the bindings, which describe possible ways of getting at the service. If you write your application against the logical contract, then you're relieving it from dependencies on underlying technologies. This protects your investment and gives you the flexibility to change and upgrade technologies without requiring you to "rip and replace" them entirely whenever something newer comes along.
As noted earlier, many of the world's largest companies have mission-critical CORBA applications that will not be retired anytime soon. These same systems could add significant value to new business applications if they could be effectively exposed to the rest of the enterprise without requiring them to be re-implemented, retested, and redeployed based on something newer. This is where WSDL comes in, and why we at IONA recently succeeded in getting the OMG, which looks after CORBA standards, to issue a request for proposals for a standard CORBA binding for WSDL. CORBA bindings for WSDL are key to allowing existing, deployed CORBA applications to continue to work in a web services world.
The typical way to integrate existing systems like CORBA with newer approaches like web services is not to integrate at the edges — within the consumers and services themselves — but rather to deploy gateways, bridges, or centralized intermediaries. Unfortunately, any approach to web services integration that requires the use of gateways or web service front ends just adds complexity to an already complex system. The use of gateways requires the deployment of new and often expensive hardware, creates new intermediary processes to manage, more network hops to cross, and more data conversions that reduce performance. The end result: added cost, more complexity, and slow services that don't deliver for the enterprise.
CORBA bindings for WSDL allow a CORBA object interface to be described in the logical part of the WSDL description, and allow the object's communication mechanisms to be described in a binding definition that forms part of the physical part of the WSDL description. Communications with the object therefore go over whatever protocols and transports the object's interoperable object reference (IOR) specifies (typically IIOP). As a result, existing deployed CORBA applications can operate, untouched and without bridges or gateways, as part of a larger web services integration. Note that this does not mean, however, that consuming applications must be aware of CORBA. Service consumers are WSDL-based applications, not CORBA applications. They know and depend on only the logical contract, and WSDL abstractions along with the appropriate middleware isolate them completely from the underlying CORBA communications infrastructure.
While it is true that not all aspects of all CORBA object definitions can be seamlessly redefined in WSDL, many CORBA objects in practice are quite compatible with WSDL. Redefining these in WSDL, thereby making all of these mission-critical CORBA applications available to the rest of the loosely coupled enterprise, is well worth it.
More on this topic
Related
For some time now, the existence of web services technologies has stimulated the discussion of Service Oriented Architectures ...
Service-oriented architectures and tools free up functionality in legacy systems ...