A comparison of CORBA and Web Services - Essay Example

A Comparison of CORBA and WEB SERVICES Contents of the Report Introduction Distributed Applications CORBA Web Services CORBA versus WEB SERVICES Conclusion Introduction Distributed Applications Distributed Applications refer to the applications which can be distributed across different processors and computer systems. This concept helps in deploying an application across systems on a network which might be working a common project or an application. Distribution introduces a whole new set of semantics for ease of computing; some applications by their very nature are distributed across multiple computers because of one or more of the following reasons (Chaffee & martin, 1999): The data used by the application are distributed The computation is distributed The users of the application are distributed There are some applications which might need to access common data. Therefore, the data which these applications must access must necessarily be residing on multiple systems for administration and ownership reasons. There are several options available with distributed applications like an owner could permit the accessibility of the data-the data might be permitted to be accessed remotely but not stored on the local systems. If the data cannot be co-located, it must necessarily exist on multiple heterogeneous systems. Many applications in particular make the use of multiple processors in parallel computing to run an application and to solve a problem. Other applications may execute on multiple computers in order to take advantage of some unique feature of a particular system. Distributed applications most definitely take advantage of the scalability and heterogeneity of the distributed system (Chaffee & Martin, 1999). Some applications execute on multiple computers because users of the application communicate and interact with each other via the application. Each user executes a piece of the distributed application on his or her computer, and shared objects, typically execute on one or more servers. A typical architecture for this kind of application is illustrated below. Fig 1: Distributed Applications (Chaffee & Martin, 1999) It is necessary for the Distributed application developers to address several issues in a local program where in one operating system process all logic is executed. There are some differences between the objects that are co-located in the same process and the objects that can interact across processes or machine boundaries. The objects that are co-located can communicate faster than the ones that run on distributed applications. When in a group of objects which are co-located, one object fails, the whole of the object group fails. However, in the distributed applications, if one object among the whole bunch of objects running fails, it will not affect the other objects. Also the networks can be partitioned so as to separate the objects into different domains. Concurrent access in co-located objects is possible only through multiple threads. Concurrent access among the objects is possible in objects running in the distributed applications. Co-located objects are totally secure which is evident through the fact that objects have access only among themselves and any other outer objects cannot access that group of objects. Objects in a distributed application environment are not secure since objects in such an environment are not protected against access from other processes. The communication speeds between the objects belonging to the same process are much higher when compared to the communication speeds between objects located on different machines. This statement implies that distributed applications which most probably might contain more than two objects having tight interactions should not be designed. If such applications are designed, the objects should be co-located to enhance the performance and the communication speeds. When two objects are co-located, they fail together; if the process in which they execute fails, both objects fail. The designer of the objects need not be concerned with the behavior of the application if one of the objects is available and the other one is not. However, the case is different if it is concerning two objects which are distributed across the process boundaries. Both the objects have the freedom of failing independently and in such cases, the designer of the objects must be concerned with each of the object's behavior in the event the other object has failed. In a distributed system the network can partition and both objects can execute independently assuming the other has failed. By default, most of the local programs and processes operate only with a single control thread which is generally designed in such a manner for the reason that single threaded programming is easy and not too many complications are involved. In order to introduce multiple control threads into a program or a process, the possible orderings of accesses to objects must be considered and also the synchronization mechanisms must be used to control the concurrent access to the shared objects. In a distributed application, there are necessarily multiple threads of control. Each distributed object is operating in a different thread of control. A distributed object may have multiple concurrent clients. As the developer of the object and the developer of the clients, we must consider the concurrent access to objects and use the necessary synchronization mechanisms. When two objects are co-located in the same process, the issue of security is automatically taken care of. When the objects are on different machines, security mechanisms to authenticate the identity of the other object might have to be used. CORBA: CORBA, or Common Object Request Broker Architecture, is a standard architecture for distributed object systems. It allows a distributed, heterogeneous collection of objects to interoperate. CORBA defines the architecture for distributed objects. The basic CORBA paradigm is that of a request for services of a distributed object (Jonusaitis, nd). Everything else defined by the OMG is in terms of this basic paradigm. The services that an object provides are given by its interface. Interfaces are defined in OMG's Interface Definition Language (IDL). Distributed objects are identified by object references, which are typed by IDL interfaces. The working of an application using CORBA is depicted in the diagram below: Fig 2: Client CORBA invoking a server CORBA (Segue Software, nd) A client holds an object reference to a distributed object. The object reference is typed by an interface. In the figure below the object reference is typed by the Rabbit interface. Fig 3: CORBA Interface (Chaffee & Martin, 1999) The Object Request Broker, or ORB, delivers the request to the object and returns any results to the client. In the figure, a jump request returns an object reference typed by the AnotherObject interface. The Common Object Request Broker Architecture (CORBA) from the Object Management Group (OMG) provides a platform-independent, language-independent architecture for writing distributed, object-oriented applications. CORBA objects can reside in the same process, on the same machine, down the hall, or across the planet. The Java language is an excellent language for writing CORBA programs. Some of the features that account for this popularity include the clear mapping from OMGIDL to the Java programming language, and the Java runtime environment's built-in garbage collection (Missier, 1999). Web Services: Web services are a topic that has garnered a lot of attention in the last few years. The term has numerous meanings depending on who you ask. To some, there's not much "web" in "web services." Overall, however, the term is used to describe the ability to easily link programs and data from various sources in a way that creates a new look at the data or even a new application (Gottschalk et al., 2002). A Web service is an interface that describes a collection of operations that are network-accessible through standardized XML messaging. A Web service performs a specific task or a set of tasks. A Web service is described using a standard, formal XML notation, called its service description that provides all of the details necessary to interact with the service, including message formats, transport protocols, and location (Sun Microsystems, 2002). Web service descriptions are expressed in WSDL. Web services technologies provide a language-neutral, environment-neutral programming model that accelerates application integration inside and outside the enterprise. Application integration through Web services yields flexible loosely coupled business systems. Because Web services are easily applied as a wrappering technology around existing applications and information technology assets, new solutions can be deployed quickly and recomposed to address new opportunities (Curbera, 2001). As adoption of Web services accelerates, the pool of services will grow, fostering development of more dynamic models of just-in-time application and business integration over the Internet. Fig 4: Web Services(Curbera, 2001) The architecture sets forth three roles and three operations. The three roles are the service provider, the service requester, and the service registry. The objects acted upon are the service and the service description, and the operations performed by the actors on these objects are publish, find, and bind. A service provider creates a Web service and its service definition and then publishes the service with a service registry based on a standard called the Universal Description, Discovery, and Integration (UDDI) specification. CORBA versus Web Services One important observation concerning CORBA and Web services is that whatever can be accomplished by CORBA can be accomplished using Web service technologies and vice versa, although the amount of effort required would be noticeably different. In particular, one can implement CORBA on top of SOAP, or SOAP on top of CORBA. There are however several differences that be attributed to the technology they are built upon. Data Distribution When compared with respect to the data model, CORBA uses the object model and the web services works on the SOAP message exchange model. The object model that CORBA uses relates to the model of an object. Using an object, we can relate to any process. A process can hold any access to an object which means the applications are totally object based. Web-Services use the SOAP (Simple Object Access Protocol) basis. Using SOAP, distributed application environment can be implemented with a mixture of object and process oriented environment enabling the use of advantages of both types of implementations (Windley, 2003). One important distinction that comes into play when examining CORBA and Web services is how an application is modeled in either case. CORBA is a true object-oriented component framework, whereas Web services are centered around a message passing paradigm with no notion of objects. As mentioned earlier, SOAP, despite its name, does not deal with objects. There was a belated effort to reassign the name SOAP to mean Service Oriented Access Protocol, but the XML Protocol Activity Group did not like this acronym first, description later approach. So in the latest W3C working drafts, it is simply called SOAP 1.2, with no explanation of what the name means. In CORBA, there is a tight coupling between the client and the server. First, both must share the same interface -- with a stub on the client-side and the corresponding skeleton on the server-side -- and must run an ORB at both ends. Second, the interaction between client and server can be done directly, with no need for further intermediation. Request semantics In order to maintain data consistency, the infrastructure should provide at most once semantics. These semantics guarantee against multiple executions of the same client request on the server. CORBA ORBs are required to provide at most once semantics, thus ensuring data integrity. CORBA also specifies a Transaction Service that provides support for multiple transaction models such as flat and nested. In Web services, the message semantics are defined by the protocol underlying SOAP (Moller & Schwartzbach, 2006). There are some additional issues. SOAP has a notion of exceptions/errors (SOAP-Fault specification) that can be returned by a Web service. However, that portion of the SOAP specification has been criticized since it requires a service returning a SOAP-Fault to also return an 'HTTP 500' error status, thus breaking the true layering nature of the protocols involved. Scalability and reliability Several applications such as B2B transactions and banking/stock trade transactions, among others should scale reliably to several million transactions per day. In CORBA, the Portable Object Adapter (POA) policies combined with the Fault-tolerant CORBA features and the Load-balancing CORBA service provide the desired scalability to CORBA applications. The Fault tolerant CORBA uses the entity redundancy paradigm to provide fault tolerance to CORBA objects. These issues are not part of the Web services standards, but again, are left to the components implementing these standards. Application servers (e.g. IBM's WebSphere) implement their own mechanisms to handle scalability and reliability. Serializability 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 specification enables features such as reverse Java-to-IDL mapping that allows Java RMI objects to interoperate as CORBA objects; and the XML/Value mappingthat allows XML documents to be represented as native CORBA types. SOAP 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 (Mougin & Barriolade, 2001). It has been argued that SOAP, being XML based, is too verbose as compared to CORBA IIOP's binary format, and thus introduces a big performance hit. That may be true for certain kinds of applications, but in most complex business applications, the cost of message passing is dwarfed by the cost of processing the business logic. Hence, the verbose nature of SOAP might not be an issue. Static and runtime checks The programming platform should offer some static and run-time guarantees about the execution behavior of the application. CORBA uses IDL as a contract language. IDL is strongly typed and provides some static guarantees. CORBA Dynamic Invocation Interface (DII) on the other hand does not provide such static checks. The implementation can also take advantage of some properties of the target language (e.g. Java) with some runtime checks (e.g., array bound checks, etc.). When building Web services, there is no standardized infrastructure support to offer static checking. At runtime, only the structure of the SOAP message is checked, and the payload is only required to be a piece of well-formed XML. It is the responsibility of the application to verify the payload further (i.e., validate against a schema). In the future, WSDL could be used to generate a mapping to a programming language to offer some static guarantees. Location transparency Client applications should be able to seamlessly interoperate with the services, without concern for the location of the service. CORBA client applications obtain references to objects and invoke operations on them to perform application tasks without concern for whether the objects are remote or collocated relative to the client. Web services client applications (using SOAP) refer to services using URLs which implicitly encode the location (IP address) of the service. However, location information can be changed via DNS. A side-effect of the encoding of network information in URLs, is that it permits some semantic manipulation of network addresses directly at the level of the application, making it sometimes easy to write proxy services. Registry Efficient repositories for services that maintain all the service-specific information should be available. The CORBA standard defines an Interface Repository (IR) that provides run-time information about IDL interfaces. At run-time clients can use the IR to discover the operations that can be performed on an object, and make invocations on it using the Dynamic Invocation Interface (DII). The CORBA standard also defines an Implementation Repository that contains information that allows an ORB to activate servers to process a request, along with other server-specific information such as administrative control, resource allocation, security, and activation modes. For Web services, UDDI provides an XML/SOAP standards-based framework for describing and managing the web services (Lindstrom, 2004). In particular, UDDI provides searchable central repositories using a publish/subscribe mechanism to store service definitions. UDDI registries optionally can store some structural information about the service in the form of a WSDL specification which defines the set of interfaces and messages used by the service. Metadata for the services is stored in the form of XML schemas to enable discovery using standard search tools. Service Discovery Service lookup should be easy (e.g., accessing a service via its name, or functionality offered). The CORBA Interoperable Naming Service defines a URL-formatted object reference called corbaloc that applications can use to reach remote services. A second URL format called corbaname allows applications to directly invoke the remote service. The Trading Object Service supports an advanced lookup, registration and discovery of services based on service type. In Web services, UDDI registries permit discovery of services matching a given interface. UDDI is itself a Web service accessible via a SOAP interface. Firewall traversal Application requests should be able to seamlessly traverse firewalls after proper security audits. This is crucial for applications that span enterprises. The upcoming CORBA Firewall Traversal specification allows CORBA requests to be routed through firewalls (Gray, nd). Explicit routing information is added to the interoperable object references (IOR). The clients can control security parameters such as end-to-end SSL or permit unencrypted requests via gateways/proxies. Note that this is still a draft specification, and currently not supported by ORB vendors, or supported via proprietary solutions only. For Web services, the preferred transport protocol is SOAP over HTTP. Because HTTP is the ubiquitous Web protocol with a well-defined port, firewalls are usually configured to allow inbound and outbound HTTP traffic, thus enabling SOAP messages to cross firewall boundaries easily. The presence of Web service does not require any change in the firewall configuration. SOAP over secure HTTP (using SSL) is handled in the same way. Security Security in distributed applications involves a variety of features such as authentication, authorization, encryption, data integrity, delegation, non-repudiation and auditing. All these features are supported by the CORBA Security service. However, there are no standardized security services in the Web services technology stack. Some aspects of security can be dealt with at the level of the transport protocol though. SOAP does not specify any security features but rather makes it easy to build security using Internet technologies such as SSL or XML-Signature for maximum interoperability. Moreover, Web service vendors have started offering some security services (e.g. Microsoft's Passport and Sun's Liberty Alliance for network identity). However, the security solutions being provided for Web services are akin to reinventing the wheel since significant R&D efforts have gone into developing a well defined CORBA Security service. Persistence Certain applications such as online shopping maintain customer state in the form of shopping carts. Such information should be made persistent to handle failures or as mandated by the business logic. The CORBA Persistent State Service (PSS) provides the mechanism to maintain a persistent state of the object. The PSS is an abstraction layer that provides a unique API to use any kind of data stores like files, databases, directory, and so on. Web services do not define a standard persistence mechanism, instead leaving it to the applications to do so. For example, applications written in Java can make use of Java serialization to create persistent objects. Ease of deployment and assembly The framework must be amenable to creating, assembling, and deploying services by integrating new as well as custom-built legacy components, while still offering standardized, open interfaces to clients. The CORBA Component Model (CCM) provides a container environment. Furthermore, CCM provides the ability to develop components in multiple languages. The specification provides a multi-platform software distribution format that includes an installer and XML-based configuration tools. Due to its platform independent feature, CORBA is very well suited to wrap legacy applications as CORBA objects and bind them together. The main motivation for SOAP (and Web services more generally) is to address the complexity of deploying and assembling software components. Even though it is too early to draw any conclusion about this new technology, SOAP tries to address these two issues in the following ways. SOAP relies on Web data-formats and protocols that have been successful, such as XML and HTTP. SOAP champions interoperability by imposing a simple message-based protocol, which is model, language and platform independent. The underlying data-model is XML-based which makes it expressive and extensible. SOAP is being touted as a middleware technology for middleware. SOAP is being enriched by new technology to make the authoring, assembly and deployment of Web services easy. Development platforms such as .NET and WebSphere make this task easier. Platform independence New service offerings might potentially have to leverage from components built on heterogeneous platforms involving different hardware and software including different operating systems and implementation languages. CORBA has been designed to be platform independent. This includes hardware, operating systems, and programming and scripting languages. In Web services, all message communication is via SOAP, and no other restrictions (e.g., platform similarities) are imposed on the client or the server. The only requirement is to be able to read and write SOAP messages (i.e. XML documents). Footprints The use of mobile embedded devices such as PDAs mandate the need for a small footprint client-side (or even server-side) application. The Minimum CORBA specification provides a subset of the CORBA standard and is meant primarily for embedded systems. The OMG is also working on a Wireless CORBA specificationthat allows wireless access, terminal mobility, and service provisioning in CORBA. A related work in the OMG community deals with CORBA for smart transducers. Note however that all these specifications still require some minimum infrastructure on the client side. In Web services, depending on the complexities of the client and server (e.g., is WSDL/UDDI required), the footprint requirements will vary. In extreme cases (e.g., thin clients accessing simple services), it is not hard to imagine that the client might not even require a full XML parser. Conclusion One of the goals of the CORBA specification is that clients and object implementations are portable. The CORBA specification defines an application programmer's interface (API) for clients of a distributed object as well as an API for the implementation of a CORBA object. This means that code written for one vendor's CORBA product could, with a minimum of effort, be rewritten to work with a different vendor's product. However, the reality of CORBA products on the market today is that CORBA clients are portable but object implementations need some rework to port from one CORBA product to another. Web-Services was developed to provide a platform for the applications to run on different systems. Using Web-Services, the communication between the objects of the same process residing on different systems across a network or across wide areas is made easy and faster. The APIs of Web Services help implement the concept of distributed applications. Both CORBA implemented distributed applications as well as Web Services implemented distributed applications aim at facilitating proper communication between the objects and processes running on different systems. As it was seen, there are several differences between Web-Services and CORBA. Although there are contrasting differences, both of them can be combined and can be applied to implement distributed applications on a large network. Web-Services is mainly used for the applications running on web whereas CORBA is mainly used within local networks. Both have advantages and disadvantages with regard to working with objects. However, when distributed applications are designed using both CORBA and Web-Services, we can build strong architectures for multi-networked systems and a lot of research is going on in this field. References Chaffee Alex., Martin Bruce., (1999), "Introduction to CORBA", Article, Magelang Institute, http://java.sun.com/developer/onlineTraining/Downloads/CorbaIntro.PDF Jonusaitis Paul., (nd), "An Introduction to CORBA", Online Presentation, found at: http://www.uniforumchicago.org/slides/corba/corba_ov.pdf Segue Softwre, (nd), "A CORBA Primer", Online Article, found at: http://www.omg.org/news/whitepapers/seguecorba.pdf Missier Paolo., (1999), "An Introduction to CORBA", Online Article, found at: http://www.dia.uniroma3.it/atzeni/psfiles/CORBAIntro.pdf Gottschalk K., Graham S., Kreger H., Snell J., (2002), "Introduction to Web Services Architecture", http://www.research.ibm.com/journal/sj/412/gottschalk.pdf Sun Microsystems, (2002), "Web Services Made Easier", Online Article, found at: http://java.sun.com/xml/webservices.pdf Curbera Francisco., (2001), "Web Services Overview", Online Article, found at: http://www.llnl.gov/CASC/workshops/components_2001/viewgraphs/FranciscoCurbera.pdf Moller Anders., Schwartzbach Michael I., (2006), "An Introduction to XML and Web Technologies", Online Article, found at: http://www.brics.dk/ixwt/webservices.pdf Windley Philip J., (2003), "Enabling Web Services", Online Journal, found at: http://www.windley.com/docs/EnablingWebServices.pdf Mougin Phillippe., Barriolade Christophe., (2001), "Web Services, Business Objects and Component Models", Online Article, found at: http://www.xml.org/xml/feature_articles/orchestra_webservice.pdf Lindstrom Pete., (2004), "Attacking and Defending web Services", Online Article, found at: http://forumsystems.com/papers/Attacking_and_Defending_WS.pdf Gray N. A. B., (nd), "Comparison of Web Services, Java RMI and CORBA services", Online Journal, found at: http://mercury.it.swin.edu.au/ctg/AWSA04/Papers/gray.pdf Gokhale Aniruddha., Kumar Bharat., Sahuguet Arnaud., (nd), "Reinventing the Wheel CORBA vs Web Services". Read More