1.3 e-business applications: complex layers of services

---

1.3 e-business applications: complex layers of services

A modern e-business solution is much more complex than the standard terminal processing-oriented systems of the 1970s and 1980s, as illustrated in Figure 1-2 on page 12. However, despite major revisions, especially during the turn of the last century, legacy systems are still the bread-and-butter of many enterprises, and the e-business solutions in these environments are designed to front-end these mainframe-oriented application complexes.

Figure 1-2: Growing infrastructure complexity

The complex infrastructure needed to facilitate e-business solutions has been dictated mostly by requirements for standardization of client run-time environments in order to allow any standard browser to access the e-business sites. In addition, application run-time technologies play a major role, as they must ensure platform independence and seamless integration to the legacy back-end systems, either directly to the mainframe or through the server part of the old client-server solution. Furthermore, making the applications accessible from anywhere in the world by any person on the planet raises some security issues (authentication, authorization, and integrity) that did not need addressing in the old client-server systems, as all clients were well-known entities in the internal company network.

Because of the central role that the Web and application servers play within a business and the fact that they are supported and typically deployed across a variety of platforms throughout the enterprise, there are several major challenges to managing the e-business infrastructure, including:

• Managing Web and application servers on multiple platforms in a consistent manner from a central console

• Defining the e-business infrastructure from one central console

• Monitoring Web resources (sites and applications) to know when problems have occurred or are about to occur

• Taking corrective actions when a problem is detected in a platform independent way

• Gathering data across all e-business environments to analyze events, messages, and metrics

The degree of complexity of e-business infrastructure system management is directly proportional to the size of the infrastructure being managed. In its simplest form, an e-business infrastructure is comprised of a single Web server and its resources, but it can grow to hundreds or even thousands of Web and application servers throughout the enterprise.

To add to the complexity, the e-business infrastructure may span many platforms with different network protocols, hardware, operating systems, and applications. Each platform possesses its unique and specific systems management needs and requirements, not to mention a varying level of support for the administrative tools and interfaces.

Every component in the e-business infrastructure is a potential show-stopper, bottleneck or even single point of failure. Each and every one provides specialized services needed to facilitate the e-business application system. The term application systems is used deliberately to enforce the point that no single component by itself provides a total solution: the application is pieced together by a combination of standard off-the-shelf components and home-grown components. The standard components provide general services, such as session control, authentication and access control, messaging, and database access, and the home-grown components add the application logic needed to glue all the different bits and pieces together to perform the specific functions for that application system. On an enterprise level, chances are that many of the home-grown components may be promoted to standard status to ensure specific company standards or policies.

At first glance, breaking up the e-business application into many specialized services may be regarded as counterproductive and very expensive to implement. However, specialization enables sharing of common components (such as Web, application, security, and database servers) between more e-business application systems, and it is key to ensuring availability and performance of the application system as a whole by allowing for duplication and distribution of selected components to meet specific resource requirements or increase the performance of the application systems as a whole. In addition, this itemizing of the total solution allows for almost seamless adoption of new technologies for selected areas without exposing the total system to change.

Whether the components in the e-business system are commercial, standard, or application-specific, each of them will most likely require other general services, such as communication facilities, storage space, and processing power, and the computers on which they run need electrical power, shelter from rain and sun, access security, and perhaps even cooling.

As it turns out, the e-business application relies on several layers of services that may be provided internally or by external companies. This is illustrated in Figure 1-3.

Figure 1-3: Layers of service

As a matter of fact, it is not exactly the e-business application that relies on the services depicted above. The correct notion is that individual components (such as Web servers, database servers, application servers, lines, routers, hubs, and switches) each rely on underlying services provided by some other component. This can be broken down even further, but that is beyond this discussion. The point is that the e-business solution is exactly as solid, robust, and stable as the weakest link of the chain of services that make up the entire solution, and since the bottom-line results of an enterprise may be affected drastically by the quality of the e-business solutions provided, a worst-case scenario may prove that a power failure in Hong Kong may have an impact on sales figures in Greece and that increased surface activity on the sun may result in satellite-communication problems that prevent car rental in Chattanooga.

