StudentShare
Contact Us
Sign In / Sign Up for FREE
Search
Go to advanced search...
Free

Comparison of CORBA and Web Services - Essay Example

Cite this document
Summary
The purpose of the paper "Comparison of CORBA and Web Services" is to take a closer look at the different technologies that are available today - a successful transformation of the Wells Fargo Bank may help us to comprehend different infrastructures and especially the CORBA and its comparison to Web Services. …
Download full paper File format: .doc, available for editing
GRAB THE BEST PAPER98.8% of users find it useful
Comparison of CORBA and Web Services
Read Text Preview

Extract of sample "Comparison of CORBA and Web Services"

CORBA and Web Services Introduction For years, the architecture of the internet and software have been developed to match the dynamic roles of the customer oriented companies. These companies and business entities including the government sector have evolved to generate the ever growing demand of the public. To take a closer look at the different technologies that are available today- a successful transformation of the Wells Fargo Bank may help us to comprehend different infrastructures and especially the CORBA and its comparison to Web Services. Wells Fargo was the first financial services company to support Internet Banking. The Wells Fargo Internet was implemented as a 3-tier architecture. The Internet is one of several applications implementing the "View" or "presentation tier". Other "presentation tier" implementations include the Wells Fargo Phone-Bank, which provides banking services via an Interactive Voice Response system. Applications implementing the view are called "Channels" in Wells Fargo terminology. Not unlike the evolution of the commercial Internet, the Wells Fargo system has grown from very humble beginnings (2000 remote calls per month) to much more impressive volumes (Khan & Zheng, 2004). Development of Web technologies At peak the systems support tens of thousands of users and processes thousands of requests per second. These volumes need to be supported in an environment that has no tolerance for downtime. The "database tier" is implemented almost entirely by mainframes and similar types of systems, which remain dominant in the financial services industry. There are also some very large RDBMS systems implementing less significant aspects of the model (Khan & Zheng, 2004). To a large extent the business-logic is implemented in the middle tier. Consequently it can be shared by the different channels of Wells Fargo Bank. The obvious benefit of this design is that business logic does not have to be implemented multiple times for different channels. It is not entirely possible to implement business logic in the middle-tier only once, because of differences in requirements. Business proponents of the different channel applications sometimes represent different interest groups or legal positions and do not always succeed in identifying one set of requirements (Khan & Zheng, 2004). The middle-tier provides a polymorphic view of the data stored by a very diverse set of backend systems. This is one of the most important and successful features of this component. Channel applications can represent account information in a consistent manner, representing many products such as savings accounts, loans (including mortgages), credit cards, and even stock portfolios. This feature allows bank customers to view account information from their personalized home page on the Wells Fargo Internet in addition to performing various self-service features such as money transfers (Khan & Zheng, 2004). To achieve this type of polymorphism the middle-tier performs a function best described as "data-scrubbing" (cleansing data from different data sources to improve data-consistency and data-integrity). This function is required because, in addition to using a diverse set of technologies, the different backend-systems also use a very different and partly overloaded business terminology, which results in often-incompatible data-dictionaries and data-layouts(Khan & Zheng, 2004). Discussion on CORBA The original implementation of the system was based on an early CORBA Object Request Broker, the “ObjectBroker” from DEC. The technique used to implement this "concurrent fan-out" was based on a feature of the DEC ObjectBroker ORB (OBB) used by the CORBA-based distributed applications, which enables Asynchronous Messaging. In the CORBA environment the middle-tier was built using several different levels of server processes. The lower level of processes would be dedicated to communicate with a particular backend system. The higher-level server, responsible for the fan-out, calls the lower-level CORBA servers asynchronously, which resulted in the desired parallelism (Coulouris et al, 2005). Another noteworthy feature of the CORBA-based solution was that the middle-tier servers were almost entirely stateless. No customer or session-specific information ever resided on the middle-tier in-between invocations. Instead, all relevant state information was passed to the channel application as part of CORBA object references. In subsequent calls to the middle-tier the client unwittingly passed the object references back to the server and the server was able to re-materialize the object-graphs discovered during the previous invocations from the data cached in the object references (Coulouris et al, 2005). Pitfalls of CORBA This approach created a highly scalable solution because customer sessions were not tied to a particular middle-tier machine. Calls in a session were routed to any available machine, no matter what where previous calls where processed. This also meant that by adding additional machines the performance of the system scaled almost linearly. The CORBA-based system was also implemented without using distributed transaction technologies, i.e., no two-phase commit was mandated by the requirements of any of the applications. It turns out that there are very few use-cases in retail banking that justify the relatively high-cost of distributed transactions managers because very few customers simultaneously use Internet Banking, the IVRU and ATMs (Coulouris et al, 2005). This is particularly surprising since much of the literature regarding distributed transaction management is focused on banking environments. The support for the ORB used by Wells Fargo Bank was about to expire and the ORB vendor was unable to provide a feasible migration strategy for the roughly 5 million lines of existing code. This was the main reason that while the CORBA-based solution was very successful, a rewrite of most of the functionality was unavoidable (Coulouris et al, 2005). Another problem with the CORBA system was interoperability. The ORB was written before IIOP was defined. This made it very difficult to integrate with other CORBA solutions or use platforms such as Java, which were never supported directly by the ObjectBroker ORB. These problems proved to be a limiting factor in one of the key initiatives at Wells Fargo, known as "Any to Any". This initiative aims to ensure that every system in the bank can communicate with all other systems, if a use-case exists that requires such communication (Umar, 2004). Middleware development teams were required to keep experts on staff in order to be able to deal with proprietary nature and the complexity of the underlying technology. This need for experts limited the number of teams that could afford to use this technology on a large scale. The limited number of teams meant that the few teams providing support for distribution risked becoming bottlenecks in the development process. Versioning was another issue with the CORBA solution. Clients and server code was tightly coupled, which tended to make even the smallest changes very expensive. Minor modifications on the server side often required all clients to be redeployed, which resulted in high costs considering the client software was deployed on thousands of different machines (Umar, 2004). Advantages of Web Services as compared to CORBA When replacing the CORBA-based distributed application platform the goal was to retain the benefits of the old system, but remove some of the inherent liabilities to create a simpler, faster, cheaper, and more reliable solution. Another goal was to make the development process more cost effective and predictable. Web-Services in general and SOAP in particular were identified by the Enterprise Architecture team as the desired suite of communication protocols and standards for distributed applications. The rapid and not always predictable evolution of SOAP and Web-Services standards put an additional burden on the development teams (Umar, 2004). The resulting uncertainties required consideration both from the software architecture perspective as well as from project management. The use of XML-based protocols immediately enabled larger number of teams and team members to create components and applications that produce and consume XML. Unfortunately this also means that the enterprise ends up with a large number of solutions that may interpret more complex standards, such as XML-schemas or SOAP, very differently. This leads to a new set of interoperability problems that eventually must be resolved (Umar, 2004). The new application server-based solution replacing the high volume, mission-critical CORBA-based application uses a strictly layered architecture. A "distribution layer" isolates the business logic from being exposed to Java-bindings used by the distribution technology. This encapsulation makes it simpler to react to changes in the standard as well as to support business partners. This flexibility is required because of previously mentioned interoperability problems (business partners occasionally keep insisting on a reading of standards that may not be entirely comply with the mainstream interpretation) (Umar, 2004). In a similar fashion the business logic is also isolated from the details of components used to communicate with mainframe systems and databases through a persistence layer. Adjustments to the backend systems therefore cause fewer changes to the rest of the application server code. It also enables the middle-tier teams to test the connectivity and functionality of the backend systems in isolation. Additionally, this layer is a very good place to add a "backend-simulator", which helps to decouple the development effort of the backend systems from the middle-tier. Such a simulator is also very useful for functionality and performance testing (Umar, 2004). Evolution of Web Services Java replaced C/C++ as the implementation language to take advantage of a more productive, modern platform. The added benefit is that Java also produces more portable applications. Portability, at least in theory, creates more competition among hardware vendors. The new application server architecture does not use any J2EE functionality other than Servlets. The servers initially were built as J2EE applications using Enterprise Beans but have evolved very quickly beyond this design. Eliminating Enterprise Beans from the servers removes a distribution layer that was not useful, hence simplifying the solution and reducing latency (Umar, 2004). Like their predecessor systems the new servers still do not need to support any use-cases that would require transaction semantics, interact very little with RDBMS systems, and typically do not use Message Oriented Middleware to communicate with mainframe systems. As result there are few benefits to using Enterprise Beans. The J2SE-based application-servers are stateless much like the original CORBA-based system. They do not retain any session or other customer-related state in-between servicing remote calls. Because SOAP does not really support objects and does not have the equivalent of an Object Reference, a new technique was implemented by the application development teams (Umar, 2004). Working of Web Services to attain advantages that older architecture could not provide This technique is based on the Memento design pattern. Object graphs are marshaled into tokens, which are passed on to the channel applications. In order to reduce latency channel developers are expected to pass these tokens back to the server as optional input parameters for subsequent calls. The use of the Memento tokens is optional. The only penalty for omitting such tokens in calls is additional latency because object-graphs need to be re-materialized by calling the backend systems repeatedly. Since reducing latency is a primary focus of all development projects in the bank there are few channel developers who choose not to use Memento tokens (Umar, 2004). The HTTP protocol used by the present generation of application servers represents a simplification over the previous CORBA based solution. The implementation of the GIOP protocol used by the ObjectBroker ORB creates a significant overhead because tasks, such as discovering and managing available object implementations and servers, are no longer required. Typically, multiple TCP/IP connections had to be made with the ObjectBroker solution to execute a single remote call. The more basic HTTP protocol relies on "well-known ports", which can be effectively managed by even the most basic server load-balancer solutions (Birman, 2005). Load-balancers and the fact that application-servers are stateless create a very simple, but at the same time scalable and robust solution. Scalability is archived by adding machines behind the load-balancer, which increases the capacity of the overall solution in an (almost perfectly) linear fashion. The solution is robust due to the high number of redundant servers and server instances that are front-ended by the load-balancer. Loadbalancers are able to detect if one of the instances fails and will stop routing traffic to the malfunctioning components. In contrast, CORBA implemented scalability and fail-over features in a much more convoluted fashion, which resulted in systems that are more difficult to nderstand and manage (Birman, 2005). When using the HTTP protocol only one connection has to be created to access information on a remote server, which also greatly reduces the latency of the distributed call. The elimination of CORBA calls within the middle-tier seems to be the primary reason that the present Java-based solution outperforms the original C/C++-servers. Remote calls inside the middle-tier are no longer necessary because the "concurrent fanout" was implemented using multi-threading rather than Asynchronous Messaging. Multiple levels of application servers are no longer required (Birman, 2005). This change represents another significant simplification. Instead of managing a large number of server processes organized in multiple levels the present J2EE solution relies on a comparatively smaller number of processes that have an identical code-base and configuration. As a result of the relative simplicity of SOAP and HTTP it is comparatively easy to acquire or even create client and server infrastructures that support these protocols. As a result many more hard- and software platforms can be used with this approach than with CORBA. Consequently the "Any to Any" initiative mentioned before has substantially benefited from the change to simplified protocols (Birman, 2005). As also previously mentioned the downside of this large number of components that implement the web services standards is the lack of uniformity between them. These problems are likely to make it increasingly difficult to grow the "Web-Services stack" as aggressively as the proponents of this technology hope. Similar incompatibilities seemed to have limited the propagation of CORBA. It is apparent that within even this simplified solution the demand for "experts" has not decreased. After all, most of the problems that require management when building large-scale, high-volume, low-latency distributed application do not change when swapping protocols and infrastructure components. The analysis, design, implementation, and diagnostic skills of the "experts" are still invaluable and hiring qualified senior engineers remains a difficult task (Meersman, 2002). Lastly, "looser coupling" between client and server applications was not realized in the environment described here, even though the solution was based on modern standards that claim to foster loosely coupled architectures. It appears that there is little flexibility to foster "looser coupling" built into standards such as SOAP. A low-latency environment with clients and server using SOAP still depends on a well thought-out and executed versioning strategy. For example, XSLT and similar technologies do not seem to work in environments where adding 100ms to a call is considered a drastic and unacceptable increase in response time (Meersman, 2002). Building high-performance, mission-critical applications for the enterprise remains a complicated undertaking involving costly analysis and design. For most project teams replacing distribution technologies with a more "fashionable" alternative is little more than a distraction from the task at hand. In many cases it is hard to see how the end-users will significantly benefit from this type of change. Instead of chasing the latest buzzword or industry trend, it seems more productive to use good software design principles to strictly isolate the distribution aspects of an application from its actual core, the business logic (Meersman, 2002). Future and Conclusion The strictly layered architecture is an invaluable tool for implementing applications in this manner. Using this type of design is initially more expensive, but it helps to isolate many types of changes. It typically only requires a small sub-team to implement a new "distribution layer" when support for another distribution technology is needed. To promote this approach a new generation of tools that automates the creation and maintenance of "distribution layers" would be extremely beneficial. Instead of utilizing the classic methods of "skeletons" & "stubs", or the interface conventions of technologies like EJBs, these tools should be able to work off existing code. They have to be able to add the bindings required to support distribution technologies without introducing any modifications of existing code. Aspect Oriented Programming seems to have demonstrated the feasibility of this type of tool in other areas of software development. These tools would enable "application transparent distribution" and eliminate the need for developing and maintaining "distribution layers", without loosing any of their benefits. Works Cited: Umar, Amjad. Third Generation Distributed Computing Environments. Nge Solutions, 2004. Khan, Khaled & Zheng, Yan. Managing Corporate Information Systems Evolution and Maintenance. Idea Group Publishing, 2004. Birman, Kenneth. Reliable Distributed Systems: Technologies, Web Services, and Applications. Springer, 2005. Coulouris, George et al. Distributed Systems: Concepts and Design. Addison Wesley, 2005. Meersman, Robert & Tari, Zahir. On the Move to Meaningful Internet Systems. Springer, 2002. Read More
Cite this document
  • APA
  • MLA
  • CHICAGO
