Popular IBM Applications for Business - Literature review Example

IBM Tivoli Composite Application Manager for Response Time Tracking INTRODUCTION Software is the foundation of any business in the modern world. No organization today can manage to sustain itself without depending on software for some or all of its needs. The success of today’s business processes and models highly depends on the type of software application that is being used for those particular processes. Most of today’s work has now shifted from being paper based to being handled by complex software systems. However, the magnitude and range of these operations has encompassed so many domains and responsibilities that apart from using these applications, a new and important responsibility to maintain the health of these applications has evolved and this also includes the following four domains: Availability: the extent to which the application is available for use by the end users. Integrity: the degree to which the application is able to process and deliver the results correctly. Performance: The response time of the system in reaction to a set of queries from the user. Reliability: the degree to which the application’s results can be believed to be correct. Among these required capabilities of application health management, Integrity and reliability are facets inherent to the system while the availability and performance of a system is controlled by many other supporting components in addition to the application itself. The importance and availability of an application becomes even more important in environments where the application comprises numerous interconnected components. However, before proceeding with the discussion of the main topic, it is necessary to describe some popular IBM technologies and products that will be used as part of the discussion. These are the IBM DB2 universal database and the IBM WebSphere Application Server, each of which are as described below: IBM DB2 The IBM DB2 universal database is a pioneering product of IBM’s series of Relational Database Management Systems. In recent times, the DB2 has been integrated into the company’s Information Management Software line and has come to be associated with a broader range of products. The latest version of the database is 8.2 and numerous earlier versions with different capabilities and functionalities have been released before. The newer versions of the DB2 have been tagged as universal databases as they have come to be operated upon a range of devices from handheld PDAs to normal computers to Mainframe Systems. Apart from being able to be hosted by a number of Operating Systems such as Windows, Unix and Linux, DB2 also comes in versions that are capable of allowing it to operate as a Warehouse Edition (DB2 DWE). (IBM, 2006) The latest version of DB2, which is 8.2 benefits from a number of new features. Predominantly, it ships with an automated feature that allows it to self manage some of its processes and services. An example in this regard is a tool such as the Design Advisor, which assists the user in designing the database and the corresponding database schema. The latest version allows online import of data from external data sources. IBM DB2 also provides a number of libraries that allows DB2 based databases and services to be used within the .NET and Java Environments. The provision of tools and libraries for different product lines means that the environment is made more conducive for application development. the inclusion of support for different platforms also makes it more conducive for developing both platform intensive and platform independent applications. Apart from these provisions, DB2 is a tool that can be administered both from the command line and also through a Graphical User Interface (GUI). However, invoking the database application from the command line is not an easy process and requires that the user have avid experience over the interface. The User interface or operating the database has been developed over a Java Client that makes It suitable to be run over a number of platforms. Every task that can be performed over the database is handled over the interface by a number of wizards that ease the level of interaction on the part of the user. DB2 has been known to support both the SQL form of querying as well as the use of the XQuery. The data is stored within the system in XML format, which speeds up the process of data extraction, manipulation and storage (IBM, 2006). DB2 ships with built-in libraries for a number of programming languages and environments such as the .NET platform, Java Runtime, PHP, C/C++, COBOL and FORTRAN. Latest versions of IBM DB2 have also found their way into the Visual Studio IDE (Integrated Development Environment) and the Eclipse IDE. Another important feature that has been a hallmark of DB2 is its error processing capability. For being able to handle errors effectively, the IBM DB2 Universal Database uses the SQLCA (SQL Communications Area) structure that is used to return the error detail for every API call that the application programme makes to DB2 system through a SQL statement. In fact, a number of statistics connected with the error are usually displayed by the system (IBM, 2006). The DB2 system was available initially for use only under IBM Mainframes, which was the company’s flagship product. Over the course of the preceding years, the database has been evolving to encompass a number of popular operating systems and has made its way even into handheld devices . Another notable achievement of DB2 can be found in the area where DB2 has been driving the growth of hardware systems as well. This means that the system, has been helping the improvement of systems such as Parallel Sysplex data sharing and the database has been made so versatile that it can now be run on both 32 and 64 bit operating systems and has made its way into distributed systems as well. IBM WEBSPHERE APPLICATION SERVER The IBM Websphere application server is an application server that is an inherent component of the IBM’s Websphere range of products. Typically speaking, it is a server used to host other applications and has been developed using J2EE, XML and Web Services. The IBM Websphere Application Server works on a number of Popular web servers (HTTP Servers such as Microsoft IIS and Apache HTTP) and can be hosted by a number of operating systems in line with the IBM DB2 Universal Database (IBM 1). One of the most versatile features of IBM Db2 is that it favors the hosting and running of applications bearing a number of extensions. The whole set up runs on the foundation of beans, which includes profile beans, scheduling beans, start up beans and thread based beans. The IBM Websphere Application Server supports clustering and newer versions have been developed to ensure a high degree of availability within the environment. In order to speed the processing of data, all the log information is stored within a shared file system. Given the nature of clustering within the server environment, there is no provision of separate deployment as it is handled implicitly by the cluster (IBM, 2007). The IBM Websphere application Server is capable of working over a network based environment and uses a workload manager to prioritize the various process and services that are being run. The server also comes with a unique feature to recover lost items through the provision of Resource recovery services. It must be noted that the support for networking capabilities extends up to the mainframe environments as well. The server environment is highly scalable and this is made possible by the use of a control region which controls access to the various regions of the server thereby monitoring the amount of requests (IBM 5). The latest version of IBM Websphere application server supports the J2EE 1.4 Environment and the standard edition 1.5. it supports the use of portlets and uses Servlets as the base for communication. Support for Struts (JSF) and user administration is also provided. The server is known to have been incorporated with a number of security features that allows the user administration to allow access both at the user as well as the application level. This has been achieved through the use of improved certificate and key management techniques. There has also been an increased drive to be able to host numerous applications that cater to a number of requirements of the users as this has been seen as the primary requirement in order to popularize the product in the market (IBM, 2007). IBM TIVOLI COMPONENT APPLICATION MANAGER FOR RESPONSE TIME TRACKING The IBM Tivoli Component Application Manager is a suite of products that belongs to the application management division of the IBM Tivoli portfolio. This suite allows an organization to handle the maintenance and organization of the entire corporation’s IT infrastructure. The IBM Tivoli Component Application Manager consists of the following products, each of which is aimed at solving specific problem areas under IT Infrastructure management at an organizational level: IBM Tivoli Composite Application Manager for WebSphere IBM Tivoli Composite Application Manager for J2EE IBM Tivoli Composite Application Manager for Response Time Tracking IBM Tivoli Composite Application Manager for J2EE Operations IBM Tivoli Composite Application Manager for Internet Service Monitor IBM Tivoli Composite Application Manager for SOA IBM Tivoli Composite Application Manager for CICS Transactions IBM Tivoli Composite Application Manager for IMS™ Transactions OMEGAMON® XE for Messaging (IBM 25). The IBM Tivoli Composite Application Manager (known as ITCAM for short) for Response Time Tracking is an application suite that is structured around the IBM Tivoli Monitoring for Transaction Performance v.5.3. most of the properties and features of ITCAM RTT have been inherited from the this earlier product. The schematic for the ITCAM RTT is as shown below: The central component of ITCAM for Response Time Tracking is the RTT Management Server. As the name suggests, the ITCAM for RTT is capable of providing a centralized policy for policy management, configuration as also handling of data within the ITCAM for Response Time Tracking. The second most important components under the ITCAM for RTT are the Management Agents, which are nothing but simple action-response agents of the management server. The management agents are responsible for the performance and data collection and sending them as feedback to the management server. Every management agent can be configured to be consisted of different components depending on the range of operations that need to be handled by each of that management agent (IBM 15). The management server and the management agents communicate among one another using ports and sockets and all communication is secured by the use of firewalls at each interface between the server and the agents. Of course, there is also an option to operate under an unrestricted environment that is free of any firewalls. The idea behind the use of a firewall is simply for the purpose of allowing the server agent communication to take place via a single port thereby bringing in a greater sense of control into the system. Additionally, the RTT management server and agent cannot communicate directly and are instead dependent on the use of another critical component, namely the store-and-forward agent (IBM 19). Typically speaking, the store-and-forward agent works towards facilitating the communication between the agent and the server through the use of a single port. An additional capability of the store-and-forward agent is that it can be cascaded, which means that an organization will be able to use a series of store-and-forward agents each of the connected to a number of management agents and capable of communication back and forth with the management server through the use of numerous firewalls. It must be noted in this aspect that the it is these store-and-forward agents that are connected to each other through the use of firewalls and this is the medium through which all the communication takes place (IBM 16). ARCHITECTURE OF ITCAM for RTT The architecture of the ITCAM for RTT is as described in detail below. The architecture consists of thee primary components: RTT Management Server. RTT Management Agent. RTT Store and Forward Agent (IBM 14). RTT Management Server The ITCAM RTT Management Server is a J2EE (Java 2 Enterprise Edition) based application that utilizes DB2 as the database and used JDBC for the appropriate database connectivity. The RTT management server is hosted by a Web Sphere Application Server. The schematic for the communication is as shown below: An interesting feature of the RTT management server is that it can be used within a clustered environment. The communication flow is as shown below: As seen from the picture above, a clustered management server works by the collaboration among a number of independent servers. It primarily consists of a Websphere Edge Server, a Websphere application server cluster and a database. The purpose of the Websphere edge server is to ensure the load balance of the system. The purpose of using a clustered management server is manifold. Primarily, it solves the purpose of opting for a clustered system by allowing the workload to be shared by a number of processing instead of putting the entire burden on a single entity. Another primary advantage of the cluster based server is that it can operate in a fail-safe mode, wherein the failure of one system to operate does not affect the operation of the entire cluster and the workload is instead transferred to other nodes in the cluster. However, the clustered management is plagued with problems typical of a clustered environment such as the overhead of communication among various nodes. Additionally, setting up a clustered management server is a complex process is comparison to setting up a standalone management server (IBM 9). However, despite these advantages and limitations, a management server is capable of providing a number of functions. The prime role of the management server is to allow every management agent to log into it so as to be able to retrieve information about all the policies in place. The management server is also the place where one is supposed to store all the configurations as also keep up with its maintenance. The management agent is also responsible for the management of users and user groups. This user management is performed through the use of a web interface (IBM 20). STORE AND FORWARD AGENT As has been described before, the store and management agent works as a simple intermediary between the Management Server and the Management Agent. The working of a Store and Forward Agent in the ITCAM for RTT set up is as shown below: The store and forward agent restricts the communication between the management server and agent by utilizing a single port for the purpose of all such communication. Additionally, the store and forward agent can be cascaded, which means that there can be a number of such agents within an ITCAM network. The store and forward agent utilizes the services of the IBM Websphere Server’s Caching Proxy feature to optimize the connections with the Management Server. Apart from this, the agent also facilitates the use of different ports for the purpose of secure/non secure communication. The cascaded use of store and forward agents has been shown in the preceding pages (IBM 11). MANAGEMENT AGENT The management agent run in a Java Run time Environment and is hosted on a managed server. It predominantly performs a number of functions. Apart from collecting policy related data from the management server, the management agent is also responsible for the start up and shut down of management components. The management agent also works by directing the various management components on the activities that need to be performed. Most of the communication between the agent and the management server takes place is concerned with reporting back the response times from the former to the latter. The management agent provides flexibility in this regard by allowing the policy to either choose for regular updates of response times or by opting for updating on demand (IBM 17). ENTERPRISE MONITORING AGENT The enterprise monitoring agent is a separate component within the ITCAM for response time tracking and must be a part of the Enterprise Monitoring Server, Enterprise Portal Server and the Enterprise Portal. MANAGEMENT OF ITCAM FOR RTT The Management policies within the ITCAM for RTT are applied within the environment in a number of ways, which are discussed in the forthcoming paragraphs. This is discussed as a series of sections, each of which will detail the management methodology under ITCAM for Response Time Tracking. MANAGEMENT RESOURCES There are a number of management resources that are used within the ITCAM for Response Time Tracking. These are as explained below: Reporting Group: this is a collection of monitors that share common attributes. Agent Group: this is a group of Management Agents that allows common management policies to be applied to the different members of the Agent group. Schedule: the rules based on time, which are applicable to the system. Discovery: the detection of the process or server element. Listening Monitor: this resource collects the response time from the server based applications. Robotic Monitor: this resource is used to send automated instructions and transactions using tools such as Client Application Tracker or Rational Robot (IBM 21). Among these resources, the Agent group and the Reporting group hold most prominence. AGENT GROUP An Agent group in a way assists the installation of a Reporting Group. This is achieved when the Agent group decides the places where the monitor needs to be placed. This is shown in the figure below: The above figure depicts three management agents out of which one of them falls within both the geographical groups. Out of these, it is intended to monitor the trading under Agents 1 & 2, while it is also desired to monitor the eBanking under Agents 2 & 3. Thus, these individual monitoring requirements would require the need for a separate monitoring group for each of these regions. Note that this also means that each of these agents can fall under more than one groups at any given instant and can be reconfigured to put them under different groups as desired (IBM 18). REPORTING GROUP The basic difference between a reporting group and an Agent group is that the former does not affect the execution of monitors, while the latter can as has been shown above. Instead, a reporting group is used to provide a superficial role as they are only used to control the access to certain features under the applications and this is achieved by the definition of different roles that are used to provide access to the different features. These roles are simply the specification whether the particular monitor within a reporting group is allowed read or update access. in fact, a reporting group can be used for a variety of purposes (IBM 10). Firstly, a reporting group governs the control on the level of access that can be granted to every entity, which are essentially read, write and none access levels. Such a configuration allows for the easing of workload on the operators. The reporting group also allows for the provision of aggregation capabilities, which simplifies the reporting needs of a complex environment. It is also advocated that in order to ease the administration process, it is best to document each and every aspect of the computing environment (IBM 29). MANAGEMENT IMPLEMENTATION There a number of aspects that needs to be looked after in order to be able to ensure the correct implementation of management methodologies under ITCAM for RTT. These are as explained below: Define and create the Agent groups that can facilitate the Management agents in creating monitors for different agents as and where required. Define Reporting Groups that will act as placeholders for the monitors created by the Agent Groups. This is accomplished by allowing the definition and creation of reporting groups for allowing requisite access to different kinds of operators. Define the various monitoring schedules that will be used to keep track of the schedule of various monitoring transactions. Detect the various transactions at all levels within the application environment. Create separate monitors that will monitor every identified transaction. Automate the invocation and execution of certain transactions using appropriate tools such as the Client Application Tracker or Rational Robot. Use the same automation tools for creating and running robotic monitors (IBM 8). IMPLEMENTATION PROCESS The implementation of the IBM Tivoli Composite Application Manager for Response Time Tracking is a step-by-step process and involves a number of steps that are explained below: 1. The first and the foremost step during the implementation of ITCAM for RTT is the planning of the overall configuration of the application. One has to decide the various applications that need to be monitored, determine the kind of monitors that need to be installed in order to monitor them and also decide upon the server configuration in order to be able to implement the whole system in an efficient manner. The ITCAM for RTT supports both single-server as well as a cluster-server environment. This means that the methods described here will apply to both the available configurations unless specified otherwise. Additionally, the server tracking would have to take care of the installation of the Response Time Tracking management server as well as the deployment of the Management Agent. 2. it is also extremely important as part of the next step to understand that the Response Time Tracking Management Server is the core of the whole monitoring application. Therefore, it is always advised to install and deploy the ITCAM for Response Time Tracking Management Server before proceeding ahead with the installation of any other component. 3. The ITCAM for RTT Management Agent is installed on all of the Managed Servers that are under the control of the Management Server by way of a governing policy. It is important to note here that the various management components must not be installed at this juncture. With the Management Agent in place, it is an ideal time to deploy the Management Components, which is done through the use of a Management Console Web Interface. when a management agent is installed without checking its connection with a Management Server, it is known as an Offline Agent. However, it is recommended to verify the communication status among various elements at this point. 4. The management components are like the actual working components of the Management Agent. As such, the work of a Management Agent is to collect the various parameter data from the Management Components and send them to the management server in the proper format. 5. With most of the elements in place, the subsequent step is to integrate the ITCAM for RTT Environment with the IBM Tivoli Monitoring Environment. 6. With the ITCAM for RTT infrastructure in place, the next step is to create the actual objects that will be used to affect the actual monitoring process. Some of the typical monitoring objects include schedules, Agent groups and reporting groups. There is an option to create default schedules and Agent Groups, which can however be bypassed to custom install all the monitoring objects (IBM 2). The process of monitoring the ITCAM for Response Time Tracking is achieved by any of the three types of methods: Discovery: discovery encompasses the definition and detection of an area within the environment where sampling and investigation of he transaction activity data is performed by measuring the actual and average performance times. Listening Monitor: the performance data is gathered and specific information about the transaction performance times is calculated and analyzed to arrive at possible conclusions as desired and configured. Such an analysis using the listening monitor allows for targeting specific problems at the particular component. Robotic Monitor: the same transactions can also be run from an automated environment such as a robotic workplace. The most impressive feature of robotic monitors is that they allow for the recognition of the problem area beforehand by simply analyzing the status of the various components using robotic monitors at all times (IBM 3). However, the implementation process of ITCAM for Response Time Tracking has certain considerations that need to be looked into during the time of installation of the system. These considerations cover both the agent as well as the server configuration and deployment. Each of them are explained below: CONSIDERATIONS FOR MANAGEMENT SERVER as has been mentioned before, the ITCAM for RTT’s Management Server is the core of the Monitoring Application. Its major task is to retrieve information from and issue service commands to the various Management Agents. As such, it is imperative that the Management server must be the first component that needs to be installed during the implementation process and it is also important to decide upon the proper deployment of the Management Server beforehand. There are a number of modes in which a Management Server can be installed: Single Server-Silent: this is an automated process where a single Management Server is installed from the command line. As such, this process is a fairly automated affair. Single Server-Typical: in addition to installing the ITCAM for Response Time Tracking under a single server mode, the DB2 database back end as well as the IBM Websphere application server is installed. Single Server-Custom: with this option, once can choose to install either a DB2 or an Oracle database along with the ITCAM for RTT response package. It additionally allows the user to choose whether to install the IBM Websphere Application Server along with these components. Upgrade: as the name suggests, this option is useful when it is desired to upgrade from an existing version of the ITCAM for Response Time Tracking. Cluster: this option is chosen in scenarios where it is chosen to deploy a multitude of ITCAM for RTT Management Servers into an existing IBM Websphere Application Server Cluster Environment. The benefit of this option is that provides for stability and fault tolerance during and after installation (IBM 7). CONSIDERATIONS FOR MANAGEMENT AGENT The Management Agents are entrusted the task of identifying all the transactions that require some form of monitoring, collect data from that as and when required and configured and send the appropriate information to the Management Server. As such, the Management Agent must be deployed on every system that requires such monitoring capabilities. While the process of monitoring of transactions is handled by a Monitoring component, a Management Agent is needed to maintain control over all such Monitoring Agents (IBM 4). ITCAM RTT-INTRANET SCRIPTING //need info ITCAM INTERNET SERVICE MONITORS The ITCAM suite of applications includes an Internet Service Monitoring component that is the latest name for the Netcool Service Monitor. The primary service of this application component is to determine the availability and responsiveness of Internet applications in a lightweight fashion. This component has gained popularity among users as it supports as many as 20 different Internet (TCP/IP) based protocols. The new Netcool monitoring component under the name Internet Service Monitors provides for the monitoring of the following classes of entities: Hosts. Internet based Applications. Local Software Applications. The ITCAM for Internet Service Monitoring component supports the processes within other applications found under the ITCAM Suite including ITCAM for Response Time Tracking. The new monitoring components assists in Loading Configuration data, generating reporting data, reporting the data to the associated entities and issuing alerts as and when required. As such, ITCAM for ISM (short for Internet Service Monitoring) assists the user in conducting tests and trials of the systems in use. The schematic of ITCAM for ISM is as shown below (IBM 6): The primary component of this product is the set of monitors that are used to test specific Internet based services and transfer the test results to the Data Bridge. This is especially used in testing the web interface that is used for controlling most of the aspects of ITCAM for Response Time Tracking. The monitoring component tests the system by sending emulator requests to the web interface and collects the corresponding results based on the events generated within the interface. The information from these events is transformed implicitly by the system into evaluation data and displayed as the test result in the requisite format. The ISM Server is entrusted with the task of overlooking the operation and maintenance of ITCAM for ISM. This is achieved by the ISM Server through the use of profiles and Service level agreements (SLAs). The Data Bridge, as the name implies, is a communication channel between the monitors and the other components that need access to data collected by the monitors. However, the main part of the ITCAM for ISM is the Netcool SM Reporter that provides solutions for displaying the test results and generating reports. All the generated information can be stored as required by using the Netcool Object Server, which stored the data in a format suitable for fast storage, processing and retrieval of data. The Netcool License Server is a server component that works as a collection of licensing rules and legislations that applies to the Netcool suite of products (IBM 12). REFERENCES 1) WebSphere Studio Application Monitor V3.2 Advanced Usage Guide, SG24-6764 2) IBM Tivoli Composite Application Manager for Response Time Tracking V6.1 Prerequisites, SC32-9486 3) Large-Scale Implementation of IBM Tivoli Composite Application Manager, REDP-4162 4) Getting Started with IBM Tivoli Monitoring V6.1 , SG24-7143 5) Installing WebSphere Studio Application Monitor V3.1, SG24-6491 6) End-to-End e-business Transaction Performance with IBM TMTP 5.1, SG24-6912 7) IBM Tivoli OMEGAMON V3.1.0 Deep Dive on z/OS, SG24-7155 8) Solution Deployment Guide for IBM Tivoli Composite Application Manager for WebSphere, SG24-7293 9) Deployment Guide Series: IBM Tivoli Composite Application Manager for WebSphere V6.0, SG24-7252 10) IBM Tivoli Composite Application Manager for Response Time Tracking V6.1 Program Directory for z/OS, GI11-4099 11) IBM Tivoli Composite Application Manager for Response Time Tracking V6.1 Administrators Guide, SC32-9483 12) IBM Tivoli Monitoring Installation and Setup Guide, GC32-9407 13) IBM Tivoli Monitoring: Upgrading from Tivoli Distributed Monitoring, GC32-9462 14) Introducing IBM Tivoli Monitoring, GI11-4071 15) IBM Tivoli Composite Application Manager for Response Time Tracking V6.1 Problem Determination Guide, SC32-9513 16) IBM Tivoli Monitoring Administrator's Guide, SC32-9408 17) IBM Tivoli Composite Application Manger for Response Time Tracking V6.1 Installation and Configuration Guide, GC32-9482 18) IBM Tivoli Composite Application Manager for Response Time Tracking V6.1 Checking Performance and Availability, SC32-9484 19) IBM Tivoli Composite Application Manager for Response Time Tracking V6.1: Installing a Management Server in a WebSphere Cluster Environment, SC32-1804 20) Implementing OMEGAMON XE for Messaging V6.0, SG24-7357 21) IBM Tivoli Monitoring User's Guide, SC32-9409 22) IBM Tivoli Composite Application Manager for Response Time Tracking V6.1 Command Reference Guide, SC32-9485 23) IBM (2006), Information on IBM DB2 Universal Database. Found at: http://publib.boulder.ibm.com/infocenter/db2luw/v8//index.jsp 24) IBM (2007), Information on IBM WebSphere Application Server. Found at: http://www.redbooks.ibm.com/abstracts/redp3918.html 25) IBM Tivoli Composite Application Manager V6.1 Family Installation, Configuration and Basic Usage, SG24-7151-01 NOTE: Since all the publications have been from IBM, the references shall be cited as IBM followed by the number under which the reference is listed above (For example: IBM 22 refers to IBM Tivoli Composite Application Manager for Response Time Tracking V6.1 Command Reference Guide, SC32-9485) Read More