While mankind cannot prevent increased activity of the sun and wind, there are a number of technologies available to allow for continuing, centralized monitoring and surveillance of the e-business solution components. These technologies will help manage the IT resources that are part of the e-business solution. Some of these technologies may even be applied to manage the non-IT resources, such as power, cooling, and access control.

However, each layer in any component is specialized and requires different types of management. In addition, from a management point of view, the top layer of any component is the most interesting, as it is the layer that provides the unique service that is required by that particular component. For a Web server, the top layer is the HTTP server itself. This is the mission-critical layer, even though it still needs networking, an operating system, hardware, and power to operate. On the other hand, for an e-business application server (although it also may have a Web server installed for communicating with the dedicated Web Server), the mission-critical layer is the application server, and the Web server is considered secondary in this case, just as the operating system, power, and networking are. This said, all the underlying services are needed and must operate flawlessly in order for the top layer to provide its services. It is much like driving a car: you monitor the speedometer regularly to avoid penalties by violating changing speed limits, but you check the fuel indicator only from time to time or when the indicator alerts you to perform preventive maintenance by filling up the tank.

1.3.1 Managing the e-business applications

Specialized functions require specialized management, and general functions require general management. Therefore, it is obvious that the management of the operating system, hardware layer, and networking layer may be may be general, since they are used by most of the components of the e-business infrastructure. On the other hand, a management tool for Web application servers might not be very well-suited for managing the database server.

Up till now, the term "managing" has been widely used, but not yet explained. Control over and management of the computer system and its vital components are critical to the continuing operation of the system and therefore the timely availability of the services and functions provided by the system. This includes controlling both physical and logical access to the system to prevent unauthorized modifications to the core components, and monitoring the availability of the systems as a whole, as well as the performance and capacity usage of the individual resources, such as disk space, networking equipment, memory, and processor usage. Of course, these control and monitoring activities have to be performed cost-effectively, so the cost of controlling any resource does not become higher than the cost of the resource itself. It does not make much business sense to spend $1000 to manage a $200 hard disk, unless the data on that hard disk represents real value to the business in excess of $1000. Planning for recovery of the systems in case of a disaster also needs to be addressed, as being without computer systems for days or weeks may have a huge impact on the ability to conduct business.

There still is one important aspect to be covered for successfully managing and controlling computer systems. We have mentioned various hardware and software components that collectively provide a service, but which components are part of the IT infrastructure, where are they, and how do they relate to one another? A prerequisite for successful management is the detailed knowledge of which components to manage, how the components interrelate, and how these components may be manipulated in order to control their behavior.

In addition, now that IT has become an integral part of doing business, it is equally important from an IT management point of view to know which commitments we have made with respect to availability and performance of the e-business solutions, and what commitments our subcontractors have made to us. And for planning and prioritization purposes, it is vital to combine our knowledge about the components in the infrastructure with the commitments we have made in order to assess and manage the impact of component malfunction or resource shortage. In short, in a modern e-business environment, one of the most important management tasks is to control and manage the service catalogue in which all the provisioned services are defined and described, and the SLAs in which the commitments of the IT department are spelled out.

For this discussion, we turn to the widely recognized Information Technology Infrastructure Library (ITIL). The ITIL was developed by the British Government's Central Computer and Telecommunications Agency (CCTA), but has over the past decade or more gained acceptance in the private sector.

One of the reasons behind this acceptance is that most IT organizations, met with requirements to promise or even guarantee performance and availability, agree that there is no point in agreeing to deliver a service at a specific level if the basic tools and processes needed to deploy, manage, monitor, correct, and report the achieved service level have not been established. ITIL groups all of these activities into two major areas, Service Delivery and Service Support, as shown in Figure 1-4 on page 17.

Figure 1-4: The ITIL Service Management disciplines

The primary objectives of the Service Delivery discipline are proactive and consist primarily of planning and ensuring that the service is delivered according to the Service Level Agreement. For this to happen, the following tasks have to be accomplished.

