Unformatted text preview:

AbstractToo Much MiddlewareMichael StonebrakerEECS DepartmentM.I.T.AbstractThe movement from client-server computing to multi-tier computing has created a potpourri ofso-called middleware systems, including application servers, workflow products, EAI systems,ETL systems and federated data systems. In this paper we argue that the explosion in middlewarehas created a myriad of poorly integrated systems with overlapping functionality. The worldwould be well served by considerable consolidation, and we present some of the ways this mighthappen. Some of the points covered in this paper have been previously explored in [BERN96]. 1. IntroductionA typical Fortune 1000 company has a myriad of mission critical data systems on which theenterprise depends. Such systems include ERP systems, sales tracking systems, HR systems, etc.Over the last twenty years, the conventional wisdom was to implement such applications using aclient-server computing model as noted in Figure 1. Here, the DBMS (or other storagetechnology) ran at the server level, accessed by a collection of applications which ran on theclient desktop. Client-server computing was enabled by the emergence of desktop PC’s whichprovided a client computing platform, and was pushed by many software and hardwarecompanies, that were selling alternatives to IBM mainframes. client serverFigure 1. Client-server ArchitectureRecently, several factors have rendered client-server computing completely obsolete, but we willfocus only on the web in this paper. Basically, it forces every enterprise to move to thearchitecture of Figure 2. The client level from Figure 1 moves inside a web browser, where atmost a portion of the application from Figure 1 can run. Sometimes an ultra-thin client is run,whereby no code exists at the client level. Other enterprises utilize Java, Javascript, or othertechnology to run some code on the client desktop. In either case, the remainder of theapplication must be executed in a new middleware tier.The web also enables cross-enterprise e-commerce applications. In this world, the client is inanother organization outside the enterprise firewall, and it is typically impractical to run much (ifany) application code at the client level. Again, the thin client architecture of Figure 2 isessential.This switch from Figure 1 to Figure 2 creates a new tier of computing, commonly calledmiddleware. Moreover, it has created several new classes of products, that run at this level. InSection 2 we will review the major classes of products that fit in this category. Then, in Section 3we show that the various product classes have dramatic overlap in functionality. Moreover, thisoverlap will likely increase in the future. We then argue that this product overlap is very bad forcustomers, leading to complex and inefficient environments. Lastly, in Section 4 we projectsome scenarios, whereby a consolidation of middleware products could occur. client middleware serverFigure 2. Multi-tier Architecture2 Middleware ProductsIn this section we will discuss six classes of middleware products, namely application servers,enterprise application integration (EAI) systems, workflow systems, enterprise portals, datafederation systems, and extract, transform and load (ETL) products. For each kind of system, webriefly describe its core functionality and its reason for existence.2.1 Application ServersApplication servers have been in existence for more than twenty-five years. Historically, theywere called TP monitors, the most popular being the IBM Customer Information and ControlSystems (CICS). Recently, the category has been renamed application servers, and includesproducts such as Silverstream, Dynamo from ATG, Web Logics from BEA Systems, Bluestone(now owned by HP), Cold Fusion from Allaire and WebSphere from IBM. TP monitors came into existence to allow multiple client users to run the same applicationefficiently on a mainframe computer. Specifically, they provided application activation. Toperform efficiently, they also provided multi-threading of applications (that were written to allowthreading) and connection multiplexing. The latter feature lowered the number of connectionsthat had to be maintained between the middleware layer and the server level, typically increasingefficiency. To provide scalability, many application servers support automatic load sharing overmultiple hardware machines. Lastly, most provide a security module including authentication,single site login, and access control. In summary, an application server is capable of providing code activation and related services.Since the underlying operating systems were slow to provide multithreaded execution, this classof products developed a foothold. More recently, the architecture of the web created a need forweb servers to execute web protocols and CGI programs. This naturally evolved into full-fledgedweb-oriented application servers.2.2 EAI ProductsA typical large enterprise has more than 5000 major application systems. Such systems arealways logically interconnected. For example, when a new employee is hired, he must beinserted into the payroll systems, added to the pension plan, added to the medical insurancesystem, etc. When a customer changes his telephone options, a change must be made to thebilling system as well as to the provisioning system. Whenever two companies merge, there are two sets of information systems to contend with, onefrom each of the partners. It is desirable, but rarely possible, to kill one of the two overlappingsystems, at least not immediately. Again, multiple interacting application systems are part of theresulting enterprise architecture.A last example arises in e-commerce. The purpose of a net market is to connect a transactingbuyer and seller. Here, transaction information must be communicated from the net marketapplication to the procurement system of the buyer and the order processing and fulfillmentsystems of the seller. Again, multiple interacting applications are present.To service the needs of interacting application, a class of products called enterprise applicationintegration (EAI) systems arose. The core functionality is to reliably deliver a message from oneapplication to a second one, which needs to be alerted concerning an action taken by the first one.Such a messaging service is a core functionality of EAI systems. However, the two communicating systems, which were written


View Full Document

Toronto ECE 1770 - Too Much Middleware

Download Too Much Middleware
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Too Much Middleware and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Too Much Middleware 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?