Comparison of CORBA and Web Services - Essay Example

Running Head: A COMPARISON OF CORBA AND WEB SERVICES A comparison of CORBA and Web Services [The Writer’s Name] [The Name of the Institution] A comparison of CORBA and Web Services Abstract It is feasible that prior to discussing CORBA, one important concept we must know about it which is distributed systems. Actually, Distributed systems have been in existence, in one form or another, for some time, although they haven't always been named the same and they certainly haven't always had the flexibility that they do now. To discover where CORBA fits in, let's briefly introduce the history of distributed systems. Background Before distributed systems developed, there were three different system models. At beginning, Monolithic Systems and Mainframes are along with come hierarchical database systems and dumb terminals also recognized as green screens. On account of this, Software systems composed for mainframes were frequently monolithic. That is the user interface, business logic, and data access functionality was all controlled in one large application. By reason of this, one more flexible model came into being which Client/Server Architecture is. With the start of PC accomplished a notable model shift from the monolithic architecture of mainframe-based applications; many applications simply did not have need of the massive power of mainframes. So client/server applications characteristically distributed the components of the application so that the database would reside on the server (whether a UNIX box or mainframe), the front end would be located in the client, and the business logic would exist in either, or both, components. However, one problem came out is client/server was not without error of its own, because database access functionality and business logic were often contained in the client component, every change in the business layer logic, database access method, or even the database itself, frequently demanded the deployment of a new client component to all the users of the application, such frequent amendments would divide earlier versions of the client component, resulting in a fragile application. (Gollmann, 1998, 62-70) So the next more utility and flexible evolution is Multitier Client/Server which was an application can have any number of tiers conceptually, but the most popular Multitier architecture is three-tier, the partition of the system into three logical layers: the first one user interface layer, the second one is business rules layer, and the last one is database access layer. Because of it, the Multitier client/server architecture partitions the application into more components than traditional two-tier client/server; it also allows more flexibility in deployment of the application. Whereas, if we can discover a system model simply exposes all functionality of the application as objects, each of which can use any of the services offered by other objects in the system, or even objects in other systems. That is to say blur the distinction between "client" and "server" as a result the client components can also create objects that behave in server-like roles. This Distributed System provides the ultimate in flexibility. (Wang, 2003, 22-24) The distributed system design attains its flexibility by implementing the definition of specific component interfaces. The interaction of a component denotes to other components what services are offered by that component and how they are used. CORBA and other Web Services Comparison No operator system installed in computers can not use; no application software in Internet for integration can't reveal Internet's fascination. Development of distributed application software in Internet must solve several problems: Different platform---software will distribute at different platform, such as PC, laptop, PDA and DSP. Different operator system: There are various operator systems in this computer world: windows, UNIX, Linux, Solaris Os. Different programming language: Nowadays, there hasn't a universal and all-purpose programming language in our programming field: Java, Delphi, C++ builder, Visual Basic, Visual C++. Different protocol: Software applicants at different field in Internet can have different network configuration and transmission protocol. Different version of software: Software must be update because of the maintenance. Every change must need software engineer re-write the program module. CORBA can satisfy this requirement of distributed application software design and effectively solve these problems. In 1991 the first version of CORBA 1.1 was launched by Object Management Group (OMG) and defined the Interface Definition Language (IDL) and the Application Programming Interfaces (API) make possible client/server object communication within a specific implementation of an Object Request Broker (ORB). December 1994 CORBA 2.0 introduced, describes true interoperability by specifying how ORB from different vendors can interoperate. CORBA 3.0 more powerful supports Java, Internet and CMM. In these days, computers connected by Internet, and that the application software connected by CORBA. CORBA features Distributed systems depend on the classification of interfaces between components and on the existence of various services (such as directory registration and lookup) available to an application. So CORBA offers a standard method for explaining the interactions between components as well as some tools to facilitate the implementation of those interfaces using the developer's choice of languages. In addition, the OMG specifies a wealth of standard services, such as directory and naming services, constant object services, and operation services. (Object Management Group, 1997, 2) Services are defined in a CORBA-compliant manner, so they are available to all CORBA applications. Lastly, CORBA offers all the "plumbing" that permits different components of an application--or of separate applications--to communicate with each other. In other words, it allows applications to communicate with one another no matter where they are located or who has designed them. Two more features that CORBA presents a rarity in the computer software regime are platform independence, which CORBA objects can be used on any platform for which there is a CORBA ORB implementation, and language independence, which CORBA objects and clients can be implemented, in just about any programming language. Benefit of CORBA We can use any information or data which is wherever it is We can automatic process diversified information and data which is designed by any programming language in any companies We can optionally change the transaction processing flow in order to implement dynamic management. We can work together for the big project even though our partners use different programming language. If a software modules accord with CORBA software modules, it is important information that can be using at anytime and anywhere. Developing process effectively: Because the software modules completely integrate others. If we use CORBA manner to develop, we can use the existent modules, which had been designed. Use CORBA manner to programming, software's version can compatible with the last version. In nature, CORBA will achieve the software's Plug and Play (PnP) in Internet. CORBA architecture and its components Hereinbefore, we known CORBA's history and saw how the CORBA architecture fits into the world of client/server application development. At this part, we will discuss CORBA architecture and its components. So it can make us more deeply understanding CORBA. The ORB is the middleware that sets up the client-server associations between objects. Using an ORB, a client can obviously call upon a method on a server object, which can be on the same machine or across a network. The ORB interrupts the call and is liable for locating an object that can execute the request, pass it the variables, call up its method, and return the results. The client does not have to be ORB gives interoperability between applications on various computers in response of where the object is found, its programming language, its communication system, or any other system features that are not part of an object's interface. In doing so, the varied distributed surroundings and seamlessly communicates multiple object systems. (Vinoski, 1997, 46-55) Platform Independence An invention of the marshaling/unmarshaling procedure is that, because parameters are transformed upon broadcasting into a platform-independent format (the on-the-wire format is provided as part of the CORBA specification) and converted into a platform-specific format upon reception, the communication between components is platform-independent. This defines that a client running on, for instance, a Macintosh system can invoke methods on a server running on a UNIX system. In addition to independence of operating system used, differences in hardware (such as processor byte ordering, or endings) are also rendered irrelevant because the ORB automatically makes these conversions as necessary. In essence, the ORB accounts for word size, any differences in platforms--be it operating system, and so on. The Interface Definition Language (IDL) The other CORBA architectural cornerstone If the idea of the Object Request Broker is one basis of the CORBA design, the Interface Definition Language (IDL) is the other. IDL, as its name advocates, is the language used to define interfaces between application modules. Note that IDL is not a procedural language; it can define only interfaces, not implementations. C++ programmers can reflect of IDL descriptions as equivalent to header files for classes; a header file characteristically does not have any accomplishment of a class but rather explains that class's interface. Java programmers might liken IDL definitions to definitions of Java interfaces; again, only the interface is described--no execution is offered. (Lang, 1997, 121-25) Language Independence The IDL language comes with the standard CORBA characteristic and is not dependent on any programming language. It attains this language independence through the idea of a language mapping. Language independence is a very important feature of the CORBA architecture. As CORBA does not attributed to a specific language to use, it provides programmers and software developers the freedom of choice to select whichever programming language they want to use and which best fits the requirements of their applications. Taking advantage of this interface independence, developers can also select different languages for various modules of an application. For example, the client module of an application may be defined using Java language, which guarantees the clients can run on virtually any kind of computer system. The server modules of that application might be written in C++ for high performance. CORBA enables various components to communicate one and other. Use synthetically ORB and IDL In implementing typical client/server applications, Programmers uses own designed or a recognized standard to define the protocol to be used between the electronic devices. Defining protocol definition developers depends on various factors such as, on the implementation language, network transport and a dozen other. ORB provides the solution of the problem. ORB, defines the protocol through the application interfaces via a single implementation language-independent specification, the IDL. And ORB provides flexibility. In return let developers select the most powerful and appropriate operating system, implementation environment and even programming language to use for each component of a system under construction. CORBA Process The procedure of developing a static CORBA server and client is defined in detail as below: First of all, specify the server interface using IDL, through the user interface. It will produce a native language interface when run the IDL explanation through an IDL compiler. Simultaneously, the user can also have the access of the user application and implement object. During the IDL compiler (C++, Java), it associate and skeleton to the core C++ and Java compiler as the same objective with the user application and implement object. Using ORB at the end registers the server in the execution depository, bind and invoke between the server and client. The Future of CORBA CORBA on the road of object-oriented standardization and interoperability is a signal step that provides, users’ access to information clearly, without any prior knowledge of software or hardware platform, resides on or where it is located on an enterprises' network. The integral part of object-oriented systems is transportation; CORBA gives true interconnect ability to today's computing environment. CORBA is getting popular rapidly evident from this fact that the membership of more than 750 and still growing, the OMG has certainly got a position of great significance in the market. As a standard it (CORBA) has been proceeding and growing for more than seven years now. CORBA goods are available in variety of platforms and operating systems from various vendors. (Among the platforms supported by CORBA are MacOS, MS-DOS, OS/2, SunOS and Windows 95, 98, 2000, XP, Windows NT, 2000 Server, 2003 server.) Clearly, CORBA has developed from its humble start into a recognized, mature stage for distributed application development. Around the clock enhancements are being incorporated in CORB. Now you've experienced some of the enrichments currently suggested, from horizontal features such as a CORBA object design, facilitation for various languages, and support for passing objects by value, to specifications for vertical facilities such as the healthcare, telecommunications, and manufacturing industries. The OMG has designed plans for CORBA development, and with the backing of a plethora of vendors producing CORBA products, these plans are being realized. CORBA has already grown a powerful, strong platform for the expansion of distributed enterprise applications and is well on its way to becoming far more useful than it already is. In prospective days, CORBA will not only become more effective, powerful and strong, but it would also become more incorporated with application development. The future definitely has some exhilarating things in stockpile for CORBA and its developers. For many years, middleware has been utilised to grip data movement across incongruent platforms and between irreconcilable databases. In accumulation, middleware has made it effortless for developers to tackle the differences between databases and platforms by writing applications that join to the middleware stratum and by letting the middleware hold the data transport and translation (Talarian Guide, 2000, 8-10). There exist a sequence of interconnected idea about middleware, and particularly examine two types of middleware: Object Request Brokers (ORBs) and Message-Oriented Middleware (MOM), both are challenging to develop into the network standard for connecting inheritance systems to the web. Ultimately, by comparing of their benefits and boundaries, the exact sort of middleware, which is far better apt to do the work, is suggested. Introduction of middleware Middleware is the broad variety of services encrusted between the implementations and an operating system that offer interoperability and focused services between disseminated applications. As regards to this, for a multiplicity of reasons comprising the reality that middleware is a comparatively fresh group of software, the functionality of diverse sorts of middleware is not harmonized (Wang, 2003, 22-24). For example, the chief purpose of operational processing middleware is to do with management, but many transactions and with it, certain processing stuffs also comprise communication services of various kinds. Middleware vendors append functions guarantee that their products interoperate with a diversity of software and hardware and to help distinguish their product from their competitors. Since each product in a middleware category based upon a multiplicity of functionality and for the reason that the standard roles within each category modify swiftly, helpful differences among middleware services are tough to locate. At current stage, the middleware market can be broken into five different segments: 1. Transaction processing monitors (TPM) 2. Remote procedure calls (RPC) 3. Object request brokers (ORB) 4. Home grown middleware solutions 5. Message-oriented middleware (MOM) (Talarian Guide, 2000, 8-10) Amongst these, we are going to pacifically analyse two of them, Message-oriented middleware (MOM), which is already in mature stage, and Object request brokers (ORB), the newest form of middleware. What is Message-oriented middleware (MOM)? Message-oriented middleware (MOM) is definitely a server/client infrastructure that intensifies and enhances the portability, interoperability, and flexibility of an application by permitting the application to be delivered over manifold heterogeneous platforms. It decreases the intricacy of developing applications that cross multiple network protocols and operating systems by shielding the application developer from the particulars of the different network interfaces and operating system- Application Programming Interfaces (APIs) that expand across varied networks and platforms are characteristically afforded by the MOM (Rao, 1995, 89-96). How does MOM work? MOM is a definite category of middleware that helps the substitute of general-purpose messages in a dispersed application setting. Data is supposed to be exchanged by message queuing and/or message passing supporting both asynchronous and synchronous connections between strewn computing procedures. Generally, it is most intimately recognized with asynchronous messaging utilizing queuing. MOM conveys messages from one application to the other using a queue as a temporary measure. Client messages, on the other hand, are sent to a queue and stay there until they are recovered by the server application. The MOM system guarantees message delivery by utilizing dependable queues and by affording the security, directory as well as administrative services mandatory to support messaging. (Brose, 1999, 237-52) The benefit to this system is this that the server application does not require to be obtainable when the message is conveyed; in its place, the server can repossess the message all the times. In accumulation, since messages can be recovered off the queue in any command, MOM can also assist recovery of messages by means of hierarchy or load-balancing schemes. MOM may also provide a certain point of fault-tolerance by bringing in importunate queues that permit messages to be recollected in case if system fails. (Blobel, 1998, 29-38) What is Object Request Broker (ORB)? The Common Object Request Broker Architecture (CORBA) is designed as a standardized, vendor- and operating system-independent technology for client/server, object-oriented application integration. An Object Request Broker (ORB) is a type of middleware, standardized in CORBA, which enables client-server relationships between objects. It also can be thought of as language-independent, object-oriented RPCs. Object Request Brokers (ORBs) represent a robust solution for building enterprise-strength OO applications. Current ORB offerings include CORBA, COM, and Enterprise Java Beans. The primary role of an ORB is to facilitate communication between distributed components. (John, 1999, 55-60) How does ORBs work? ORBs are designed for use in projects that require a strict object-oriented approach, where "objects are the only way." Like RPCs, ORBs are generally synchronous and operate in a point-to-point manner. When applications communicate, one application sends a request to the ORB, which then finds the appropriate object from the answering application to fulfil the request, feeds it the parameters of the request, performs the object's function, and then relays the result back to the requesting application. This essentially shields communicating applications from having to understand how to navigate within each other. ORBs provide all of this inter-process sharing magic via interfaces. More importantly, ORBs support independent interfaces. An independent interface defines the shared operations and attributes of the underlying logic without regard to the implementation. ORB-based interfaces are defined separately from any implementation code using Interface Definition Language (IDL), another part of the CORBA standard. IDL is designed to help developers avoid building any specialized protocols specific to the interaction of a particular collection of applications. Because IDL supports the independent definition of an interface, developers can use a shared component without knowing or caring how the implementation is accomplished, or even whether it's actually an object on the other side. (Beznosov, 1999, 19-30) Interfaces, particularly as supported by ORBs, present an opportunity to design a truly plug-and-play architecture at the software level. Custom objects, legacy systems and packaged software can all be packaged in an infinite number of combinations and made available as business-related interfaces. Comparison of MOM and ORBs: Broadly speaking, both DCOM and CORBA presume that the system has a dependable communications sheet, and they do not concentrate on the problems implicated when this layer is not consistent. On the contrary, MOM does not suppose the system has a dependable transport sheet at the very base. MOM tries to address the problems that surface when the transport layer is unreliable, as when programs must communicate over a WAN or the Internet. Object middleware is very flexible and easy to use; however, it can't scale to the large transactions such as message-oriented middleware. Furthermore, the degree of standardization is far higher for CORBA products than for message-oriented middleware. (Sohn, 1999, 24-55) While Message-oriented middleware is more difficult to use than object-oriented middleware, it is mainly because of the need to "hand-code" marshalling. Which one should we choose? Message-oriented Middleware (MOM) and object Request Brokers (ORBS). Both are competing to become the network standard for linking legacy systems to the web. But which one is better suited to do the work? Normally, which middleware we should choose to do the work depends on different situation. For example, The advantages of message oriented middleware are that it is performance in real-time applications such as dealing floors, supported by some big industry names and is good match to a distributed systems strategy and to an 'event driven' business model. Therefore, in the cases B2B application integration, MOM is the best choice in the case that bandwidth cannot support RPCs, or when a server cannot be dependent upon to always be up and running. MOM is also a good choice for communication between applications when networks are unstable. However, on the minus side MOM is invasive - participating systems and applications have to comply with the middleware. It is also often difficult to integrate with existing systems not designed for a message framework. MOM usually imposes a strong vendor lock-in, and solutions are typically relatively expensive. Therefore, distributed objects are useful in method-oriented integration thanks to their capability of providing an additional location for application processing and for interoperability among processes, thus creating an infrastructure for sharing methods. They work best, e.g. in a trading community. However, being the newest form middleware, the role of ORBs has been being expanded; it offers developers an easier time combining objects to build distributed applications. The Advantages of ORBs: * It is the best technology to integrate diverse platforms and languages, including C, C++ and Java. * CORBA supports communication between object-oriented applications. * It is an industrial standard, endorsed by a consortium of over 800 companies, which supply a whole range of products from which to choose. * Products are available on virtually any platform, including LynxOS. * CORBA 3 supports asynchronous message-queuing protocols as part of the base communications interfaces, so that messages can be passed on to methods for later execution. Conclusion From above mentioned evaluation, it may be asserted that, ORB is a sunrise middleware with the fresh technology in the middleware market. And also, with the rising reputation and development of ORB, it will be the enhanced middleware for connecting legacy system to the web. The reality behind ORBs is this: Many applications need access to the same set of services as well as to other applications. The reality of computing currently is heterogeneous computing hardware and operating system platforms, plus applications built with a wide variety of improvement languages and tools. To obtain all of those mechanisms interacting to each other, the venture needs a regular, object-oriented architecture. And with the growing requirement for applications in one corporation to split data with business suppliers or partners, this type of consistent approach can significantly abridge the integration task. References Beznosov, K. and Y. Deng, A framework for implementing role-based access control using CORBA Security service, in' Fourth ACM Workshop on Role-Based Access Control, Fairfax, Virginia, October 1999, pp. 19-30. Blobel, B. and M. Holena, CORBA Security services for health information systems, Journal of Medical Informatics 52(1-3) (1998), 29-38. Brose, G. A view-based access control model for CORBA, in: Secure Internet Programming: Security Issues for Mobile and Distributed Objects, J. Vitek and C. Jensen, eds, Lecture Notes in Computer Science #1603, Springer-Verlag, 1999, pp. 237-252. Gollmann, D. and U. Lang, Security in CORBA based electronic commerce systems, Information Security Technical Report 3(2) (1998), 62-70. John Hunt. JAVA and Object Orientation: An Introduction, Springer, London, 1999. 55-60 Lang, U. CORBA Security: Security aspects of the Common Object Request Broker Architecture. Master's thesis, Royal Holloway, University of London, 1997 121-25 Object Management Group, The Common Object Request Broker: Architecture and Specification, Revision 2.2, February 1998. (Formal /98-07-01) Rao, B. R. Making the most of middleware, Data Communications International, vol. 24, no. 12, pp. 89-96, 1995. Sohn, H. D. Kung, and P. Hsia, “State-based Reproducible Testing for CORBA Applications,” Proc. of IEEE Internat Symposium on Software Engineering for Parallel and Distributed Systems, PDSE’99 (Los Angeles, 1999), pp. 24–35. Talarian, A Guide to Selecting A Real-Time Infrastructure: Everything You Need to Know About Middleware, Talarian Corporation, 2000. Vinoski, S. CORBA: Integrating diverse applications within distributed heterogeneous environments, IEEE Communications Magazine 35(2) (1997), 46-55. Wang, J. W. Lu and W. Jia, “A New Architecture for Web-Based Virtual Laboratory with CORBA Technology”, in Proceedings of the Second International Conference on Web-based Learning (ICWL’03), 2003. 22-24 Read More