Comparing Common Object Request Broker Architecture and Web Services - Assignment Example

Abstract The emergence of CORBA has created a new computing concept away from the traditional loosely service-oriented Web Services. CORBA’s capability is potentially useful and reliable making it the choice of various industries such a Banking and Finance, Telecommunications, E-Commerce etc. Its state of the art Object Resource Broker is the driving force behind CORBA efficiency in processing client request. Web Service through SOAP and XML data format also maintains a standard, flexible, extensive, and reliable distributed computing. Through various criteria, the comparison between concepts and features of CORBA and Web Services resulted in a new concept of distributed computing that would certainly benefit the enterprise. Table of Contents 1. Introduction 2 2. Scope of the Study 3 3. Literature Review 3 3.1 CORBA 3 3.1.1 Overview 3 3.1.2 Data Model 5 3.1.3 Client/Server Coupling 8 3.1.4 Location Transparency 8 3.1.5 Serialization, Scalability, and Reliability 8 3.1.6 Persistence 9 3.1.7 Request Semantics 9 3.1.8 Runtime Composition and Error Handling 10 3.1.9 Registry 10 3.1.10 Service Discovery 11 3.1.11 Platform Independence 11 3.1.12 Security 11 3.1.13 Firewall Traversal 11 3.1.14 Ease of Deployment and Assembly 12 3.2 WEB SERVICE 12 3.2.1 Overview 12 3.2.2 Data Model 15 3.2.3 Client/Server Coupling 16 3.2.4 Location Transparency 16 3.2.5 Serialization, Scalability, and Reliability 16 3.2.6 Persistence 17 3.2.7 Request Semantics 18 3.2.8 Runtime Composition and Error Handling 18 3.2.9 Registry 18 3.2.10 Service Discovery 19 3.2.11 Platform Independence 19 3.2.12 Security 19 3.2.13 Firewall Traversal 20 3.2.14 Ease of Deployment and Assembly 20 3.3 Comparison Table 21 4. Discussion 23 5. Conclusion 24 6. Reference List 25 1. Introduction Initially the modest purpose of the World Wide Web was to exchange simple information but as e-commerce grew the need for better and secured information exchange mechanism increased. Since then various web applications with different strategies and mechanism for accessing e-services have been introduced to a range of business enterprises. Microsoft and IBM introduced the standardization of the Simple Object Access Protocol to facilitate automatic access to multifaceted message exchange services in web. SOAP is a lightweight XML based protocol that is part of the Web Services offered by the XML Protocol Activity Group with UDDI/WSDL under the W3C and believed to be the best solution to e-commerce. Meanwhile, building complex services is another goal of many distributed application developers. Microsoft built COM, DCOM, and COM+, Java released its Enterprise Java Beans, and CORBA, the only distributed application framework that is platform and language independent. CORBA earned its reputation in the area of finance, healthcare, and telecommunication as a versatile and reliable distributed component framework. On the other hand, SOAP despite of its reputation as an “object” based component of the Web Service is not truly object-oriented like CORBA. It is in fact a message-based component focus on the communication aspect of the infrastructure than the objects of the service. CORBA, however, comes with services such as events, naming, and trading that put business logic on the centre of the process. However, one opinion is not enough to say that CORBA is more efficient than Web Service and therefore a study of will be conducted to facilitate a much better understanding of the concept of both contesting web component. In the paper, we will provide a comparison between CORBA and Web Services and see how they are going to score in some of the most significant criteria of the distributed computing model. 2. Scope of Study We will compare CORBA and Web service technologies using criteria in a distributed computing model such as data model, client-server coupling, location transparency, platform independence, serialization, scalability, reliability, persistence, request semantics, runtime composition and error handling, registry, service discovery, security, firewall traversal, and ease of deployment and assembly. 3. Literature Review 3.1 CORBA 3.1.1 Overview In simple terms, CORBA (Common Object Request Broker Architecture) is one famous technologies that can be use to construct enterprise computing platform. It enables the interconnection, intercommunication, and interoperability of distributed application software in enterprise. Sharing arrangements are typically relative static and restricted to occur within a single organization. The primary form of interaction is client/server mode, rather than the coordinated use of multiple resources (Wang 2004, p.314). The CORBA specification from the Object Management Group or OMG was developed to support the implementation of distributed object systems. In CORBA-based system, processes executing on the same or different computers are linked by object request brokers (ORB) who allow object in these different processes to interact as if they were in a single environment on a single computer. If one object in a process has an object reference for an object in another process, the reference is indirect. A proxy object will represent the remote object. If the “customer” object sends a message to the “account” object, it goes to the “proxy” object first. The proxy object invokes the object request broker, which forward the message to the remote object and returns the result. In each process or ORB domain, every reference to an object in another domain is represented with a proxy object. Each domain may send and receive message from all other domains- they are peers. However, they need not to be used as peers, each domain knows about the external objects through their proxies and the proxies contain sufficient information to locate the associated domain and object within that domain. The interactions between objects, from an application programming perspective, are the same as in a single environment even though the objects are being executed on different computers. The objects may also be implemented in different languages. The target objects maybe a façade or “wrapper object” that can act as an adapted interface to a legacy system. (Sadiq and Cummins 1998, p.15; Balen 2000, p.6). CORBA’s application in different industries such as Banking and Finance for Online Account Access, Bill Payments, and Stock Trading has been a success. E-commerce application such as Online Shopping; B2B in Supply Chain Networks; providing Insurance Claim Handling System and Hospital Patient Record Management for the Health Care Sector; Service Provisioning and Network Management for Telecommunications; Virtual Customer Care Centre for big enterprise; and pay per-view subscription service in the entertainment industry (Gokhale et.al. 2002, p.1) 3.1.2 Data Model The CORBA architecture model is derived from the abstract Core Object Model defined by OMG in the Object Management Architecture Guide thus CORBA’s model is described as the concrete object model. “An object model is an organized presentation of object concepts and terminology that defines a partial model for computation that embodies the key characteristics of objects as realized by the submitted technologies” (OMG 2001, p.1-2). The OMG object model is non-representational of any particular technology directly. A concrete object model can make the abstract object model more precise by expanding it through specifying types of language used or form of request parameters definition. Furthermore, it may introduce specific instances of model-defined entities that could populate the model similar to specific objects, operations, or types. In addition, it may also eliminate entities or place restrictions on their use that could eventually control the model (OMG 2001, p.1-2). The compilation of objects with a well-defined encapsulating interface that can isolate a client from the service provider is an object system. In particular, clients are isolated from the implementations of services as data representations and executable code. At first, the object model communicates to client concepts that are most significant such as requests and operations, types and signatures, and object identity and creation. Next, it will make clear concepts correlated to object implementations such as processes, implementation engines, and activation. Apparently, it is more focus on defining and prescribing concepts important to clients. It is more suggestive when discussing concepts relevant to object implementation as its aiming to allow utmost autonomy to various objects technologies to provide several ways of object implementation. There are other characteristics of object systems outside the scope of the object model, which falls under the architectural reference model. These are compound objects, change management, transactions, copying of objects, and links. Functionality wise, method selection could be performed both by the object or the ORB (OMG 2001, p.1-2). Finding and organizing the object of implementation to accept the request and communicate to the data requesting is the responsibility of the ORB. The location of the object, the programming language, and any other features are completely autonomous interface as far as the client is concern. Fig. 1.0 Client (“entity”) sending a request through an ORB to an object implementation. The code and data that actually implement the object is the client by performing an operation on the object and the object implementation. In the request process, OMG IDL stub can be utilized by client or the Dynamic Invocation interface (DI). It can also openly network with the ORB for several tasks. As an up-call through the OMG IDL generated or dynamic skeleton, the OI can accept a request from a client. In the same, the OI, while processing a request may call the ORB and the OA. Since OMG’s IDL can facilitate the static definition of an Interfaces. The definition of the type of objects depends on the operation or the parameters of that operation to be done on them. Interfaces can be accommodated and permitted to access by IR as CORBA objects. In any ORB implementation IR and the IDL share equal communicative control. Figure 1.1 A discrete ORB where striped boxes and arrow represents the interfaces and calls respectively. 3.1.3 Client/Server Coupling CORBA coupling for client/server is tight because they have to use an ORB at each ends and carve up same perimeter with a matching stub on the client end and a skeleton on the server side. Secondly, there is an open interface between client and server thus except from the ORB, intermediation is no longer necessary. The CORBA object gives the client a handle and applies a method on it, which will probably result in another CORBA object where further method is applicable (Gokhale 2002, p.1; Balen 2000, p.34). 3.1.4 Location Transparency As a rule, regardless of the location of service, there should be a good and effortless interoperability between the client applications and the services, Client applications in CORBA are acquiring references to objects, call up functions, and carry out application tasks regardless of object’s location. 3.1.5 Serialization, Scalability, and Reliability Serialization affects a variety of concerns such as performance, extensibility, persistence, and ease of interoperation with different structures. The CORBA Objects-by-Value design offers language-independent operation comparable to serializable effectiveness of Java. Through valuetypes design features, Java-to-IDL mapping let Java RMI objects to interoperate as CORBA objects (Spaniol et. al. 1996, p.15; Gokhale 2001, p.1; Horstmann and Cornell 2003, p.5). Correspondingly, by means of XML/Value mapping, XML documents are represented as native CORBA types. Through the Portable Object Adapter (POA) policies combined with the Fault-tolerant (using entity redundancy paradigm) and the Load-balancing features of CORBA, numerous applications such as B2B transactions and banking/stock trade transactions should work reliably to quite a few million transactions per day since CORBA service ensures scalability to other CORBA applications. 3.1.6 Persistence Maintaining customer’s state in the form of shopping carts on online shopping which is mandated by the business logic, applications needs to be persistent and should be able to handle failures. CORBA provides and maintains a persistent state of the object through an abstraction layer that provides a unique API that uses any form of data like files, directory, and databases. This is a mechanism is called CORBA Persistent State Service (PSS) 3.1.7 Request Semantics “The infrastructure should provide at most once semantics in order to maintain data consistency at all times”(Gokhale 2002, p.1). During multiple executions, these semantics guarantees execution of the same client request on the server thus ensuring data integrity. CORBA ORBs are required to provide at most once semantics and specify a Transaction Service supporting flat and nested multiple transaction models. 3.1.8 Runtime Composition and Error Handling Normally, static and run-time safeguard is a part of a programming design to restrain the working performance of the application. In this regard, CORBA employs a contract language like IDL, which is robustly formed and guarantees control of static run-time behaviour. CORBA Dynamic Invocation Interface (DII) on the other hand does not provide such static checks but it can take benefit from some properties of the intended language as Java’s array bound checks. 3.1.9 Registry Availability of information for all service oriented information is a good quality of an efficient repository. To determine the operations that can be administered to an object at run time, clients can exploit a CORBA model capable of giving IDL interfaces run-time information—CORBA Interface Repository (IR). Comparably, if they need to make invocations, Dynamic Invocation Interface (DII) is also available for them. In addition, server-specific information such as, resource distribution, security, activation modes and administrative control that are required to trigger a server to handle a request through ORB, are available with CORBA’s Implementation Repository. 3.1.10 Service Discovery Service lookup enable easy access to services using its name or functionality. However, for remote access, applications can utilize CORBA Interoperable Naming Service’s URL-formatted object reference-- corbaloc. Similarly, to invoke the remote service, applications can use corbaname, a second URL format from the same CORBA service. For advanced lookup, registration, and discovery of services based on service type, applications can use the Trading Object Service. 3.1.11 Platform Independence The design of CORBA is platform independent that do not require specific hardware, operating systems, programming, and scripting languages thus it does not need to gain power from components built on assorted platforms. 3.1.12 Security CORBA Security service maintains an assortment of security features that are incorporated in ideal distributed applications. These are auditing, validation, permission, encryption, data integrity, allocation, and non-repudiation. 3.1.13 Firewall Traversal The upcoming CORBA Firewall Traversal specification allows routing of CORBA request to a firewall. This feature will be able through the Interoperable Object References (IOR) thus application requests should be able to seamlessly traverse firewalls after proper security audits which is crucial for any application that span enterprises. Clients can administer security parameters such as lateral SSL or approved unencrypted requests through gateways/proxies, the However, this is currently not supported by ORB vendors since it is still a draft specification only. 3.1.14 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” (Gokhale et. al. 2002, p.20). Similar to EJB (Enterprise Java Beans), the CCM provides a container environment and support them as a another CORBA component. Since its platform independent, CORBA treats legacy applications as CORBA objects that it could wrap and bind together. In addition, it has the facility to develop components in multiple languages and provides a multi-platform software distribution format that includes an installer and XML-based configuration tools. 3.2 Web Service 3.2.1 Overview “Web services offer a standard means of interoperating between dissimilar software applications, running on an assortment of platforms and/or frameworks and WSA present a theoretical model and a structure for understanding Web services and the relationship between the components of this model” (W3C 2004, p.6).. It is implemented and enforces no restriction on how combinations of Web services should be since the architecture does not have any specification in this regard and in order to ensure interoperability between Web services, it recognizes inclusive elements of the global Web services network (W3C 2004, p.6). In general, in any recognition of the architecture, a theory is expected to have some structure of communication. For instance, we expect to be able to identify in any Web services context through the message concept’s class of objects. Since message diverge noticeably and they do not have an exact form, the message model inform us of what to expect in a particular tangible structure as an alternative to imposing its specific form,. However, not all concepts in terms of data objects or structures taking place in computers or communications devices will have a realization. For instance, people and human organizations are the person or organization and a more abstract concepts are will consider message reliability as denoting a property of message transport service that cannot be touched but nevertheless is vital to Web services. The presentation of each concept is in a standard but methodical way comprised of a short definition. This is like the account of interaction with other concepts that has somewhat extended illustrative explanation. For instance, an agent is a computational resource that has an identifier and a possessor as far as the theory of agent is concern. However, explanations on why agents are significant to the architecture are available in detail in the description part of the agent (W3C 2004, p.10). “Through standard, flexible and inherently extensible data format, key technology requirement that emerge in many places are solved by XML” (W3C 2004, p.64-65). To guarantee the success of Web services, XML considerably diminishes the trouble of deploying the many technologies essential to the services. The core syntax itself is the most important aspects of XML. However, for the purposes of this Architecture, are the concepts of the XML (Infoset, Schema, Namespaces). XML Infoset is a prescribed collection of information objects and their coupled properties consist of a theoretical explanation an XML file. In a number of stipulations requiring referral to the information in a regular XML file, to first place too look for a dependable and accurate array of definitions is in its specification. Although it is not an inherent requirement of the architecture, XML 1.0 can express the serialization XML Infoset definitions of information. The litheness in preference of serialization design permits for a wider interoperability involving agents in the system. It is not remote textual serialization maybe represented by a binary programming of XML in the future since binary encoding may be more competent and fitting to the degree that machine-to-machine interactions is involve (W3C 2004, p.64-65). “SOAP 1.2 provides a standard, extensible, modifiable framework for packaging and exchanging XML messages” (W3C 2004, p.64-65). In the context of this architecture, it is a convenient mechanism for referencing capabilities. Messages from network protocols such as HTTP and alike can be carried by a SOAP since it has various components that is capable of programming rules for articulate occurrence of data types that are application- defined. For SOAP with HTTP version 1.1, it has a standard for signifying RPC, riposte, and a collection of policies intended for specific purpose. A SOAP message aside from the information specified in the service interface, generally symbolizes the information essential to call upon a service or reproduce the results of a service invocation. Similarly, a SOAP message is communicating with a remote object through a method invocation particularly when using a SOAP RPC Representation where the serialization contained in the method’s argument register must be transferred from the present location to the distant environment. In addition, WSDL 2.0 facilitates the description of the Web services beginning with the switching over of messages among the provider agents and clients. However, this may necessitate an actual network protocol and a message system since the description of the messages themselves is intangible. Since mapping of definitions for Web Service definitions is possible through any implementation language, platform, object model, and messaging systems, communication by means of browsers or application direct is applicable. If both sender and receiver concur on the service description, Web services for any number of proprietary amalgamation solutions is limitless (W3C 2004, p.64-65). 3.2.2 Data Model With no notion of objects, Web services are undoubtedly centred on a message-passing paradigm and regardless of its name, SOAP does not deal with objects. Reassigning the name SOAP to mean Service Oriented Access Protocol was just a deferred attempt to hide it thus again, with no description of what the name means, the latest W3C working drafts simply call it SOAP 1.2. 3.2.3 Client Server Coupling When the client sends a message and receives a message in a Web Service, the response does not give an immediate access to the next step and therefore decoupled. 3.2.4 Location Transparency Since location information can be changed via DNS and the programming of network information is in URLs, manipulation straight at the level of the application is consequential to a number of trouble-free semantic manoeuvring of network addresses that you can easily write codes for surrogate services. This is possible since the Web services client applications through SOAP transfer to services by means of URLs, which unreservedly programme the service address. 3.2.5 Serialization, Scalability, Reliability Reliable messaging is often referred to as Reliability. However, there are deep-seated restrictions to the dependability of communication among agents on a open network in several distributed system but in practice, we can greatly augment the consistency of messages by means of techniques and we can get some response to the sources of the failure during communication break down. For instance, the sender of the message would like to know if the given message has been received exactly once, already picked up, and received correctly. Aware that the message did not successfully go through allows the sender to take compensating action and attempt to resend the message (W3C 2004, p.85). “The Web services architecture does not itself give specific support for reliable messaging or for reporting in the event of failure” (W3C 2004, p.86). However, there is no clear explanation on how this can be done. Since SOAP programming is XML-based and offer some highly developed characteristics like light arrays to decrease transport outlay, it permit for serialization mechanisms defined by the user. It may be factual for specific sort of applications that XML-based SOAP initiated a large operation hit and too verbose to weigh against CORBA IIOP's binary design but the price tag of business logic processing in generally multifaceted production applications is soaring than the outlay of message dispatching. Application servers like WebSphere using their own scalability and reliability mechanisms are implementing the necessary processes to ensure operating standards for Web services. 3.2.6 Persistence Definition of a standard persistence mechanism is not included in Web services and applications should do the persistence handling. For instance, create persistent objects, Java applications can utilize of Java serialization. 3.2.7 Request Semantics In Web services, a SOAP protocol defines the message semantics. For instance, HTTP is normally the underlying protocol of SOAP but it does not provide any at-most-one semantics. Furthermore, SOAP is known to return its exceptions/errors (SOAP-Fault Specification) to an HTTP 500 error status when working over HTTP. This is apparently destroyed the layered nature of protocols. 3.2.8 Runtime Composition and Error Handling “There is no known standardized infrastructure offer static checking support in Web services”(Gokhale 2002, p.1). Normally, the application is responsible to validate payload against the schema but in the SOAP, only the message structure is checked and do not account for the payload at runtime. However, there is a possibility that WSDL could be used to offer some static guarantees by generating a map to a programming language, but message validation in SOAP is much better that verifications based on IDL because XML Schemas are more expressive than IDL and define some syntactic or semantic checks. 3.2.9 Registry A XML/SOAP standards-based structure for web services description and administration is offered by UDDI using exploitable main repositories using a distributed device to stock up service description. Optionally, information about the structure can be stored in UDDI registries. On the other hand, Metadata for the services is stored in the form of XML schemas to enable discovery using standard search tools. 3.2.10 Service Discovery In Web Service, a client may necessitate to "discover" an appropriate participant for interaction lest it has on information what provider agent it desires to hook up. The process of finding an unknown but functional (appropriate service) machine-processable description of a Web service is called “discovery”. The UDDI in Web Service is doing this job. Since UDDI by its own is a Web service reachable via a SOAP interface, its registries allows discovery of services corresponding to a specified interface (W3C 2004, p.68). 3.2.11 Platform Independence There is no restriction imposed on the client or the server for as long as they are both able to read and write SOAP messages as SOAP facilitates all message communication in Web services. 3.2.12 Security There are no standardized security services in Web services but SOAP deals with it in the transport protocol level using SSL or XML signature for maximum interoperability. Furthermore, there are many security services like Microsoft's Passport and Sun's Liberty Alliance for network identity verification. 3.2.13 Firewall Traversal For Web services, since HTTP is an ever-present protocol (Gray 2004, p.1) with a discrete port, firewalls are naturally arranged to authorize inbound and outbound HTTP interchange. The favoured transport protocol is SOAP over HTTP, therefore facilitating easier SOAP messages traversal to firewall restrictions. SOAP over secure HTTP is controlled in the same manner thus; the existence of Web service does not necessitate any modification in the firewall arrangement. 3.2.14 Ease of Deployment and Assembly To deal with the difficulty of deploying and assembling software components is the foremost motivation for SOAP and Web services and they are trying to resolve these issues through WSDL and UDDI. SOAP is being augmented by these technologies to make creating, assembling and deploying of Web services simpler. Furthermore, development platforms such as .NET and WebSphere make this task much easier. Even if it is still hasty to draw any assumption about this novel technology, it is all right to say that SOAP is reliant on thriving Web data-formats and protocols such as XML and HTTP. SOAP supports interoperability by enforcing a model, language and platform independent simple message-based protocol. 3.3 Comparison Table Aspects CORBA WEB SERVICES Data Model Object Model SOAP Message Exchange Model Client/Server Coupling Tight Loose Location Transparency Object references URL Serialization, Scalability, and Reliability Built in ORB, Portable Object Adapter, Fault-Tolerance and Load Balancing User Selectable Persistence Persistent State Service (PSS) No Standard persistence mechanism, application dependent Request Semantics Once semantics through ORB for data integrity. Semantics are defined by protocol underlying SOAP i.e. HTTP but does not provide at-most-one semantics Runtime Composition and Error Handling Some static guarantee from IDL. Application dependent for checking payload. No standard support static checking. Registry Interface Repository for providing run time information and Implementation Repository to enable ORB to activate servers. UDDI provides an XML/SOAP standards-based framework for describing and managing the web services. UDDI registries optionally can store some structural information about the service in the form of a WSDL specification. Service Discovery CORBA Interoperable Naming Service defines a URL-formatted object reference called Corbaloc that applications can use to reach remote services. Corbaname allows applications to directly invoke the remote service. Trading Object Service supports an advanced lookup, registration and discovery of services based on service type DDI registries permit discovery of services matching a given interface. UDDI is itself a Web service accessible via a SOAP interface. Platform Independence Designed to be platform independent. This includes hardware, operating systems, and programming and scripting languages. All message communication is via SOAP. The only requirement is to be able to read and write SOAP messages Security CORBA Security Service: authentication, authorization, encryption, data integrity, delegation, non-repudiation and auditing No standardized security services. However, security can be dealt with at the level of the transport protocol. Firewall Traversal CORBA Firewall Traversal Specification (upcoming) SOAP over secure HTTP. Firewalls are usually configured to allow inbound and outbound HTTP traffic, thus enabling SOAP messages to cross firewall boundaries easily. Ease of Deployment and Assembly CORBA Component Model (CCM). CCM provides the ability to develop components in multiple languages. Platform independent feature Simple message-based protocol, which is model, language, and platform independent. Authoring, assembly and deployment of Web services through development platforms such as .NET and Websphere. 4. Discussion According to the specifications presented in behalf of CORBA and Web Services, it is clear that the predominant issue between these two distributed systems is “object” orientation. Web Services appears to neglect some parts of the original concept of “service oriented” architecture to solve business requirements. Apparently, Web Services do not include in its design some of the most important aspects of business oriented distributed system such as persistence mechanism, built-in serialization, scalability, and reliability since most of the time, it is dependent on the external application. CORBA on the other hand focus more on the business needs and has incorporate almost all the fundamental requirements of an ideal distributed system. Although we cannot completely claim that CORBA is a much better alternative since Web Services do have some unquestionable qualities, we can safely admit that built-in mechanism is far better reliable than user selected approach. Moreover, the fact that Web Service on its own is not “object-oriented” is something we should be all concerned about. CORBA’s security for instance, is much better than the dealing security issues in the transport protocol itself since any breach on the layer will compromise the entire system. Apparently, an added or direct safety features are more logical and practical than relying on securities provided by a “universal HTTP” (Gray 2004, p.1). 5. Conclusion CORBA enables interconnection, intercommunication, and interoperability of distributed application software in an enterprise and it is indeed potentially useful and reliable. The ORB or the Object Request Broker allows objects in different processes to interact similar to a single environment on a single computer. CORBA has been making its name in various industries such as Banking and Finance, E-Commerce, Telecommunications etc. Its client/server coupling is definitely tighter than Web Service and its Portable Object Adapter (POA) combined with Fault-tolerance features ensures reliability and scalability. Furthermore, IR or Interface Repository, Implementation Repository, and the Dynamic Invocation Interface are commendable CORBA standard in efficiently processing client request. Web Service on the other hand through standard, flexible, and inherently extensible data format like XML and a lightweight XML based protocol like SOAP is undoubtedly solving various key technology requirements. Although CORBA seems to outsmart Web Services in some important areas of distributed computing, the balance between them still exists. They may also work together since CORBA can sit on top of a SOAP application if permitted. Furthermore, the difference between Web Services and CORBA is probably motivated by the nature of task and simplicity of implementation, object orientation, and need for performance and therefore are not exclusive and should coexist as harmonizing technologies. 6. Reference List Balen Henry, 2000, Distributed Object Architectures with CORBA, Published 2000 Cambridge University Press, ISBN 0521654181 Gokhale Aniruddha, Kumar Bharat , and Sahuguet Arnaud, 2002, Reinventing the Wheel? CORBA vs. Web Services, ISIS, Vanderbilt University Nashville, TN 37203, online, http://www2002.org/CDROM/alternate/395/ Gray N.B.2004 , Comparison of Web Services, Java-RMI, and CORBA service Implementations, School of Information Technology & Computer Science, University of Wollongong, New South Wales, Australia Horstmann Cay S. and Cornell Gary, 2003, Core Java 2, Published 2003 Prentice Hall PTR, ISBN 0130927384 OMG, 2001, The Common Object Request Broker: Architecture and Specification, Object Management Group Inc. Sadiq Waqar and Cummins Fred, 1998, Developing Business Systems with CORBA, Published 1998 Cambridge University Press, ISBN 0521649994 Spaniol Otto, Linnhoff Claudia, and Meyer Bernd, 1996, Trends in Distributed Systems: Corba and Beyond: International Workshop, Published 1996 Springer, ISBN 3540618422 W3C, 2004, Web Services Architecture, W3C Working Group Note 11 February 2004, MIT, ERCIM, Keio Wang Shan, 2004, Conceptual Modelling for Advanced Application Domains: ER 2004 Workshops, Published 2004 Springer, ISBN 3540237224 Read More