(Comparison of CORBA and Web Services Essay Example | Topics and Well Written Essays - 2500 words, n.d.)
Comparison of CORBA and Web Services Essay Example | Topics and Well Written Essays - 2500 words. https://studentshare.org/information-technology/1711987-a-comparison-of-corba-and-web-services
(Comparison of CORBA and Web Services Essay Example | Topics and Well Written Essays - 2500 Words)
Comparison of CORBA and Web Services Essay Example | Topics and Well Written Essays - 2500 Words. https://studentshare.org/information-technology/1711987-a-comparison-of-corba-and-web-services.
“Comparison of CORBA and Web Services Essay Example | Topics and Well Written Essays - 2500 Words”. https://studentshare.org/information-technology/1711987-a-comparison-of-corba-and-web-services.
  • Cited: 0 times

CHECK THESE SAMPLES OF Comparison of CORBA and Web Services

RESTful Web Services

This literature review "RESTful web services" presents the RESTful web services and the way these web services differ from Big Web Service techniques.... REST has become very popular across the Web as this software architecture is considered as a simpler alternative to SOAP and WSDL based web services.... These providers have deprecated the software architectures like SOAP and WSDL based web services as they believe that REST is easy to use and exposes their services in an effective manner....
10 Pages (2500 words) Literature review