Service Delivery

Within ITIL, the proactive disciplines are grouped in the Service Delivery area, which are covered in the following sections.

Service Level Management

Service Level Management involves managing customer expectations and negotiating Service Level Agreements. This involves identifying customer requirements and determining how these can best be met within the agreed-upon budget, as well as working together with all IT disciplines and departments to plan and ensure delivery of services. This involves setting measurable performance targets, monitoring performance, and taking action when targets are not met.

Cost Management

Cost Management consists of registering and maintaining cost accounts related to the use of IT services and delivering cost statistics and reports to Service Level Management to assist in obtaining the correct balance between service cost and delivery. It also means assisting in pricing the services in the service catalog and SLAs.

Contingency Planning

Contingency Planning develops and ensures the continuing delivery of minimum outage of the service by reducing the impact of disasters, emergencies, and major incidents. This work is done in close collaboration with the company's business continuity management, which is responsible for protecting all aspects of the company's business, including IT.

Capacity Management

Capacity Management plans and ensures that adequate capacity with the expected performance characteristics is available to support the service delivery. It also delivers capacity usage, performance, and workload management statistics (as well as trend analysis) to Service Level Management.

Availability Management

Availability Management means planning and ensuring the overall availability of the services and providing management information in the form of availability statistics, including security violations, to Service Level Management.

Even though not explicitly mentioned in the ITIL definition, for this discussion, content management is included in this discipline.

This discipline may also include negotiating underpinning contracts with external suppliers and the definition of maintenance windows and recovery times.

The disciplines in the Service Support group are mainly reactive and are concerned with implementing the plans and providing management information regarding the levels of service achieved.

Service Support

The reactive disciplines that are considered part of the Service Support group are shown in the following sections.

Configuration Management

Configuration Management is responsible for registering all components in the IT service, including customers, contracts, SLAs, hardware and software components, and maintaining a repository of configured attributes and relationships between the components.

Help Desk

The Help Desk acts as the main point of contact for users of the service. It registers incidents, allocates severity, and coordinates the efforts of support teams to ensure timely and accurate problem resolution.

Escalation times are noted in the SLA and are agreed on between the customer and the IT department. The Help Desk also provides statistics to Service Level Management to demonstrate the service levels achieved.

Problem Management

Problem Management implements and uses procedures to perform problem diagnosis and identify solutions that correct problems. It also registers solutions in the configuration repository.

Escalation times should be agreed upon internally with Service Level Management during the SLA negotiation. It also provides problem resolution statistics to support Service Level Management.

Change Management

Change Management plans and ensures that the impact of a change to any component of a service is well known and that the implications regarding service level achievements are minimized. This includes changes to the SLA documents and the Service Catalog as well as organizational changes and changes to hardware and software components.

Software Control and Distribution

It is the responsibility of Software Control and Distribution to manage the master software repository and deploy software components of services. It also deploys changes at the request of Change Management, and provides management reports regarding deployment.

The key relationships between the disciplines are shown in Figure 1-5 on page 20.

Figure 1-5: Key relationships between Service Management disciplines

For the remainder of this discussion, we will limit our discussion to capacity and availability management of the e-business solutions. Contrary to the other disciplines that are considered common for all types of services provided by the IT organization, the e-business solutions provide special challenges to management, due to their high visibility and importance to the bottom line business results, their level of distribution, and the special security issues that characterize the Internet.

1.3.2 Architecting e-business application infrastructures

In a typical e-business environment, the application infrastructure consists of three separate tiers, and the communication between these is restricted, as Figure 1-6 shows.

Figure 1-6: A typical e-business application infrastructure

The tiers are typically:

