Application servers are complex products that encompass many different technologies. Often described as middleware, application servers sit in the middle of diverse technologies and provide the glue to create a unified whole. The goal of the previous three chapters has been to provide a brief description of the key technologies with which application servers integrate or interoperate with.
Chapters 5, 6, and 7 focus on application servers. This chapter provides an overview of the market, the architecture, and the packaging of application servers. Chapter 6 describes some of the characteristics that should be designed into an enterprise infrastructure that includes application servers. Chapter 7 discusses some real-world implementation issues, highlights some case studies, and provides an overview of some of the application servers available today.
There is no doubt that application servers are a hot topic. The trade press is filled with articles about application servers. The number of vendors claiming to have an application server product grows almost daily. One Web site devoted to application servers currently lists 66 separate vendors participating in the application server market.
Unfortunately, the term “application server” is sufficiently vague that it could mean almost any server-based platform that supports applications. Indeed, the 66 vendors listed on the application server Web site mentioned offer a very diverse set of products.
One word that is frequently used to describe an application server is middleware. This is an intuitive term because application servers are utilized in three-tier distributed computing environments and represent the middle of the three tiers. The term “middleware,” however, has been around since the earlier days of client/server, predating the Web, and has meant many different things, depending on the background of the person or company using the term. For example, middleware has been used to describe everything from a database replication product to a transaction processing monitor.
In Chapter 1, an application server was defined as “a component-based, server-centric product that allows organizations to build, deploy, and manage new applications for i*net users.” This definition is more specific than the term “middleware.” There are three key aspects of the definition:
1. Application servers are based on a distributed object computing model such as EJB, CORBA, or Microsoft COM.
2. Applications servers facilitate all three activities (build, deploy, manage) related to new application development.
3. Application servers communicate with i*net-based users using the public Internet, a corporate intranet, or a partner extranet. This implies Web-related protocols and client software.
The remainder of this book deals with products that meet this definition.
The application server market is rapidly evolving and growing. New vendors enter the market regularly. The current market leaders are more firmly establishing their lead and growing their market shares, while a number of vendors are carving out their particular niche in the market. Big established companies and smart newer ones are competing on an equal footing. The Java 2 platform in general, and J2EE in particular, is dominating the more established and mature COM and CORBA technologies. Vendors are attempting to differentiate themselves from the pack by offering a range of application servers targeted to different environments and also offering a range of solutions that extend the application server.
The major technology research firms agree on this: the application server market is poised for explosive growth. The actual size of the market may be in dispute, but it is not disputed that the market is growing to become a multi-billion dollar market.
According to the Giga Information Group, a research firm specializing in technology for E-business, the application server market is estimated to have been $585 million in 1999. The firm has estimated that the market will reach $1.64 billion in 2000 and $9 billion in 2003.1 This estimate indicates the market will grow by 98 percent per year between 1999 and 2003. International Data Corp. and Forrester are apparently not quite as bullish. These two firms apparently predict that the market will be approximately $2.5 billion in 2003.2
Without having access to the full research reports, it is impossible to know the reason for these discrepancies. Some of the possible reasons include:
▪ different definitions of what an application server is and therefore inclusion of a different set of products in the market size extrapolation
▪ different pricing assumptions, particularly the assumption of the average sales price per unit three years in the future
▪ different assumptions on the growth of demand in the various worldwide geographies (North America, Europe, Latin America, the Middle East, Africa, the Pacific)
Despite the market size projection differences, the research firms agree that the application server market will be a substantial market in the future. To demonstrate this, take a midpoint estimate that the revenue generated by application servers, worldwide, in 2003 will be $5.75 billion. To estimate the number of licenses this represents, one must make some assumptions about average sales price to the end user (i.e., not to the distribution channel). Today’s list prices range from free (unusual) to a high of about $35,000 per CPU. One must consider that as the market matures, there will be some competitive pricing pressure. To estimate unit shipments, use a range of three different average sales prices (i.e., high = $15,000; medium = $7500; low = $3000). The resulting unit shipments are provided in Exhibit 5.1.
Exhibit 5.1 Calculated Unit Shipments in 2003
It is obviously critical to get the average sales price assumption right. In this case, the unit shipments range from 383,000 units to almost two million. The “right” number is quite likely near the medium estimate, $7500 average sales price and 767,000 units. Nonetheless, any of these unit shipments represents a very sizable market. Remember that application servers, by definition, are installed on servers — not desktops PCs. The unit shipments calculated are for a single 12-month period, that is, the calendar year 2003. The installed base of units at the beginning of 2003 will already exceed one million units, and perhaps substantially greater than that. Although the precise size of the market in terms of both revenue and unit shipments is in question, the fact that this is an attractive and growing market is unquestionable.
Market Drivers and Customer Requirements
Given the indisputable fact that the application server market is growing, what are the factors driving this growth? The biggest single factor is the furious stampede of organizations trying to achieve E-business.
As described in Chapter 1, an organization’s presence on the Web typically evolves in three stages. A static site that merely publishes information about the organization and its products and services using the Web characterizes the first stage. In the second stage, dynamic interaction with the user is added. Scripts and applets are used to achieve the second stage of Web presence. In the third and final phase of Web presence, all of the organization’s key business processes are tied to the i*net. Customers, partners, and employees regularly carry out mission-critical interactions with the enterprise using the i*net infrastructure and Web-style interfaces.
To achieve this third phase, which is synonymous with achieving E-business, it is critical that organizations tie their legacy, client/server, and new Web applications together in a cohesive manner. The application server is a platform that enables them to do this. The CEOs and CIOs of almost every major organization have gotten the message — enterprises that do not have a Web strategy will cease to exist, and organizations that stay in the first phase of Web presence will eventually be wiped out by the competition. The very senior level of management understands that the achievement of E-business is essential to the future success of the organization. This is true whether the organization is a for-profit corporation, an educational institution, a nonprofit entity, or a government agency.
As stated in Chapter 1, IBM, a key thought leader in E-business, has defined E-business as “the transformation of key business processes through the use of Internet technologies.” This, obviously, is a tall order for any organization, but especially for enterprise-class organizations that have a broad scope of operations and a wide geographical reach. Achieving this wide-reaching transformation places many requirements on the application server, which will be the key platform to allow an enterprise to achieve E-business. The most important requirements are common to most enterprises. These requirements, not particularly listed in order of importance, include:
▪ Flexibility. The application server platform should provide flexibility in supporting a wide variety of different client types, different operating systems and platforms, different legacy systems and application types, and different models of providing dynamic content (i.e., scripting, applets, servlets, server-side objects). It should be adaptable to support the future, as-yet-unidentified needs of the organization.
▪ Open standards support. The support for open standards is an important requirement because it provides flexibility of choice to the organization. If all platforms support open standards, then the organization is free to choose the appropriate platform to suit the needs of a particular task rather than being locked into a single vendor. Open standards support also allows elements from different vendors to interoperate, thus maximizing the value of the whole.
▪ Scalability. Many enterprises have tuned their internal systems to support the full complement of internal users. However, opening up these systems to a whole new set of external users has the potential to vastly increase the pool of users and tax the systems. Application servers must be able to scale to support many concurrent users, and should make parsimonious use of the resources of the systems with which they interoperate.
▪ Integration with existing systems and technologies. The key to an application server is its ability to integrate diverse systems and technologies. The application server platforms selected by a particular organization must be able to support all of that organization’s legacy and new systems to allow the organization to transform its key business processes.
▪ Support visual development tool of choice. The key to rapid application development is the use, when appropriate, of integrated development environments (IDEs) that allow a programmer to quickly and easily manipulate visual objects on a screen and create code as a result. Many organizations have adopted one IDE (or perhaps a couple) as their primary tool. An application server should be able to support the organization’s tools of choice.
▪ Security. Organizations that are opening their most mission-critical systems to the outside world have a paramount concern for security. If the mission-critical systems are attacked and altered, the organization could be in great danger. The application server platform should support an organization’s chosen security policy and work with existing security technologies and solutions.
▪ High availability. If an organization is to depend on a system for all of its key business processes, then that system and infrastructure must be prepared to demonstrate availability figures approaching 100 percent. The application server must support and integrate with technologies and solutions that are designed to allow the infrastructure to survive the failure of an individual component.
▪ Speed the development and deployment of new applications. The “old world order” in which applications took years to build and deploy is over. New applications must be developed quickly, using a combination of off-the-shelf components and tools, and new business logic. They must be deployed easily and automatically, not requiring manual installation or upgrade to each client. The application server platform should facilitate the development and deployment of applications in an i*net environment.
▪ Manageability. In a highly complex n-tier environment, it is critical that problems can be avoided when possible. When they do occur, the problems should be easily diagnosed and resolved. The application server platform should provide visibility and control to the appropriate system and network management tools of an enterprise.
▪ Leverage the current skill set of staff. With the tight labor market a problem for all IT management, the application server should, to the extent possible, leverage the current skill set of the IT staff. Outside, additional training requirements should be minimized.
Each organization will prioritize these requirements differently and will likely add a few of its own. Each organization will also have its own list of specific systems, applications, and technologies that its chosen application server will need to support. Nonetheless, most of the requirements have one thing in common — they support the goal of transforming an organization’s key business processes using Internet technologies. That is, they support the organization’s ability to achieve E-business.
One major market trend is intersecting with the growth of application servers. This trend is the growing willingness on the part of IT management to outsource certain applications. A whole new breed of service provider — the Application Service Provider (ASP) — has arisen in the past few years to deal with this trend. ASPs host specific applications, such as Enterprise Resource Planning (ERP) systems, and then rent them out to clients on some resource usage, transaction volume, or other pricing basis.
ASPs can utilize any technology they deem suitable to build their systems, including legacy hierarchical or traditional client/server systems. However, because they are in the business of supporting the ever-changing needs of their clients, they will likely look to implement systems that are flexible, expandable, and easily modified. As expressed several times throughout this book, an infrastructure based on a distributed object model enhances the flexibility of that infrastructure. In particular, it allows organizations to more rapidly deploy new applications that can be built from off-the-shelf components.
Quite simply, the application server is a very relevant platform for an ASP. With the growing availability of packaged CORBA or Java components, the ASPs will drive growth and adoption of distributed object-based application servers.
Diversity of Vendors and Solutions
The application server represents the confluence of many different technologies — legacy systems, traditional client/server systems, distributed object systems, and Web technologies. As such, the vendors that have entered and continue to enter the market come from a wide variety of backgrounds. This is depicted in Exhibit 5.2.
Each vendor brings its own unique perspectives and strengths to bear in its application server offering. Some of the solutions are very database centric. Other solutions offer a rich set of hooks to legacy and client/server systems. Still others address a particular niche such as the support of distributed numerical computing services. Some of the solutions are built solely on Microsoft ActiveX/COM technologies, while many others are focused on Java technologies and the J2EE platform. A handful of the solutions offer comprehensive support for COM, CORBA, and Java. Finally, there are several solutions that claim to support enterprisewide deployment with features such as fault tolerance, load balancing, security, and manageability.
The application server market is crowded, and many of the vendors’ claims sound similar. Any enterprise planning to deploy application servers needs to undergo a careful evaluation, matching up the unique requirements of that organization with the features supported on the current breed of products. In addition, the ability of the potential vendor to support future requirements must be considered as well. For example, the probability that a small startup with excellent database integration capabilities will be able tp offer solid and comprehensive support for traditional mainframe applications using old-style 3270 datastreams is pretty small. Chapter 7 concludes with a brief description of the capabilities of many of the current application servers available on the market.
Exhibit 5.2 Vendors Entering the Application Server Market
Battle of the Component Models
The working definition of an application server being used in this book includes the term “component-based” as one of the major elements of the definition. An application server, by this definition, must support at least one of today’s three common distributed object (component) models — CORBA, Java (EJB), or Microsoft COM.
Until late 1999, it was quite debatable (and heavily debated) which component model would prevail. CORBA is the most mature and complete of the models, and has a huge consortium of users and vendors behind it. Microsoft, as always, has extensive reach into most enterprise environments, and a number of vendors are willing to ride Microsoft’s coattails by implementing its technologies. Java, while still very hyped and watched, had lost some of its luster when the network computer, thin-client model of computing failed to meet the expectations set by some of the early advocates. Nonetheless, the release of the Java 2 platform and J2EE has reversed Java’s fortunes, particularly for server-side solutions such as application servers.
The Flashline.com Web site4 maintains a comparison matrix of application server vendors and products. As of this writing, this Web site tracks 28 separate application server vendors. Of these, 27 vendors support the EJB specification in one or more of their products; 15 of the group, representing more than half, are currently J2EE licensees. The tide, at least for now, seems definitely to be turning in Java’s favor.
This does not mean, however, that CORBA and Microsoft’s COM have become irrelevant. Almost all of the Java solutions support RMI-over-IIOP (or will in a future release) for interoperability with CORBA environments. Some of the top-tier solutions are available from traditional ORB vendors (e.g., Inprise) that have extensively enhanced their products to support EJB and other Java technologies. The top tier of IBM’s product line of application servers is built on a CORBA ORB foundation.
Until recently, Microsoft did not offer a stand-alone application server. Its application server functionality had been built into the Microsoft Internet Information Server (IIS) and the Microsoft Transaction Server (MTS). It now has a separate, stand-alone application server product called the Windows 2000 Application Center that boasts features that compete with leading application servers on the marketplace. However, as usual, the Microsoft solution is oriented to a Microsoft COM/ActiveX (only) environment. Some non-Microsoft application server vendors support COM, but usually in conjunction with Java or CORBA. The Microsoft approach and its COM-only product are expected to be widely implemented, especially in small and medium organizations. Larger enterprises that have a diverse set of technologies and a preference for UNIX as an application server platform will be expected to favor CORBA and Java approaches.
As the CORBA standards become more widely implemented and J2EE compliance becomes the norm, application server vendors will need to compete and differentiate their products based on more than just the core functionality defined by these architectures and specifications. Competition will take place on two fronts.
On the first front, application server vendors will augment their products with additional, value-added services such as those discussed in Chapter 6 (security, scalability, load balancing, fault tolerance, and management). The vendors will also craft offerings that are suitable for particular environments. For example, IBM already offers three versions of its WebSphere Application Server at three different price points, representing a low/medium/high amount of functionality. The packaging of application servers is explored in more detail later in this chapter.
On the second competitive front, application server vendors will offer related products that build upon the application server with specific functionality. For example, Bluestone Software supplements its Total-e-Server (formerly the Sapphire/Web application server) with a range of specific solutions such as its Total-e-B2B product, which automates the supply chain, enhances logistics operations, and extends E-business relationships. The set of related products is explored in more detail later in this chapter.
As briefly mentioned, pricing models for application servers are varied. A few vendors are adherents to the open source initiative and offer their products at no charge. Most IT organizations in large enterprises, however, will prefer to buy their products from established vendors that offer software maintenance and support.
The most common pricing scheme licenses the software per CPU. Therefore, in a multi-CPU system, a customer would purchase one license for each CPU that will run the software. A handful of vendors price their software per server rather than per CPU.
The price targets tend to fall into three different ranges. The lowest pricing range is the sub-$1000 range. These tend to represent the lowest end of a particular vendor’s application server product line. For example, IBM’s Web-Sphere Application Server Standard Edition (which offers the least functionality of the three different editions of the product) carries a list price of $755 per CPU. The middle pricing range is the $5000-to-$10,000 range. This range is typical for smaller vendors that offer a single product, and for the middle tier of vendors with a multi-product line. For example, BEA Systems’ WebLogic Server has a list price of $10,000 per CPU. The final pricing range is the $25,000-to-$35,000 range. This, obviously, represents a high-end product that is comprehensive in its support of component technologies and APIs. The BEA Systems WebLogic Enterprise Server, with a list price of $35,000 per CPU, is representative of products in this upper tier.
The application server market is poised both for dramatic growth and for dramatic change. Over the next two years, the number of solutions available will increase. There will be increased standardization of functionality as the J2EE and CORBA 3.0 specifications are implemented. The din of vendors clamoring to get their message out and position their offerings will be loud. Microsoft’s solution will gain some traction as its capabilities become more widely known. However, it is doubtful that Microsoft will vanquish Java and CORBA. Just the simple fact that the Microsoft solution is limited to the Microsoft server platform is sufficient to limit its influence, at least within large enterprises. Higher-end UNIX and Linux servers (and even mainframes) are expected to be the usual platform of choice for application servers in large enterprises.
The pool of available Java and CORBA components will continue to grow as independent software vendors provide vertical market solutions and prepackaged horizontal services. The availability of robust and diverse off-the-shelf components will further spur the adoption of application servers. Traditional integrators will offer customized solutions that are built using many standard off-the-shelf components.
Beginning around 2001, the market will begin to see consolidation as the winners pull away from the pack. It is too early to tell which vendors and solutions will survive, but the survivors selling into the enterprise space will have rich and robust solutions that go above and beyond the basic services detailed in the J2EE/CORBA specifications.
The second element of the definition of an application server, from Chapter 1 and the beginning of this chapter, states that an application server facilitates three activities related to new application development: build, deploy, and manage. It is a fair question to ask what role the application server, per se, plays in the overall build-deploy-manage process.
IBM and many other vendors identify the build-deploy-manage process as a key application framework for E-business. In other environments, such as the traditional client/server environment or the hierarchical mainframe-based environment, an IT organization must build applications, deploy them, and then manage them in isolated and discrete steps. The deployment process, for example, can be very laborious in traditional environments. Code needs to be installed, usually manually, on each and every system. In a client/server environment with thousands or tens of thousands of clients, this step can be very labor intensive, expensive, and error prone.
The difference between the traditional models and the new model is that these steps are no longer individual and isolated steps. With Web and distributed object technologies, these three formerly discrete actions are all intertwined. At the center of the process is the application server, as depicted in Exhibit 5.3. The build-time tools speed development and deployment of components. These components, through the services of the application server, are made available to clients across the i*net. The management of the component and the application is an integral part of the services offered by the application server.
Exhibit 5.3 Application Server in the Build-Deploy-Manage Process
Exhibit 5.4 depicts how the application server fits in the overall enterprise environment. This was introduced in Chapter 1, but now the notion of different computing tiers has been added. The application server is one of the elements in the middle tier in a three-tier environment. This environment is comprised of client devices, an i*net, a Web server (or possibly multiple Web servers), the application server, and finally the external application and data sources that reside on a variety of legacy and other servers. These are the key architectural elements of an application server environment. However, note that this is a logical representation only. Physically, the Web server, the application server, and even the “legacy” data source could all reside on the same piece of hardware. Conversely, there may be multiple levels within each of the three tiers (client, middle, back-end). For this reason, some refer to this environment as an n-tier approach.
Exhibit 5.4 Three-Tier Environment
The following sections look at each of the architectural tiers: the client tier, middle tier, and back-end tier. In addition, the services provided within the network infrastructure are detailed. Finally, an overview of the development tools that facilitate the development and deployment of component-based applications is provided.
The client tier in an application server environment includes the programs that are operating on the client platform (i.e., browser, applet), the protocols used by the client to communicate with the application server, and the client side of the interaction it has with the application server to obtain services.
The types of clients interacting with application servers can be very diverse and implement a variety of different technologies. Exhibit 5.5 illustrates an enterprise with many different types of client platforms. The clients access the application server through an internal corporate intranet, an external partner extranet, or the public Internet. Before examining the details of the various technical components of an overall solution, readers will want to examine the various factors and considerations to determine which client-side access technologies are most appropriate for a given situation.
Many of the clients within the intranet will be the usual desktop-based users who the IT department has traditionally supported. These users, equipped with desktop PCs or workstations, use a variety of packaged and custom software to do their jobs. The desktop systems are largely running a variety of the Windows operating system, although Macintosh and UNIX systems are dominant in certain environments. These desktop systems access an application server through a variety of different technologies. As stated in Chapter 2, Java applets and ActiveX controls are often a good fit for these employees because they tend to repeatedly use a small set of applications. The time and network bandwidth to download new applets/controls is minimal compared to the potential benefit of utilizing the client processor to share some of the computing burden, alleviating that chore from centralized servers. These clients will also support client-side components (JavaBeans, CORBA components, and COM components) and standard HTML/XML interaction.
The traditional set of desktop-based users has been augmented over the past few years with a growing set of employees who either travel a large percentage of the time or who telecommute. These users, while having computing needs similar to their desk-bound colleagues, present different challenges to the IT organization. Certainly, they pose a security challenge, but access speed is also a challenge. The traveling and telecommuting workers do not have the benefit of the high-speed internal network. The traveling user may dial in over a 28.8-Kbps line, while the telecommuter may have an ISDN connection. To accommodate the telecommuter and traveling user, the IT organization may need to limit the use of downloadable applets or controls to very specific circumstances. There may be a heavier reliance on server-side scripts/servlets and also on distributed components.
Exhibit 5.5 Clients within an i*net
An IT organization also needs to review the type of device used by the telecommuter and traveler. A telecommuter is likely to have a traditional desktop PC or workstation. In the past, traveling users almost always carried laptops, but more and more travelers are forgoing their laptops in favor of PDAs or other handheld devices that may have limited storage, computing power, and display area. These devices can be used for specific functions such as checking e-mail, but also to gain access to certain key enterprise applications. For example, the traveling sales rep may need to check order status and confirm delivery dates using a PDA that accesses an application server. Sun is trying to foster the implementation of the Java Virtual Machine on a variety of handheld devices, so JavaBeans may be common for these devices. For normal Web server interaction, Wireless Markup Language (WML; see Chapter 2) may become a standard wire protocol to these devices.
Extranet users are usually employees at an organization that is a supply chain partner or in some other formalized relationship with the enterprise. Examples of different types of extranet users include:
▪ auto dealers, independently owned and operated, interacting with the automobile manufacturing company to order cars, check delivery schedules, etc.
▪ manufacturing suppliers, interacting with the purchasing company using Material Resource Planning (MRP) and related systems
▪ banks and other loan agencies communicating with credit reporting companies
▪ retail operations interacting with credit card processors
▪ E-tailer interacting with express delivery companies to schedule and track package delivery
▪ two governmental agencies that require the sharing of data
Extranet-based users are in some ways similar to internal users, and in some ways similar to the general public over the Internet. They are similar to internal users in that they can be expected to be equipped with and trained to use PC/workstation systems. They are relatively sophisticated users who repeatedly use a specific set of applications. They usually have some internal help desk or technical assistance available to help resolve technical problems. However, they can also be similar to the general public in the sense that they may access the enterprise over the public Internet or slow direct-dial link. Available bandwidth may be an issue. The level of control that an IT organization has over its extranet users is widely variable. In some cases, the IT organization may be able to dictate equipment and software, as if the users were within the same organization. In other cases, the IT organization may only be able to recommend certain hardware and software, and the assumed common denominator may need to be relatively low (e.g., a Pentium PC with a browser).
It is this final issue — the level of control — that may be the first determining factor in what type of technology can be deployed at the extranet-based client. If there is no control, and cost and complexity need to be minimized, then a simple Web browser using standard HTML/XML may be the optimum solution. With more control over the level of software installed on the client, downloadable Java applets or ActiveX controls may be appropriate. If the organizations are closely related and the interaction is of sufficient volume, regularity, and mission criticality, then a distributed object approach is probably the best solution. The distributed object approach allows the two organizations maximum independence and autonomy while providing the most sophisticated functionality. Therefore, application servers are expected to be regularly deployed to support critical extranet connections.
Users over the public Internet present the IT organization with the widest diversity of hardware and software and the least level of control. Webmasters learned early on that requiring a particular browser level to view a Web site earned the wrath of the public. They soon learned to accommodate various levels on the site and perhaps added the “best when viewed with… ” disclaimer to indicate the optimum browser level. Early experiments with downloading Java applets to casual users over the Internet were less than successful, as impatient users abandoned transactions if they had to wait long seconds or even minutes for the download of code. In most cases, IT organizations should assume that the public accessing an enterprise’s middle and back-end tiers will do so with only a minimal-level and basic Web browser using HTML. Sophisticated scripts and distributed object components can indeed be implemented within the enterprise, but the output to the client will be basic HTML (and eventually XML) in most cases.
Exhibit 5.6 Client Access Technologies by User Type
Exhibit 5.6 summarizes the recommended client-side access technologies for the different types of users. These recommendations are generalizations. Unique requirements in a given circumstance need to be taken into consideration.
The most basic client in an application server environment is a PC/workstation that supports a standard browser using HTML or XML, or a specialty device (e.g., PDA, handheld device) that supports a browser subset and possibly the WML protocol. The architecture of one of these systems is depicted in Exhibit 5.7.
Exhibit 5.7 PC/Workstation with Browser
A browser-only device has just two tasks in life: to request that files (i.e., pages) be downloaded from a Web server based on the click of a user’s mouse, and to interpret and display or playback the multimedia Web pages that result from the request. However, this does not imply that there is only a simple Web server in the middle tier. The middle tier could be arbitrarily complex, with scripts, servlets, and distributed objects all cooperating and the end result being the simple HTML/XML/WML pages that are sent to the client.
A client system based on the CORBA component architecture may or may not be running a browser. A CORBA component, per se, does not have direct interaction with a browser program. A CORBA client can run any operating system, and the CORBA client program can be written in any language supported by CORBA. It only needs to have a client program with the appropriate stub, and the client component can communicate with ORB-based application servers. Exhibit 5.8 illustrates the architecture of a CORBA client.
Exhibit 5.8 CORBA Client
The CORBA client must support IIOP to be able to communicate with an ORB. The client uses the services of the ORB (i.e., the CORBAservices and ORB Interface detailed in Chapter 4) to find an object, invoke methods on the object, and receive responses from the object. Because IIOP is now supported by the EJB specification, a CORBA client can also communicate with an EJB server. The CORBA client does not have (and does not need) information about the location of its target objects and the methods they support because everything the client needs to know has been included in the client stub. As detailed in Chapter 4, the client can also access objects dynamically using the ORB’s Dynamic Invocation Interface (DII). The middle tier for CORBA clients will consist primarily of CORBA ORBs, EJB servers, and possibly target objects. The middle tier could be simple (i.e., a single server) or complex, but the simplicity or the complexity of the middle tier is transparent to the CORBA client.
A Java client is slightly more complex. The Java client, by definition, must support a Java Virtual Machine (JVM). The client may or may not be running a browser as well, but the most common Java client will be running a browser that contains a JVM. The browser’s JVM is used to initiate and run applets and JavaBeans. Exhibit 5.9 illustrates a typical Java client.
The browser interaction with the middle tier will be via one of the standard markup languages (i.e., HTML, XML, or WML). However, once the browser invokes the local applet or bean, the applet or bean is in control. Client-based JavaBeans are usually local entities that represent graphical user interface objects and therefore do not usually communicate across the network. A client accessing an Enterprise JavaBean (EJB) will need to implement RMI in addition to the Java Naming and Directory Interface (JNDI) classes. This requirement will effectively limit the number of Java clients that directly access an EJB; instead, clients will communicate with a servlet using Web pages and the servlet will interface with the EJB. An applet is not limited to HTML/XML, IIOP, or any other single protocol. An applet can utilize any protocol required to communicate with its destination host or server, including a proprietary one (usually over TCP/IP). The middle tier in a Java-oriented environment will consist of standard Web servers, Java applets being stored for eventual client download, Java servlets, and EJB servers. Because of the IIOP-based interoperability between Java and CORBA, the middle tier may also include CORBA ORBs and CORBA-based objects.
Exhibit 5.9 Java Client
A Microsoft client utilizing ActiveX controls and COM+ objects has an architecture similar to its Java client equivalent, except for one big difference: ActiveX controls can communicate directly with the Windows operating system and have direct access to all system resources. Exhibit 5.10 illustrates the architecture of a Microsoft client. This client will utilize Microsoft protocols for communication with a Microsoft-oriented middle tier. A “pure” Microsoft implementation would not include CORBA or Java servers in the middle tier. However, there are plenty of vendors that support products that bridge the gap between a COM environment and a Java/CORBA environment. Indeed, as detailed in Chapter 4, the CORBA specification details such interoperability and calls it “CORBA interworking.”
Exhibit 5.10 Microsoft ActiveX Client
A final possibility for the client is that it is based on a legacy client/server API and therefore does not adhere to any of the component models or rely on a Web browser. These clients, unless they are to be reengineered from the ground up, still need to be able to work with a server using the traditional API and networking approach (hopefully, the possible approaches include TCP/IP). One example of a common client is one that supports the IBM CICS client/server interface (the External Call Interface, ECI). Another common example is a client that makes direct database calls using the standard ODBC API. These calls may completely bypass the application server, or the application server may support these clients by implementing a gateway specific to that particular API and protocol.
All of the client systems discussed, with the possible exception of the last one (i.e., legacy client/server), are assumed to be using TCP/IP as the networking protocol. This somewhat goes without saying because the focus here is on i*nets that, by definition, are TCP/IP networks. IIOP, HTTP, and the other protocols mentioned all ride “on top” of TCP/IP. The TCP/IP clients will utilize a number of different standards and technologies to augment the functionality provided by the middle-tier servers. For example, TCP/IP-based Domain Name Servers will be used to locate the Web and application servers. TCP/IP standards will provide network-based service for security, file and print, IP address allocation, etc.
The middle tier of a Web and application server environment is where all the action is. It is where static Web pages are stored, dynamic Web pages are created, scripts and servlets are executed, and the applications based on one or more of the common distributed object models are created and executed. It is the middle tier that allows IT organization to realize the benefits of thin-client computing, in which a vast user base spread across an i*net can access a rich set of enterprise applications that seamlessly integrate the new with the existing IT resources.
The design focus of the middle tier must start with an architecture that facilitates change and growth. The distributed object models provide an excellent starting point, allowing organizations to blend off-the-shelf objects with new applications and new objects that encapsulate an organization’s unique business requirements. However, the IT organization must also design in key capabilities to support the mission-critical nature of the new E-business applications, namely, security, scalability, load balancing, fault tolerance, and management. These elements are briefly discussed in this section, and then explored individually in more detail in Chapter 6.
Exhibit 5.11 illustrates the various elements within the middle tier of an application server environment that services i*net users. The elements within the figure are architectural and the fact that they are depicted as separate entities does not mean that they could not or would not all exist on a single server platform.
Exhibit 5.11 Elements within the Middle Tier
The first element in the middle tier is the Web server, also often referred to as an HTTP server. This server implements the HTTP protocol and downloads Web pages to client systems. Conceptually, the Web server is a pretty straightforward element. It attaches to the i*net and “listens” for incoming requests from clients. The requests are usually for the download of a Web page, which can contain text, graphics, multimedia files, and even applets.
The client HTTP request can also invoke a script, Java Server Page, Active Server Page, or servlet to initiate a dynamic interaction rather than to simply download static pages. Scripts, JSPs/ASPs, and servlets are all invoked through specifying a URL that equates to a file containing the appropriate type of code. These code files logically reside on and are executed by the element that is identified in Exhibit 5.11 as the servlet engine. The servlet engine is the element that supports dynamic interaction with the user through the use of forms, drop-down boxes, radio buttons, and check boxes. The interaction between the servlet engine and the end user is standard HTTP with one of the standard page descriptive languages (HTML, XML, or WML). Refer to Chapter 2 for further information on the interaction between Web browsers and Web servers and the use of scripts, forms, and servlets.
The third and central element in the middle tier is the application server. This element is based on an architecture that supports distributed objects and thus supports a CORBA ORB, the Java EJB specification and the Java Enterprise APIs, or a Microsoft COM platform. Some application servers available in the marketplace support more than one of these platforms. The application server, beyond supporting the fundamental framework for a distributed object model, also supports a set of common, system-level facilities and services that allow the programmer of the components to focus on creating business logic. The application server can be invoked in a variety of ways. It can be directly invoked by a client program that supports the client side of the appropriate distributed object model (e.g., CORBA client, EJB client). It can be invoked through IIOP (or some other protocol) by the servlet engine, another application server, or some other server in the enterprise.
The application server, in turn, can call a variety of other systems. For example, it can utilize IIOP or RMI-over-IIOP to invoke an object on another application server. It can directly invoke other programs through a standard API. It can also invoke back-end applications through an API, gateway, connector, or other means.
The fourth element in the middle tier is an administrative server and client. The client is the user interface through which the systems management staff controls the environment. Most administrative clients are based on a Web browser interface rather than special client-based software. The administrative server executes the administrative commands, communicates with the other elements in the middle tier, and accesses the administrative data. The administrative element supports configuration and systems management functions. It can implement or communicate with other elements that implement naming, directory, and security services. For example, the administrative server can communicate with a network-based policy server to implement and enforce an organization’s security policy.
The fifth and final element in the middle tier is the device or system that stores information relevant to the application server or servers. For example, it can contain all application server configuration information. It can also include information relevant for the location and initiation of objects (e.g., the CORBA Interface Repository). It will usually also be a repository for traces, logs, and other information useful to the system and network administrators. This data store can be accessed via RDBMS calls to a centralized database server, or it can be accessed locally by the administrative server through system calls. Some application servers include a lightweight database management tool to facilitate management of this data.
Web Server/Application Server Design
The previous section discussed the five logical elements within the middle tier of an application server environment that services i*net users. In most enterprises, these five logical elements will be implemented on two or possibly three different groups of servers. These groups will usually consist of multiple different servers that are performing the same or similar tasks. The groups are viewed as a single logical entity because of scalability. Very few enterprises can support all of their Web server needs, for example, with a single server, even a very powerful and high-end server. Instead, they need to pool multiple servers together that function as a whole.
In the first group will be Web and servlet servers. These Web servers will serve static pages and also support scripts, Java Server Pages, Active Server Pages, and servlets for dynamic content. This first group of servers can support many of the common and routine requests initiated by i*net users and can even directly access a database using a database API such as ODBC. For example, in a retail Web site, these servers will provide the home page and the first level of pages that describe the corporation and its mission statement, list corporate news releases and financial information, provide contact information, and post open employment opportunities. Retail organizations that also offer brick-and-mortar stores usually also provide a store locator facility that provides store location and hours of operation. These servers can support the online catalog viewing that the majority of the Internet users access. They will support the search/query forms that allow a user to search the online catalog for a group of products meeting a specific set of criteria. They will supply the descriptions, images, and pricing of items in the catalog with the help of a catalog database. In short, the Web and servlet servers will serve the majority of the requests of the browsing public on a retail Web site.
It is becoming commonplace that these Web and servlet server “farms” are becoming quite large. Some of the premier consumer-oriented shopping Web sites, for example, may have a data center with hundreds of PC or UNIX servers functioning as Web and servlet servers. Another common trend is to support server farms in multiple, geographically dispersed locations. With this approach, customers in Europe, for example, may be directed to the European server farm, while customers in Australia are directed to the Pacific server farm. This approach helps to speed response times to users and also provides system maintenance windows for the IT organizations supporting them. It is critical, of course, that users are shielded from having to know that there are multiple servers. Users should have a single URL that denotes “The Web Server,” and the infrastructure should take care of appropriately apportioning sessions across the pool of available servers. The mechanisms for creating these server pools are detailed in Chapter 6.
The second group of servers in the middle tier is, of course, the application servers. The application servers house the server-side components that represent the new E-business logic. In a Java environment, the application server includes an EJB container and the Java Enterprise APIs detailed in Chapter 3. A CORBA application server is based on an ORB implementation, as detailed in Chapter 4. A Microsoft COM+ application server is based on the COM model. In any case, the application server supports the facilities and services to locate, initiate, and execute server-side components, as well as the ability to communicate with other application servers and back-end data and application systems.
This second set of servers can also support some of the servlets used to access EJBs, COM objects, or even CORBA objects. Recall from Chapter 3 and the previous section that implementing the client EJB interface is not really recommended for the client PC/workstation. The reason for this is that the EJB client uses RMI and JNDI to locate and communicate with the enterprise bean. Requiring these classes to be installed on all potential clients necessarily limits the pool of client machines that can access the enterprise bean. Furthermore, the communication between the EJB client and the enterprise bean is high in overhead; the data must be serialized, transmitted, and then unmarshalled on the other end. This overhead is best kept within the confines of a high-speed internal network rather than over a lower-speed wide area network. Furthermore, if the EJB client and the enterprise bean reside on the same server, the serialization overhead is then avoided because an internal call can be made. As a result, many vendors recommend that an EJB client be implemented on either the same server as the enterprise bean or a “nearby” server (i.e., another middle-tier server). The EJB client is then invoked through a JSP or Java servlet. The interface to the end user’s client system is basic HTML/XML.
Similar client location issues exist if the server-side object is a CORBA-based object rather than an enterprise bean. As in the case of EJBs, a CORBA client/server object interaction requires the serialization and marshalling of the data. Therefore, a client proxy object can be implemented on a Web server, a servlet server, or an application server that performs the object-oriented interaction with the CORBA server object. The client proxy can be any program (Java servlet, C++ program, Visual Basic program, etc.) that implements IIOP. As in the EJB case, this approach minimizes network overhead and simplifies the end client, allowing it to support only a simple browser.
In the example of the retail Web site cited above, this second group of servers can support the critical buying processes. Recall that the Web server group is supporting, in this example, the browsing functions — general corporate information, store location and hours, and online catalog search and display. The application servers can be invoked once the customer places an item in the shopping cart. Once this buying behavior is initiated, the components related to the shopping cart, the access of customer records, and the online credit card approval process are called into play. This type of activity is well suited to application servers because persistence is required to complete the total transaction, and the component architecture allows the system to be built with autonomous parts, possibly created by independent programmers or software vendors. There may be ongoing participation by the Web servers because the customer may continue browsing the catalog and adding items to the shopping cart. However, to add to the complexity, most application servers include the functionality of a Web (HTTP) server. Therefore, the application server can, depending on the design (i.e., location of servlets and pages), download Web pages directly to the end user.
As in the case of the first group of servers (i.e., Web and servlet servers), the second group of application and servlet servers should be designed in such a way as to maximize scalability and availability. Thus, in many enterprises, the second group of servers will involve multiple physical servers. Some may be groups of replicated servers in which the same set of servlets and objects are supported on multiple, different physical platforms. In this group there may also be different servers that house different components and different business logic. Therefore, there may be one set of servers dedicated to maintenance of the shopping cart, another that contains the component or components related to the concept of “Customer,” and another that contains the components and logic to carry out the credit card transaction.
Exhibit 5.12 Groups of Servers in the Middle Tier
The servers in the second group will each have built-in administrative capability. It is possible, however, that some enterprises will define a separate administrative domain with a dedicated server or servers. The administrative domain will have control over a specific set of Web, servlet, and application servers. Exhibit 5.12 illustrates the three different groups of servers in the middle tier.
Application Server Architecture
The architecture of any application server product necessarily depends on the basic model or framework upon which the product is built. For example, Java application servers are built on the Java-related specifications. Since 1999, that has been synonymous with supporting the J2EE platform. CORBA-based applications servers are built on the basic framework of an ORB and support for at least some of the CORBA services. Increasingly, CORBA-based application servers provide comprehensive support for the J2EE platform as well. Finally, Microsoft COM-based application servers are based on a COM framework. Because the focus of this book is on Java and CORBA, these two frameworks are explored in detail.
Java Framework
When the EJB specification was first published, vendors with products that implemented only that specification called their products Java application servers. Since then, however, the Java server-related specifications have grown and evolved and now encompass much more than just the EJB specification. As detailed in Chapter 3, the Java 2 Enterprise Edition (J2EE) platform specification includes EJB support, JSP and Java servlet support, and a variety of Java Enterprise APIs. The J2EE specification was defined by Sun in 1999 and now provides a baseline of functionality for Java application servers. Full J2EE support is now a minimum requirement to be considered a Java application server. Interestingly, at the core of a Java application server is an ORB. This architectural fact is invisible to the applications that use the application server because the applications only see and use the Java APIs. Exhibit 5.13 illustrates the basic architecture of a J2EE-based application server.
Exhibit 5.13 Architecture of a J2EE-Based Application Server
A Java application server provides an engine to execute Java Server Pages and Java servlets. Recall from Chapter 2 that a JSP is simply a Web page that contains both presentation logic, in the form of HTML/XML tags, and application logic. The application logic is identified and delimited by angled brackets, much like HTML and XML code. However, JSP code is dynamically compiled into Java servlets on the server. A Java servlet is a program, written in Java, that runs in the server’s Java Virtual Machine. It is similar to a Java applet except that it runs on a server rather than a client. A Java servlet can access an enterprise bean through internal system calls if the servlet and the EJB co-reside on a single system, or it can invoke an enterprise bean through the RMI interface. Because RMI-over-IIOP is considered a strategic interoperability mechanism, servlets should utilize RMI-over-IIOP whenever possible. The added advantage to this approach is that the servlet can then interoperate with CORBA-based object systems as well as EJB-based systems. As described earlier, a common and recommended approach for EJBs is to implement the client EJB interface as a JSP or servlet that communicates directly with the enterprise bean. With this approach, the end-user client machine can be very thin; it does not need to support RMI or JNDI and can run a simple HTML/XML Web browser to interact with the enterprise bean.
The EJB container on the Java application server is the environment within which enterprise beans run. An enterprise bean cannot run without a container. As detailed in Chapter 3, the container provides many of the system services to the enterprise bean and also shields the bean from direct contact with the EJB client. The container manages memory, threads, and other system resources. The container manages the state of an enterprise bean, saving and then restoring state information between method invocations. It also creates and destroys instances of enterprise beans. It manages persistence, security, and transactions on behalf of the enterprise bean. In short, the container provides several capabilities that the programmer of enterprise beans does not need to track or worry about. Compared to a rich CORBA ORB that implements the full set of CORBA services, the EJB container offers only a subset of services. However, the services that the EJB container provides are more automatic. In most CORBA environments, the programmer must still explicitly write code to create and destroy instances, for example (at least until CORBA 3.0).
The enterprise APIs on the Java application server allow the enterprise bean developer to leverage some key Java services. The full set of APIs is described in Chapter 3. The two most fundamental of these APIs is RMI and the Java Naming and Directory Interface (JNDI), which is the mechanism used to locate the EJB Home interface of an enterprise bean. However, a full-fledged application server also needs to access back-end data and transaction servers, and some of the other enterprise APIs facilitate that access. JDBC support is required to access databases. Java Transaction API (JTA) is important in facilitating the integration of Java application servers with existing transaction-based systems. Java Message Service (JMS) and JavaMail support mail and other applications that share events and data asynchronously.
Sun Microsystems licenses the J2EE platform and also makes its source code available for developers under its Community Source Code program. As stated earlier, more than half of the vendors identified by an application server tracking Web site had licensed J2EE from Sun. Some of these vendors claim to have “the most complete” J2EE implementation, but these statements should be recognized for the marketing hyperbole they are. Over time, the core functionality of many of these J2EE-based Java application servers will become almost identical. The architecture of one of these J2EE application servers — IBM’s WebSphere Application Server, Advanced Edition — is depicted in Exhibit 5.14. This product was selected as an example because IBM also offers a CORBA-based application server, called the WebSphere Application Server, Enterprise Edition. The architecture of high-end CORBA-based application servers is presented in the next section.
As Exhibit 5.14 reveals, the IBM WebSphere Application Server, Advanced Edition, is a J2EE-based implementation of a Java application server. The product includes its own HTTP server and will also work with independent HTTP servers. Each application server node includes an administrative server component that is responsible for configuring, monitoring, and managing the application servers running on that node.
CORBA Framework
Today, all major application servers based on a CORBA framework also provide extensive support for the J2EE specification. Therefore, one can view the CORBA-based application servers as providing a superset of capability provided in the J2EE-based application servers. This is because a CORBA-based application server will support components and applications written in Java, but also components and applications written in a variety of other languages. Also, a CORBA-based application server is usually a richer and more complex implementation. For example, a CORBA-based application server usually implements the full set of CORBA services, while a Java-based application server might only implement a handful of these services. Obviously, a product-by-product comparison will yield instances in which a particular J2EE server offers as much functionality as a particular CORBA-based system.
Exhibit 5.14 Architecture of IBM's WebSphere Application Server Advanced Edition
However, two major application server vendors — BEA Systems and IBM — offer a line of application servers, and the high end of the line in both cases is the vendor’s CORBA-based system. BEA Systems offers the WebLogic Server, which is based on the J2EE platform. It also offers the WebLogic Enterprise Server, which is based on a full CORBA ORB and full set of CORBA services. Similarly, IBM offers three different editions of its WebSphere Application Server product. Both the Standard and Advanced Editions are based on Java, while the Enterprise Edition is based on the company’s Component Broker, a full-fledged CORBA ORB. Inprise also offers a CORBA-based application server.
Exhibit 5.15 illustrates the general architecture of a CORBA-based application server. At the heart of the system is the ORB, which can be viewed as the base structure. On top of the ORB is the application server itself, which provides the complete execution environment for the system. The ORB is the communications bus that routes messages and method requests from client object to server object. The ORB also communicates with the outside world through the IIOP protocol (including RMI-over-IIOP). Recall from Chapter 4 that the ORB also provides a long list of services and facilities that support objects. For example, the ORB provides life cycle, naming, security, persistent object, query, event, concurrency, and other basic and essential system-level services.
Exhibit 5.15 Architecture of a CORBA-Based Application Server
The application server supports the runtime environment for both CORBA objects and enterprise beans (in most implementations). The application server must support the EJB container as defined in the Java specifications so that enterprise beans can be portable across different application server implementations. The application server will also manage system resources such as threads and memory. The application server (in conjunction with the ORB) also activates and deactivates object instances and maintains persistence and state information across method invocations. A CORBA-based application server can implement the Portable Object Adapter (POA), which (as described in Chapter 4) provides some advanced services, a container model analogous to the EJB container, and better scalability. A CORBA-based system can also support the Distributed Computing Environment (DCE) transaction processing environment, with support for DCE’s Remote Procedure Call (RPC).
In summary, both the J2EE- and CORBA-based application servers provide an execution environment and a rich set of services to support components. From an enterprise IT standpoint, which approach is “best”? The answer, of course, is that it depends on the environment. A J2EE approach may be optimal if the environment meets the following criteria:
1. no existing installed base of CORBA objects or COM objects
2. commitment to Java as a development language and environment, with sufficient Java skill sets in-house
3. mainly database back-ends
4. relatively straightforward legacy environment that does not contain a lot of client/server APIs (i.e., distributed CICS client/server, DCE, etc.)
A CORBA-based approach, on the other hand, is likely to be optimal in environments meeting the following criteria:
1. existing CORBA and/or COM object environments
2. rich set of back-ends that include databases in addition to proprietary and standard client/server environments
3. slower evolution to Java, with a significant investment in C++ or other languages
4. requirement for some of the more mature CORBA services (e.g., relationship service, qualities of service)
As stated elsewhere, the Java and CORBA specifications will continue to evolve over time and the gap in functionality between the two will continually lessen. Nonetheless, a fundamental fact of the J2EE approach is that it is tied to the Java programming language. CORBA, on the other hand, is not, and neither is Microsoft’s COM. In the end, organizations that are moving to Java should consider J2EE-based application servers; and organizations with a large and continued investment in C++, Visual Basic, Ada, Lisp, COBOL, and other languages should consider CORBA, COM, or both.
Distributed Objects Within the Middle Tier
Many enterprises will, over time, include a variety of different application servers. They can be grouped according to base technology (Java, CORBA, COM), end-user work groups, type of component, or some other criteria. The middle tier will contain application servers that replicate objects and applications in order to support load balancing and fault tolerance. It will also contain different groups of application servers that support different types of objects and applications. This is depicted in Exhibit 5.16.
IBM proposes an architecture for the middle tier that is comprised of three different layers of objects4:
1. Persistent components: abstractions that map to existing data or procedural programs
2. Composite components: new abstractions that represent an aggregation of persistent components
3. Application components: new components, accessed by client applications, that focus on business logic and the usage of other components
This architecture of layered components is similar to the concept in the EJB model of session beans and entity beans, except that the IBM model adds a third middle layer. As detailed in Chapter 3, an entity bean is a persistent entity that represents back-end resources; an entity bean is analogous to IBM’s persistent component layer. A session bean is a transient entity created by the client and usually only exists for the duration of the session between the client and the server; a session bean is somewhat analogous to IBM’s application component layer. IBM adds the middle layer of composite components to enhance reusability. IBM suggests that all data mappings that are particular to one system should be implemented as persistent components so that if the data mapping ever changes, only the single persistent component needs to change. Composite components, then, focus on aggregating data from multiple back-ends without being dependent on a specific mapping.
Exhibit 5.16 Groups of Application Servers
Interoperability between different Java and CORBA application server systems will be based on IIOP and RMI-over-IIOP. Interoperability with COM systems will be based on the OMG-defined Interworking Model or on a proprietary implementation of a COM-to-CORBA or COM-to-Java bridge. Some application servers integrate the bridge functionality so that they natively support interoperability with COM objects.
Application servers, of course, must run on some physical server hardware and server operating system. A brief mention of the different choices is in order.
Most application servers will be implemented on a server platform running Windows NT or a UNIX variant. Windows NT will be a logical choice for organizations that have a major commitment to NT and a workforce that is very skilled and adept at managing an NT environment. However, a commitment to NT does not mean that an IT organization necessarily needs to base its application servers on a COM (or COM+) technology base. Quite the opposite is true. Most application server vendors support NT as one of the operating system choices that they support.
Nonetheless, some NT-centric organizations will choose to implement COM-based solutions. As of this writing, Microsoft is offering its application server (called Application Center 2000) for beta testing. This application server’s key strength appears, at this time from early information, to be its tight integration with the new NT-based software scaling capabilities, allowing multiple NT servers to be logically viewed as a single entity to promote scalability and fault tolerance. This new capability can address what has been the biggest technical reasons (scalability and fault tolerance) to base an application server on a high-end UNIX system rather than NT.
UNIX is probably the most popular platform for application servers today. However, the UNIX market is highly fractured. The three most prevalent UNIX operating systems in enterprise environments today are Sun’s Solaris, HP’s HP-UX, and IBM’s AIX. Linux, a variant of UNIX, is growing in popularity within the enterprise. Most major application server vendors support all four of these operating systems.
Another server operating system that has some level of support from application server vendors is NetWare. Although the NetWare star has long since dimmed and many enterprises have replaced their NetWare servers with NT or UNIX, there remains a huge installed base of NetWare. Therefore, some vendors do offer application servers for NetWare.
IBM supports some of its application servers on its own OS/400 and OS/390 operating systems as well. OS/400, the operating system of IBM’s highly popular AS/400 system, may be a popular platform for smaller organizations or departments that use the AS/400 as the primary system, supporting legacy applications, new applications, and even a Web server. OS/390, the operating system for IBM’s mainframe computers, is an interesting option for large enterprises. OS/390 offers the most sophisticated load balancing, high availability, and fault tolerance capabilities of any other computing platform (which is described in Chapter 6). Today’s OS/390 comes equipped with a TCP/IP stack and a Web server. Therefore, in some environments, an OS/390-based application server makes a great deal of sense. If there are a great deal of mainframe-based legacy data and applications that need to be integrated with the new application server-based applications, for example, the mainframe might be the best platform for some or all of the components. This design would promote high availability while reducing network overhead.
The back-end tier of any enterprise is unique to that enterprise. Each individual enterprise has built, usually over a period of years or decades, a diverse set of systems and applications to run the mission-critical business processes of that enterprise. This tier includes legacy systems that are based on a character interface, client/server systems with proprietary or open APIs, and new distributed object-based systems. There is no single approach that will tie all of these diverse systems into today’s application server. Each type of system requires its own approach.
In some cases, the application server supports an API that directly communicates with the back-end server. In other cases, the application server uses object services to communicate with the back-end server. Finally, the application server might utilize a gateway approach, in which another program or server performs the conversion from the API/protocol used by the application server to one expected by the legacy host system. There is no single term for this latter approach; some vendors call the conversion programs “connectors,” some call them “adapters,” and some call them “gateways.” The term “gateway” is used here because it is the most correct from an architectural standpoint. Gateway functionality can be integrated into the application server or it can be provided by a stand-alone product. Several types of gateways were discussed in Chapter 2. The host integration server is becoming increasingly popular. The host integration server is a server-based product that provides generalized access to a variety of different legacy host systems.
Many legacy applications based on mainframes and midrange systems still exist today that communicate using character-based data streams. These legacy applications are built around a hierarchical model, in which end users traditionally accessed the applications using dumb terminals. Dumb terminals are simple devices that provide a keyboard and a character-based screen. The user interacts with the application by filling in fields on the screen and pressing the Enter key or a programmed function (PF) key. With the advent of PCs, the dumb terminal has been largely replaced with terminal emulation software that runs on the PC. This software continues to present, in most cases, the character-based user interface to the user. Although dated, the legacy hierarchical systems continue to run some of the most long-standing and mission-critical applications of an enterprise. The investment that has been made in these applications is huge (trillions of dollars worldwide), and IT organizations have found it technically difficult, not cost-effective, or too risky to try to reengineer these applications to fit the client/server or the distributed object model.
Chapter 2 contains a detailed description of the issues and technologies in providing access to legacy systems from Web-based users. Essentially, there are two basic approaches to Web-to-host: client-based applets and server-based conversion programs. In the client applet approach, terminal emulation software is packaged as a Java applet or ActiveX control and downloaded to the user via the browser. Any user with an appropriately equipped browser (i.e., with the proper JVM or ActiveX support) can access the legacy system. Early client-based applets only offered the traditional character-based interface, but solutions increasingly are offering a means of rejuvenating the user interface on-the-fly. Server-based conversion programs and host integration servers can offer greater flexibility and superior rejuvenation of the user interface. A server-based approach can allow a complete revamp of the application flow without changing the legacy application. A server-based approach also allows the user to interact with a new Web-style interface that integrates information from multiple different legacy systems.
Few application servers today integrate a complete host integration server or server-based HTML conversion. One possible explanation for this may be that many application server vendors do not have the expertise or experience to provide this capability. This obviously is not true of IBM, however, and IBM has chosen to integrate its client-based applet with WebSphere Application Server, Enterprise Edition, rather than supporting server-based conversion and host integration. The client-based applet, IBM WebSphere Host On-Demand, is downloaded to users requiring host access. From that point on, the Web-Sphere Application Server has no role in the host access. The client directly accesses the host without going through the application server.
One very likely reason that vendors are not offering extensive legacy host integration features within their application servers is the cycle impact. Server-based conversion of host data streams can be a very costly process in terms of CPU utilization. A single server that is running a full-fledged host integration server in addition to an application server may be constrained to supporting tens or hundreds of concurrent users rather than the thousands of concurrent users that larger enterprises may require. For this reason, many enterprises will implement separate host integration servers to support the legacy, character-based application access.
The database has been an integral part of the enterprise IT environment since the very early days of business computers. Originally, database systems were accessed in proprietary ways, with a different interface or query language for each system. IBM’s IMS, for example, was highly popular and is still being used in many enterprise environments today.
Eventually, in the 1980s, the relational database model became prevalent over the proprietary systems. Relational database management systems (RDBMS) from companies such as Oracle, Sybase, and Informix, accessed using Structured Query Language (SQL) commands, are the norm today. The client/server era was largely based on the RDBMS system. Most client/server applications contain at least some database access. In the client/server world, each RDBMS vendor implemented a unique variation of the SQL command set and a unique protocol and API. This made it difficult for different clients to interoperate with different servers.
The interoperability problems eventually precipitated two changes: the introduction of standard RDBMS APIs, and the introduction of a middle-tier server to communicate with multiple database systems. The standard API widely implemented in client systems and RDBMSs is the Open Database Connectivity (ODBC) API initially developed by Microsoft but now an industry standard. The J2EE platform supports a Java version of ODBC called, appropriately, JDBC.
The introduction of the middle-tier server for accessing multiple database systems marked the beginning of the category of product called an application server. Although today’s application server is much more than just a middle-tier device for connectivity to multiple databases, there are still strong ties, to some people, between application servers and database systems. In fact, some analysts, vendors, and writers still position the application server as having a single type of back-end — the relational database system. To these people, a Java application server with JDBC support is all one really needs to access the back-end tier.
One common manner in which application servers access relational database systems is through ODBC or JDBC APIs. The API approach offers a direct interface, which can be very efficient and direct. Legacy databases, such as IBM’s IMS, may require a specific gateway (or adapter or connector). Another possible approach is to access the database through a CORBA object implementation or enterprise bean. Some database vendors, for example, have extensively “componentized” their systems so that they are accessible through CORBA ORBs or EJB servers. A final approach is for the application server to utilize its inherent transaction services to access the database system and coordinate between different resources. This is described in the following section.
Transaction Processing Systems
Transactions are really the heart of any enterprise IT infrastructure. Users carry out transactions with legacy character-based systems, with database systems, with message queuing systems, and with a wide variety of other systems. A transaction is a unit of work that has the following properties:
▪ It is atomic: a transaction is the smallest unit of work; all changes to systems are either all committed or they are rolled back.
▪ It produces consistent results: changes to the state of the resource move from one valid state to another.
▪ It is isolated: changes to shared resources do not become visible to others until the transaction commits.
▪ It is durable: changes to shared resources survive subsequent system or media failures.
Early transaction processing systems, like other types of applications and systems, had proprietary and hierarchical interfaces. IBM’s CICS is perhaps the most widely deployed transaction processing system, and its original interface was proprietary and largely based on character-based data streams in which the application logic was intertwined with the user interface. With the client/server movement, IBM added a client/server programmatic interface to CICS, and now CICS APIs are supported on a wide variety of client and server systems.
As enterprise environments evolved and more and diverse systems supported transactions, some enterprises deployed a class of product called a transaction processing monitor, commonly called a TP monitor. The TP monitor is a piece of middleware that integrates and coordinates transactions that span multiple different systems.
Both CORBA and Java support transaction services, meaning that the CORBA- or Java-based application server can become a coordinator of distributed transactions that span multiple systems. A CORBA application server would need to support the CORBA Object Transaction Service (OTS) specification, and the Java application server would need to support the Java Transaction Service (JTS). J2EE also specifies the Java Transaction API (JTA), an API upon which JTS is built and that is available to programs on application servers that directly communicate with transactional systems. The systems accessed by the CORBA or Java application server could be, depending on the implementation, database systems, legacy systems, message queuing systems, or other TP systems or TP monitors.
An application server that does not support the full OTS or JTS specification can still connect to individual transaction processing systems or TP monitors through a specific gateway (or adapter or connector).
Messaging and message queuing systems allow two or more applications to communicate asynchronously. E-mail is probably the most common example of a messaging application. However, many other enterprise applications are designed with a messaging interface. Messaging and message queuing systems are often used when the volume of transactions is high, and a very efficient and robust means of distributing and sharing data across multiple heterogeneous applications and systems is required. IBM’s MQSeries, for example, is used by a worldwide express package delivery service to track its packages using a variety of different back-end systems.
Messaging and message queuing systems can be interfaced directly by way of a specific gateway (or adapter or connector) integrated with the application server. Clients that require access to the system can do so directly. In the case when the message queuing system is part of an overall larger transaction, the application server, with an OTS or JTS implementation, can coordinate the overall transaction, of which the message queuing is just one piece. Finally, both the Java and the CORBA specifications contain messaging interfaces. The Java Messaging Service (JMS) provides a common Java interface to messaging products. CORBA supports two services, the Event Service and the Notification Service, that facilitate messaging. JMS can even be implemented on top of the CORBA Event and Notification services.
Enterprise IT environments include a wide variety of other types of mission-critical applications that represent key business processes or provide a critical function in the infrastructure. Some of the applications that may require integration with an application server include:
▪ Enterprise Resource Planning (ERP). These systems, from companies like PeopleSoft, SAP, and Oracle, integrate the various functional organizations such as human resources, finance, and business process management.
▪ Workflow automation and collaboration. Software, such as Lotus Notes, that promotes workgroup collaboration and automation of workflow between groups.
▪ DCE-based distributed processing systems. Applications based on DCE APIs for distributed transaction processing; the most common of these is the Remote Procedure Call (RPC) API, which provides for a network-transparent communication between processes in a distributed system.
▪ Network-based services. A variety of network-based systems that provide directory services, security, load balancing, and other services.
Many of these systems are based on open and published APIs. Application servers equipped with the appropriate gateway (or adapter or connector) can directly communicate with these systems. In other cases, there may be object-oriented interfaces or implementations of the applications that allow a Java or CORBA application server to access the application using standard object services.
Exhibit 5.17 summarizes the potential back-end connections and systems that can be supported by an application server. Each application server will be unique in the types of back-end systems that the application server natively supports. A bare minimum functionality is support for RDBMS access using ODBC or JDBC. More sophisticated application servers will provide a richer set of APIs and gateways/adapters/connectors. Remember that a host integration server that offloads some of the CPU-intensive gateway and conversion functions to legacy systems can augment the application server.
Exhibit 5.17 Application Server Back-Ends
Recall that the definition of an application server includes the notion that an application server allows IT organizations to build, deploy, and manage new applications. The application server cannot do all of these functions alone; it must work with related products to accomplish all three tasks. One of the more important related products is the Integrated Development Environment (IDE) and related development tools used to design and develop the new applications.
One of the promises of distributed object computing is that this model facilitates and speeds the design, development, and deployment of new applications. The distributed object model fulfills this promise, largely through the concept of application reuse and open interfaces to objects and applications. The IDE is a tool or set of tools that can dramatically improve the productivity of software developers by providing an easy-to-use visual interface, automating the generation and deployment of code, and facilitating the test and debug process. The IDE is a category of product that has been evolving over the past decade or so. It is not specifically tied to the development of distributed applications built on application servers. IDEs are used to build traditional client/server and Web server-based applications as well. Popular Java IDEs include IBM’s VisualAge for Java, Symantec’s Visual Café, Inprise’s JBuilder, and Microsoft’s Visual J++. These products are commonly used to build client-based Java applets, Java servlets, and JSPs.
Additional tools can be used in an application server environment to model the object environment, map components to resources and applications, and build new business logic that integrates components from around the enterprise.
Different application server vendors approach the subject of development tools differently. Some vendors offer a proprietary tool that works only with their application server and that is supposed to provide all of the functionality an IT organization may need to build and deploy applications using that application server. Others choose simply to provide explicit support for a variety of different IDEs and tools available in the marketplace. The third and most common approach is to provide a bundled tool in addition to support for off-the-shelf IDEs.
Most enterprises will end up deploying multiple tools. This is not because the tools are faulty and there are no comprehensive tools. Instead, it is because there will be different types of individuals, with different skill sets and backgrounds, involved throughout the end-to-end application development process. Web designers, for example, will not care about the great visual modeling and component builder aspects of a tool. Web designers want tools that allow them to easily build sophisticated Web pages. By the same token, a software engineer designing and developing business logic will not care much about the great HTML and XML capabilities of a tool.
An IT organization needs to recognize that there are different tools to suit different jobs. The ultimate goal should be to select a set of tools that supports all steps in the development process: model, design, develop, test, and deploy. However they are packaged within individual products, the following types of functions will generally be required in an application server environment:
1. visual tools for building a GUI user interface (e.g., a JavaBeans customizer)
2. visual modeling tools to model the enterprise deployment of components, applications, and servers
3. visual tools for defining, building, and deploying server-side components
4. visual tools for management of the application server container and core services
5. visual tools for the creation of new business logic that combines multiple components
6. deployment tools for enterprise bean and CORBA object deployment
7. features to map components to back-end resources (e.g., entity beans to databases)
8. code editors for HTML/XML, Java, and scripting languages
9. development kit, which includes compilers (including CORBA IDL compilers with appropriate client support), testing environment, debugging tools, and team development tools
In addition to these development tools, the administrative capabilities of an application server impact the overall development cycle in the sense that these built-in functions can assist in the deployment process. Many application server vendors offer sophisticated administrative interfaces and tools that automatically discover components and services in the environment, which assists in the configuration and ultimate deployment of the application server and its components. These administrative capabilities, while not being considered actual development tools, are a part of the overall development cycle and therefore should be considered in any application server evaluation.
The specifications defining Java and CORBA application servers are fairly complete (although evolving over time). The specifications do not get into implementation details, however. Two vendors that each offer fully compliant J2EE implementations, for example, will be able to differentiate their products from those of other vendors by offering specific functionality that extends, enhances, or goes beyond the functionality that is defined in the J2EE specification. One area that Java and CORBA application server vendors are attempting to establish differentiation is in the area of load balancing and fault tolerance. Neither the J2EE nor the CORBA specification directly addresses this key requirement, so vendors are implementing their own solutions to address it. Chapter 6 discusses this in some detail.
Another potential area of differentiation is in how the application server is packaged. Packaging, quite simply, is the combination of features, functions, and products to make a whole offering that is sold to the end user. Vendors can differentiate their application servers by bundling in related tools and products. With this type of differentiation, the vendor can offer a more “complete” product in terms of meeting all related customer needs. This can provide a competitive advantage over other solutions that do not bundle in the same capabilities.
The most common product or functionality bundled with an application server is the Web (HTTP) server functionality. Almost all application servers available on the market have a Web server built in to the product that can serve up standard HTML/XML/WML pages to users’ browsers. This is an important capability to be included. Recall from the earlier discussion on Web server and application server design that the application server will very often communicate directly with a browser using standard HTTP. This is because the client object may in fact be implemented as a servlet or a client proxy on the application server itself to avoid the overhead of sending object references across the network. Therefore, having the application server directly communicate with the end user, rather than through a separate and stand-alone Web server, is more efficient. However, just because the application server includes a Web server does not mean that an enterprise should eliminate stand-alone Web servers. Chances are that the majority of the Web-related i*net traffic will be either static or dynamic scripted pages that do not require the sophistication of an application server. It is best to devote dedicated Web servers to handling this normal traffic, conserving the resources of the application server platform for the more difficult tasks of managing distributed objects and component containers.
Another common type of function bundled with an application server is the gateway functionality for connection to a particular back-end data or application server. As detailed earlier, each application server vendor offers its own unique set of back-end gateways. Some application server vendors bundle in these gateways with their offering. In other cases, the vendors support a standard connector interface and encourage other software development firms to write to their interface. It is expected that, over time, the connector interfaces will become standardized and vendors will offer off-the-shelf connectors that work with a variety of application servers.
Application server vendors also frequently bundle development tools with their application servers. Development tools may be proprietary to the application server or open and applicable to a variety of products. In either case, virtually all vendors that offer some kind of development tool end up bundling it at no additional charge with their application server as a way of providing additional value to their customers and differentiating their product from those of the competition.
An emerging way of differentiation through bundling is in offering complete business object implementations that can be used to build new applications. For example, an application server that is bundled with the business object “Checking Account” and its related methods and properties could significantly expedite the building of new banking applications. This type of bundling is just starting to occur, but one can expect to see more of this in the future. In particular, vertical market object bundles may become prevalent as vendors try to focus on a particular segment of the market.
Vendors can also differentiate their application servers by offering a range of application server products, serving the needs of the small site with minimal functionality at a low price point and the needs of a large enterprise with greater functionality at a higher price point. This type of differentiation allows the vendor to better meet the range of needs in the marketplace while also optimizing revenue. With a single product (and a single price point), an application server vendor might be forced to offer all potential features and functions it has available in that one product. Pricing for this high-end product should be equivalent to other high-end product in the marketplace in order to fund the development for all of the value-added features. However, this may price the vendor out of competing in the departmental environment or the smaller enterprise. Therefore, some vendors already offer two or three different application servers, offering a range of price and functionality. This trend will likely continue.
As an example of this product line approach, IBM offers three editions of its WebSphere Application Server:
1. Standard Edition: supports XML, Java servlets, and JSPs
2. Advanced Edition: includes features of Standard Edition but adds full EJB and enterprise Java API support
3. Enterprise Edition: includes Advanced Edition and also offers EJB engine based on Component Broker (a CORBA ORB implementation) and transaction processing features of IBM TXSeries
Pricing and packaging mechanisms will increasingly be used by vendors to set their products apart from the pack. As more vendors implement the J2EE platform and the CORBA 2.x/3.0 specifications, the products will begin to look more and more alike. Vendors will bundle features or products to augment their products. They will also offer a complete product line that offers a variety of different price points to make sure that they meet the needs of the widest possible set of customers while maximizing revenue.
Another way that vendors will attempt to differentiate themselves from the large and growing pack of application server providers is by offering complementary and related products. These may be subsets of the application server that stand alone as products, or they may be related products that build upon and augment the application server to provide a more total solution. This approach is different from bundling because the subset products and the related products are priced and sold separately.
Vendors that offer a subset approach are attempting to maximize the engineering investment they have made in a particular area. As an example of this approach, Inprise offers a variety of different products that each implements one of the CORBAservices. The company sells stand-alone servers for the following services: trading, notification, life cycle, property, collection, concurrency, relationship, and time. The company also sells its ORB separately. These stand-alone servers can augment an Inprise application server environment. However, they can also provide a “foot-in-the-door” to accounts that do not currently implement the Inprise application server. This gives a company the potential to start with a single stand-alone service or ORB and, over time, “sell up” to the full-fledged application server.
The more common approach to selling related products, however, is to sell services that build upon the application server. This elevates the sale from a comparison of features and functions of different application servers to a total solution approach. As most top sales reps will attest, a company that offers a compelling total solution will be much more successful with the core product, in this case the application server. The core product becomes a required infrastructure, and it then does not need to be evaluated against all potential competitive offerings.
The variety of related products that vendors are positioning with their application server products is large and growing. One very common category of product is the E-business suite that offers specific applications and tools on top of the application server. IBM offers its WebSphere Commerce Suite for E-commerce and WebSphere B2B Integrator to support B2B activity with suppliers, business partners, and E-marketplaces. Bluestone Software offers a range of solutions to augment its Total-e-Server application server: the Total-e-B2B, Total-e-B2C, Total-e-Wireless, and Total-e-Global products. BEA Systems augments its WebLogic and WebLogic Enterprise application servers with the WebLogic Commerce Server and the WebLogic Personalization Server. These are just a few examples of the types of E-business extensions available on the market today.
The E-business suites are just the tip of the iceberg when it comes to related tools and products that vendors are positioning with their application servers. Other types of related products include:
1. Component development tools: assist in the development and deployment of CORBA or Java components
2. Business or vertical market components: prepackaged components that can be integrated with new business logic and other components
3. Web authoring tools: support the creation of dynamic and static Web pages
4. Web site personalization and portal products: support the concept of a personalized portal through which employees, customers, and suppliers access an individualized view of the Web site
5. Host integration servers or optional legacy gateways (adapters/connectors): provide access to specific legacy host and applications
6. Server and network modeling tools: allow the IT organization to model the servers and network and anticipate and prevent potential bottleneck points
7. Site administration and management products: facilitate the administration and management of the application server and its environment
8. Network services products: support the application server infrastructure with directory service, security, load balancing, and queuing technologies and products
IT organizations should take into account the related products offered by a particular application server vendor when evaluating alternatives. Over time, the core functionality of application servers will become very similar. The differences between vendors will become more apparent as the total product portfolio is examined. Preference should be given to vendors that offer total solutions that are required immediately or even possibly in the future, as long as the vendor has committed to providing standards-based solutions. Proprietary approaches that lock an organization into a particular vendor should be avoided. When a particular proprietary solution is required to solve a specific problem, the product should be considered tactical. The base infrastructure should be based on open standards to support future flexibility.
The application server exists within a network infrastructure that provides multiple services to the i*net and its users. The network was once considered just the plumbing that provided connectivity between sites. Now, with the efforts of enterprise networking vendors like Cisco Systems and IBM, the enterprise network is becoming an adaptive and intelligent infrastructure that enhances overall security, availability, and efficient utilization of bandwidth.
Some of the network-based services are directly called or accessed by the application server, and some are more or less invisible to the application server. Services in the former group include security and directory services. Services in the latter group include network-based queuing and prioritization, filtering and caching, and stand-alone traffic load balancers.
There are a wide variety of different network-based devices that implement one or more facets of an overall security policy. The important subject of security is covered as a comprehensive whole in the first section of Chapter 6. The other four major network-based services are discussed individually in the following sections.
Directory services allow users and programs to discover resources on the network. Like a telephone book, a directory server provides a mapping between a known entity (an element’s name) and an unknown entity (the element’s address). A directory server also offers the ability for clients (either users or programs) to select an element that matches specific criteria or to browse through a structured tree of resources.
Directory servers are critical to a distributed object environment for the simple reason that components and services are distributed throughout a network. By definition, an application server environment is based on objects that are distributed. The directory server (also referred to as a naming server or service) allows the distributed objects and services to be located.
There are a number of directory servers that are common within enterprise networks. The most common and dominant servers are:
1. Domain Name Server (DNS). As described in Chapter 2, the DNS node is a very common item in a TCP/IP network. The DNS node provides a mapping between a host name and its IP address. For example, a user can request the Web page www.excite.com by typing the URL into the browser window. The browser program will send the request for the IP address of that node to a DNS node. ISPs implement DNS nodes, as do almost all enterprise networks. There is a defined hierarchy of DNS nodes, so if the primary DNS node does not have the IP address of the host, it will find it by communicating with the hierarchy of DNS nodes. Eventually, one will be found that knows the IP address of www.excite.com, and it will return that address to the browser.
2. X.500. One of the few technologies from the Open Systems Interconnection (OSI) standards initiative that was ever widely deployed was the X.500 directory standard. X.500 describes an International Telecommunications Union (ITU) standard that specifies the client requesting directory services, the agent which stores the database and responds to requests, and protocols used between them.
3. Lightweight Directory Access Protocol (LDAP). The LDAP was defined as a response to some criticism that X.500 was too complex to be implemented. It is based on many of the same concepts as X.500 except it is more streamlined and simpler for vendors to implement. LDAP, which works specifically in TCP/IP networks, is defined by IETF standards. It has become a de facto standard for i*nets.
4. Novell Directory Services (NDS). NDS is Novell’s own directory server. NDS is a mature product that has been around for many years and has evolved to include support for LDAP.
5. Microsoft Windows 2000 Active Directory. Active Directory is the newest incarnation of Microsoft’s directory services bundled within its Windows server, in this case Windows 2000. It leverages DNS namespaces and LDAP protocols.
CORBA and Java both specify APIs that allow clients to look up and locate objects. These APIs and services work in conjunction with the network-based directory servers described above.
The CORBA Naming Service is sometimes referred to as CORBA’s “white pages” because it allows clients to associate names with objects rather than referring to objects using the Interoperable Object Reference (IOR), which is less flexible and scalable. The Naming Service specification supports both hierarchical and federated naming graphs, providing flexibility in the physical and logical organization of resources. The OMG specification does not define the implementation of a naming service. Therefore, this service can be implemented on top of almost any directory server, including an LDAP server.
The CORBA Naming Service is commonly used to locate objects within a department or intranet. For locating objects outside a department or intranet, the CORBA Trader Service is useful. The Trader Service is sometimes referred to as CORBA’s “yellow pages” because it allows clients to locate objects that meet specific criteria based on property names and values. Objects that wish to be located by way of a Trader Service can export service offers (collections of property names and values) to the Trader.
The Java API that provides naming and directory functions to Java applications is JNDI. This API has been discussed several times, and it is a requirement for any EJB implementation because it is the means by which enterprise beans are located. Programs written in Java can call the API to look up objects of any type, including remote enterprise beans, JDBC URLs, etc. The API provides methods for performing standard directory operations such as searching for objects by attribute. The JNDI specification, like the CORBA specifications, does not specify the engine that is providing the directory services. Different implementations exist of JNDI on top of LDAP, DNS, NDS, and even CORBA naming servers.
The Java and CORBA specifications are predicated on the fact that modern enterprise networks offer rich and varied directory services. Both distributed object models rely on the existence of such servers to locate specific objects and to search for objects that meet a specific set of criteria. Better yet, both specifications leave the implementation of the API open so that vendors can implement them on top of their already popular and widely deployed LDAP, NDS, or other directory servers.
An enterprise network carries a variety of different traffic types. Some of the traffic originates from file transfers; some of it is transaction-oriented data; and some is administrative or management data. A growing percentage of the traffic in the enterprise originates from a Web server located within the corporate intranet or outside it.
Each of the different types of traffic is different and each type of application has a different tolerance for delays and variations in response time. File transfers tend to be very large, but the file transfer applications are tolerant of network delays and variations. In addition, file transfer applications support checkpoint and restart capabilities in order to continue the transfer should it get interrupted for whatever reason. Transactions with legacy systems, on the other hand, tend to be characterized by small transfers of data (a few hundred bytes). However, many transaction systems are very intolerant of network delays and will terminate a session if a response is not received within a specified period of time. In addition, the end users of transaction processing systems tend to be intolerant of response time variations and will likely complain to the help desk if the response time varies from sub-second to five seconds within the same session. Web server traffic, interestingly, exhibits characteristics of both file transfer and transaction-oriented data.
Mixing these various types of traffic on a single network can be problematic. Although bandwidth is simultaneously getting cheaper and growing within the intranet and in the wide area network, it is still a finite resource. Therefore, in most environments there inevitably exists some contention for bandwidth. Consider the case of one user starting a very large file transfer just milliseconds before another user in the same location hits the Enter key to initiate a customer service transaction with a legacy system. If the network had no mechanism to prioritize these two types of traffic differently, the transaction traffic could wait an indeterminate amount of time for the file transfer to complete, and some transaction-oriented sessions would time-out and terminate before the transaction data had a chance to be transmitted. Obviously, this has drastic consequences for network users.
Fortunately, there have been a number of different mechanisms developed to avoid these contention problems and allocate network bandwidth according to some sort of priority. Generally referred to as “quality-of-service” (QoS) capabilities, these mechanisms allow high-priority data to receive a higher quality of service than lower priority data. The mechanisms are varied, but generally rely on the classification of data and the differentiated service provided to data of different classifications.
Data can be classified at the end points or at the intermediate points within the network. To achieve end-to-end quality of service, it is preferable to classify data at its point of origin and then tag or signal the data with the appropriate priority classification. A TCP/IP-based application, for example, can set the IP precedence bits in each of its packets and the network will prioritize the packets accordingly. IP precedence is an IETF-standard way of classifying eight different priorities of data. If not done at the point of origin, classification can also take place within the network. For example, a backbone router can be configured to treat all traffic from a specific interface as high-priority traffic. New mechanisms that identify and differentiate Web users based on browsing versus shopping activity are becoming available.
Once classified, the different classes of data can be treated differently. If there is contention for the bandwidth over a particular segment in the network, data must be queued at the point of ingress. There are a variety of different ways to handle the contention. High-priority traffic can be granted the entire bandwidth until the high-priority queue is empty. Other mechanisms allow for some “fair” distribution of bandwidth so that lower priority data cannot be completely starved of bandwidth. Exhibit 5.18 illustrates the concept of differentiated service based on priority. In this example, the router maintains three different priority queues (High, Medium, and Low) and allocates bandwidth based on some algorithm.
Exhibit 5.18 Differentiated Service Based on Priority
The mechanisms for prioritizing data and giving differentiated service levels to different data are rich and varied. It is important to understand the overall flow of data through an application server before an appropriate policy can be set. For example, an application server may connect to delay-sensitive applications, such as legacy transaction systems, in addition to applications that are not particularly sensitive to delays, such as message queuing systems. It is imperative that the people involved in the implementation and deployment of application server-based components and applications communicate with the networking staff that is setting and implementing network-based quality-of-service mechanisms.
Web-related traffic has impacted the networks of enterprises of all sizes. Studies have shown that organizations that implement intranets and Internet connectivity typically experience a huge spike in network traffic and resulting demand on bandwidth. As a result, network administration staffs have implemented a variety of defenses as a way of protecting traditional enterprise application traffic against the ever-increasing demands of Web traffic.
The queuing and prioritization mechanisms described in the previous section can assist in taming Web-related traffic. However, many of these mechanisms rely on classification by application type or port number. They do not have the ability to differentiate between a desirable and an undesirable Web site. An enterprise may have a policy that indicates that only certain Web sites are allowed to download Web pages and information to users. The rest are filtered out. Because an application server is involved in the middle tier, it is important that the application server implementers be involved and aware of the policies being implemented by the Web administration staff.
Another way of managing Web site traffic is in the use of Web caching devices. These devices, which are typically implemented close to the user, save frequently accessed pages and download them directly to the end user, thereby eliminating the need to repeatedly download certain popular pages across the wide area network. Unfortunately, the caching devices can implement policies that are inconsistent with the applications implemented on application servers. For example, a Web caching device might cache (or save) a particular JSP page. If the page changes, the Web caching devices might not automatically detect the update and may download outdated information to the end user. Application server developers should be aware of filtering and caching devices within the enterprise.
One of the key requirements of enterprises implementing E-business systems is that the infrastructure must scale to support an increasing number of users. Enterprises implement multiple physical servers or multiple software images to allow the environment to scale to support the required number of users. However, it is important that end users be shielded from the implementation within the enterprise. Users must have a single image or view of the enterprise.
Exhibit 5.19 Round-Robin Load Balancer
Load balancers within the network are a class of networking device that allows a defined set of servers or server images to appear as a single entity to the user base. Clients are able to identify a particular destination as a single entity. For example, all Web clients may see a single Web site name (e.g, www.amazon.com) that actually maps to many different physical systems. A network-based load balancer will serially allocate sessions across the multiple different servers. Therefore, if a particular Web site is implemented on five physical servers, the first session request would be mapped to server A, the second to server B, and so on. Exhibit 5.19 illustrates a multi-server environment that is served by a network-based round-robin load balancer.
Load balancers can either allocate sessions based on the round-robin basis illustrated, or they can allocate sessions based on some knowledge of the loads and capacities of the various servers. In the former example, no communication with the server is required. The load balancer simply keeps track of the last session allocated and moves to the next server in the list on the following session request. In the latter example, a protocol must be implemented between the load balancer and the server that provides information necessary to the load balancer to allow it to make balancing decisions. For example, the server may provide the load balancer with CPU utilization, active session counts, or other metrics upon which the load balancer can make its balancing decisions.
Application server developers should be aware of any network-based load balancers and implement any specific protocols that will be useful in effectively balancing application server traffic across multiple application servers.
The application server market is growing rapidly, and more and more vendors are entering the fray. With the more widespread implementation of the J2EE platform and the CORBA 2.x/3.0 specifications, the products will begin to look alike. Enterprises must look beyond the feature/function matrices put out by the vendors and select a product and a vendor that will best serve their needs. IT organizations should give precedence to vendors that demonstrate a commitment to open standards so that their options are left open in the future.
Today’s application servers are first differentiated based on the component model supported. Microsoft’s COM model is expected to be highly popular, especially in small and medium enterprise environments that have a relatively homogeneous environment. Most large enterprises, on the other hand, need to support a widely diverse and heterogeneous environment. These organizations are more likely to support a Java approach if they do not already have a large base of proprietary client/server, DCE-based, or CORBA-based distributed object applications. For very sophisticated, large enterprises, a CORBA approach, with its multi-language support and very sophisticated and complex services, may be the desired approach. Fortunately, the state of the technology and specifications are such that a large enterprise can quite comfortably implement all of the object models. For example, COM can be utilized in the department to tie together departmental-level objects, while Java can be used for all new component-based applications and existing CORBA systems are left in place. RMI-over-IIOP has become a critical technology for Java—CORBA interoperability, while COM interoperability can be determined by the capabilities implemented within the particular vendor’s product.
Once the Java and CORBA standards become more widely implemented, application server vendors will try to differentiate themselves through offering additional services, bundling the application server with tools and additional products, or offering related products. IT organizations should look beyond the feature and function offered in the base application server and consider the product line extensions that augment the application server when evaluating potential vendors.
It is critical that implementers of application servers within the IT organization understand the overall networking environment into which the application servers will go. Today’s enterprise network is much more than simple plumbing. Today’s enterprise network supports a rich variety of intelligent and adaptive network services. The new applications should take advantage of these network-based services where possible.
Finally, the implementers of application servers need to design the systems for the enterprise. They need to design systems that will protect the enterprise IT resources from intrusion or attack. They need to design systems that support the current and future number of concurrent users. Finally, they need to design systems that exhibit near-100 percent availability to the end user. Chapter 6 focuses on some of these elements of overall application server design.
Notes
1. June 20, 2000, Business Wire, Giga Information Group Predicts Application Server Market to Rise to $9 Billion by 2003.
2. January 2000, Network Magazine, Application Servers on Parade.
3. http://www.flashline.com/Components/appservermatrix.jsp.
4. Introduction to WebSphere Application Server Version 3.0, pp. 33-34.