E-Business in the Car Industry

web markets widen the market choices availability to buyers, giving sellers access to incoming customs and reducing costs for transaction.... The online advantage is that the customer can have comparison on all products available and use the intermediaries in conjunction to compare various manufactures and brands....
17 Pages (4250 words) Essay

A comparison of CORBA and Web Services

Distributed Applications refer to the applications which can be distributed across different processors and computer systems.... his concept helps in deploying an application across systems on a network which might be working a common project or an application.... hellip; 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):There are some applications which might need to access common data Distributed Applications refer to the applications which can be distributed across different processors and computer systems....
16 Pages (4000 words) Essay

Web Services Security

web services allow accessing information on the global internet.... The value of the web services are well recognized not just by the managers and executives.... … The value of the web services are well recognized not just by the managers and executives.... Every business wants to use web services and extend it beyond the boundaries of their organization.... It is possible to keep the web services secure although for small organizations it may be costly....
4 Pages (1000 words) Essay

Service Oriented Architecture and Web Services

Agility, flexibility and re-usability are the key success factors for application and web services providers.... Aberdeen (2007) notes, “Organizations that are focusing on SOA infrastructure are outperforming those that are deploying only web services.... The IT architecture requires seamless merging with the business… services act as the pipeline of electronic data interchanges.... SOA is a “view” of the architecture that focuses on services as the action boundaries between needs and capabilities....
4 Pages (1000 words) Essay