Demilitarized Zone	The tier accessible by all external users of the applications. This tier functions as the gatekeeper to the entire system, and functions such as access control and intrusion detection are enforced here. The only other part of the intra-company network that the DMZ can talk to is the application tier.
Application Tier	This is usually implemented as a dedicated part of the network where the application servers reside. End-user requests are routed from the DMZ to the specific servers in this tier, where they are serviced. In case the applications need to use resources from company-wide databases, for example, these are requested from the back-end tier, where all the secured company IT assets reside. As was the case for communication between the DMZ and the Application Tier, the communication between the Application Tier and the back-end systems is established through firewalls and using well-known connection ports. This helps ensure that only known transactions from known machines outside the network can communicate with the company databases or legacy transaction systems (such as CICS® or IMS™). Apart from specific application servers, this tier also hosts load-balancing devices and other infrastructural components (such as MQ Servers) needed to implement a given application architecture.
Back-end Tier	This is where all the vital company resources and IT assets reside. External access to these resources is only possible through the DMZ and the Application Tier.

This model architecture is a proven way to provide secure, scalable, high-availability external access to company data with a minimum of exposure to security violations. However, the actual components, such as application servers and infrastructural resources, may vary depending upon the nature of the applications, company policies, the requirements to availability and performance, and the capabilities of the technologies used.

If you are in the e-business hosting area or you have to support multiple lines of business that require strict separation, the conceptual architecture shown in Figure 1-6 on page 21 may be even more complicated. In these situations, one or more of the tiers may have to be duplicated to provide the required separation. In addition, the back-end tier might even be established remotely (relative to the application tier). This is very common when the e-business application hosting is outsourced to an external vendor, such as IBM Global Services.

To help design the most appropriate architecture for a specific set of e-business applications, IBM has published a set of e-business patterns that may be used to speed up the process of developing e-business applications and deploying the infrastructure to host them.

The concept behind these e-business patterns is to reuse tested and proven architectures with as little modification as possible. IBM has gathered experiences from more than 20,000 engagements, compiled these into a set of guidelines, and associated them with links. A solution architect can start with a problem and a vision for the solution and then find a pattern that fits that vision. Then, by drilling down using the patterns process, the architect can further define the additional functional pieces that the application will need to succeed. Finally, the architect can build the application using coding techniques outlined in the associated guidelines. Further details on e-business patterns may be found in Appendix A, "Patterns for e-business" on page 429.

For a full understanding of the patterns, please review the book Patterns for e-business: A Strategy for Reuse by Adams, et al.

1.3.3 Basic products used to facilitate e-business applications

So far, we may conclude that building an e-business solution is like building a vehicle, in the sense that:

• We want to provide the user with a standard, easy-to-use interface that fulfills the needs of the user and has a common look-and-feel to it.

• We want to use as many standard components as possible to keep costs down and be able to interchange them seamlessly.

• We want it to be reliable and available at all times with a minimum of maintenance.

• We want to build in unique features (differentiators) that make the user choose our product over those of the competitors.

The main difference between the vehicle and the e-business solution is that we own and control the solution, but the buyer owns and manages the vehicle. The vehicle owner decides when to have the oil changed and when to fill up the fuel tank or adjust the tire pressure. The vehicle owner also decides when to take the vehicle in for a tune-up, when to add chrome bumpers and alloy wheels to make the vehicle look better, and when to sell it. The user of an e-business site has none of those choices. As owners of the e-business solution, we decide when to rework the user interface to make it look better, when to add resources to increase performance, and ultimately when to retire and replace the solution.

This gives us a few advantages over the car manufacturer, as we can modify the product seamlessly by adding or removing components as needed in order to align the performance with the requirements and adjust the functionality of the product as competition toughens or we engage in new alliances.

No matter whether the e-business solution is the front-end of a legacy system or a new application developed using modern, state-of-the-art development tools, it may be characterized by three specific layers of services that work together to provide the unique functionality necessary to allow the applications to be used in an Internet environment, as shown in Figure 1-7 on page 24.

Figure 1-7: e-business solution-specific service layers

The presentation layer must be a commonly available tool that is installed on all the machines used by users of the e-business solution. It should support modern development technologies such as XML, JavaScript, and HTML pages, and usually is the browser.

The standard communication protocols used to provide connectivity using the Internet are TCP/IP, HTTP, and HTTPS. These protocols must be supported by both client and server machines.