Information Technology Architectures

Among the advantages of corba process, is its level of maturity, CORBA developed by the Object Management Group and its standard is neither too lax nor too restrictive.... dvantages of the Java 2 Enterprise Architecture (J2EE)The Java 2 Enterprise Architecture (J2EE) consists of a security model which protects data both in web-based application and also locally.... It will also propose the advantages and disadvantages of the same development processes for distributed systemsCommon Object Request Broker Architecture (corba)corba is an acronym for common object request broker architecture....
2 Pages (500 words) Essay

Interoperability of Web Services

… Interoperability of web servicesIntroductionIn the interoperability of web services, the supplier has multiple customers.... The suppliers Interoperability of web servicesIntroductionIn the interoperability of web services, the supplier has multiple customers.... The system will have an option of denying the credit request by the customer, but it should have an option of accepting credit also as the supplier has to provide credit for the post paid customer in the case of services sector....
12 Pages (3000 words) Coursework

Web Server Approach: Simple Object Access Protocol

The groundwork or base level of web services protocol stack is formed by SOAP, which enables a structure of fundamental messaging which can accommodate multiple layers' building (Box, Ehnebuske, Kakivaya, Layman, Mendelsohn, Nielsen, Thatte and Winer, 2000, 56).... hen the web applications and computing networks are being distributed, request in terms of running of one application is transferred from one network computer, which is also called the client computer to another network computer, which is also called server computer with the help of internet and on internet (Box, Ehnebuske, Kakivaya, Layman, Mendelsohn, Nielsen, Thatte and Winer, 2000, 59)....
12 Pages (3000 words) Assignment
sponsored ads
We use cookies to create the best experience for you. Keep on browsing if you are OK with that, or find out how to manage cookies.
Contact Us