The transformation services are responsible for receiving client requests and transforming them into business transactions that in turn are served by the Solution Server. In addition, it is the responsibility of the transformation service to receive results from the Solution Server and convey them back to the client in a format that can be handled by the browser. In e-business solutions that do not interact with legacy systems, the transformation and Solution Server services may be implemented in the same application, but most likely they are split into two or more dedicated services.

This is a very simple representation of the functions that take place in the transformation service. Among other functions that must be performed are identification, authentication and authorization control, load balancing, and transaction control. Dedicated servers for each of these functions are usually implemented to provide a robust and scalable e-business environment. In addition, some of these are placed in a dedicated network segment (the demilitarized zone (DMZ)), which, from the point of view of the e-business owner, is fully controlled, and in which client requests are received by "well-known," secure systems and passed on to the enterprise network, also known as the intranet. This architecture is used to increase security by avoiding transactions from "unknown" machines to reach the enterprise network, thereby minimizing the exposure of enterprise data and the risk of hacking.

To facilitate secure communication between the DMZ and the intranet, a set of Web servers is usually implemented, and identification, authentication, and authorization are typically handled by an LDAP Server.

The infrastructure depicted in Figure 1-8 contains all components required to implement a secure e-business solution, allowing anyone from anywhere to access and do business with the enterprise.

Figure 1-8: Logical view of an e-business solution

For more information on e-business architectures, please refer to the redbook Patterns for e-business: User to Business Patterns for Topology 1 and 2 Using WebSphere Advanced Edition, SG24-5864, which can be downloaded from http://www.redbooks.ibm.com®.

Tivoli and IBM provide some of the most widely used products to implement the e-business infrastructure. These are:

IBM HTTP Server	Communication and transaction control
Tivoli Access Manager	Identification, authentication, and authorization
IBM WebSphere Application Server	Web application hosting, responsible for the transformation services
IBM WebSphere Edge Server	Web application firewalling, load balancing, Web hosting; responsible for the transformation services

1.3.4 Managing e-business applications using Tivoli

Even though the e-business patterns help in designing e-business applications by breaking them down into functional units that may be implemented in different tiers of the architecture using different hard- and software technologies, the patterns provide only some assistance in managing these applications. Fortunately, this gap is filled by solutions from Tivoli Systems.

When designing the systems management infrastructure that is needed to manage the e-business applications, it must be kept in mind that the determining factor for the application architecture is the nature of the application itself. This determines the application infrastructure and the technologies used. However, it does not do any harm if the solution architect consults with systems management specialists while designing the application.

The systems management solution has to play more or less by the rules set up by the application. Ideally, it will manage the various application resources without any impact on the e-business application, while observing company policies on networking use, security, and so on.

Management of e-business applications is therefore best achieved by establishing yet another networking tier, parallel to the application tier, in which all systems management components can be hosted without influencing the applications. Naturally, since the management applications have to communicate with the resources that must be managed, the two meet on the network and on the machines hosting the various e-business application resources.

Using the Tivoli product set, it is recommended that you establish all the central components in the management tier and have a few proxies and agents present in the DMZ and application tiers, as shown in Figure 1-9 on page 27.

Figure 1-9: Typical Tivoli-managed e-business application infrastructure

Implementing the management infrastructure in this fashion, there is minimal interference between the application and the management systems, and the access to and from the various network segments is manageable, as the communication flows between a limited number of nodes using well-known communication ports.

IBM Tivoli management products have been developed with the total environment in mind. The IBM Tivoli Monitoring product provides the basis for proactive monitoring, analysis, and automated problem resolution.

As we will see, IBM Tivoli Monitoring for Transaction Performance provides an enterprise management solution for both the Web and enterprise transaction environments. This product provide solutions that are integrated with other Tivoli management products and contribute a key piece to the goal of a consistent, end-to-end management solution for the enterprise.

By using product offerings such as IBM Tivoli Monitoring for Transaction Performance in conjunction with the underlying Tivoli technologies, a comprehensive and fully integrated management solution can be deployed rapidly and provide a very attractive return on investment.

---