WebSphere

Subscribe to WebSphere: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get WebSphere: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


IBM WebSphere software products Authors: Yeshim Deniz, hyper filter, Timothée Bensimon, XebiaLabs Blog, Javier Paniza

Related Topics: Java EE Journal, WebSphere

J2EE Journal: Article

Managing the WebSphere Platform - Getting an end-to-end view of your applications

Managing the WebSphere Platform - Getting an end-to-end view of your applications

Your applications have just gone through a reasonably in-depth testing cycle, and now they are finally deployed in your WebSphere production environment. Great! So now I wonder... what about your WebSphere business processes? Do you understand your applications' topology, know which components participate on which flows, and in which system they "live"?

And what about the end-to-end picture? Do you know where your routers are, which WebSphere Application Server is connected to which Web server or to which WebSphere MQ system? And what about your connectivity with your back-end systems? Do you know which JavaBean is accessing which table, and where all the messaging systems are physically located? If your answer is no, this article will show you how you can better understand and manage your WebSphere applications.

From WebSphere Application Server to the WebSphere Platform
Before I discuss different approaches to managing the WebSphere platform, let's begin by defining what I mean by this term. WebSphere Application Servers (WASs) - and application servers in general - which for the most part once simply stored and served up content, are now part of bigger platforms, known as "application server platforms," that offer application hosting, integration, portal, data management, security, and other functions. In fact, IBM's WebSphere product line today contains more than 350 products. You can see a graphical representation of the main components of the IBM WebSphere 5.0 platform in Figure 1.

 

When you look at it, it seems complex. Maybe you are even thinking, "Hmmm, in my organization we are not using all of these." Don't be too sure. You might be right in the sense that you might not be using CICS, for example, but I am certain that you at least have Web servers at the front end (WebSphere relies on available Web servers to present content to the end user); databases, constantly collecting and supplying critical information; messaging systems; and network elements like routers or firewalls deployed across your organization. You might even have WebSphere MQ or legacy applications running in your environment as well.

A problem with any of these elements will impact your system's ability to present content to the end users accessing your WebSphere applications. So let's take a look at the WebSphere platform from a different angle, an enterprise implementation perspective, like the one portrayed in Figure 2.

 

As you can see in Figure 2, WebSphere applications expand beyond the WebSphere application server, and are deployed across extended underlying infrastructures on both distributed and mainframe environments. This means that even though your main focus is WebSphere, you shouldn't forget that Web transactions traverse a path of complex, interdependent entities, any of which are potential bottlenecks or failure points. Not only is every element of the chain responsible for presenting content to the end user, but problems can happen in the source code of a particular JavaBean, in a specific method's call to a back-end database, or in a router.

As infrastructures become more and more complex, applications too are becoming more and more complex. When you think about a typical J2EE production application you are going to see a few hundred components - JSPs, servlets, EJBs, methods, etc. - layered, interconnected, and highly distributed across different systems. In addition, business processes within the context of WebSphere are particularly dynamic in nature, as application cycles have shortened considerably, and applications are moved into production faster than ever before. At the same time, there are multiple departments involved in the process of building, deploying, and maintaining applications: Operations, WAS Administrators, DBAs, system administrators, Development, QA, network team, etc. So, how do you manage all of these?

Traditionally, application management was characterized by a horizontal approach, in the sense that a domain management group was responsible for individually maintaining each silo, e.g., DBAs were responsible for maintaining databases; WAS administrators were monitoring WAS systems; network administrators were overseeing routers and firewalls, etc. These domains were pulled together into frameworks and platforms, but the level of integration was minimal, i.e., leveraging a single console without meaningful integration of information and services.

This approach is no longer feasible, as it will not allow you to quickly locate and identify where a problem is really happening, and which team needs to address it. Let me give you an example. Let's assume that you are independently monitoring your DB2 systems, and you are suddenly alerted to problems with specific tables escalating locks and timeouts. Most of the updated SQL statements, if not all, are entity bean-driven, and the beans create their own SQL statements. Because you don't have a correlated WAS/DB2 management in place, you really don't know which specific application components are executing those SQL calls. What is the consequence? As you can only speculate which applications are causing the problem, you can only help by partitioning tables that are not partitioned, a temporary fix. Because the root cause of the problem hasn't really been found, it is very likely the problem will occur again.

Therefore, effective management of WAS environments requires the latitude for in-depth monitoring both across each silo and end to end, and with the capacity to correlate performance from the end-user experience down to the individual database, WAS, network element, or Java component that is really causing a performance bottleneck or degradation.

Divide-and-Conquer Technique
Although WAS comes with it's own embedded management tools, when defining your strategy for managing your applications built on top of WebSphere you should think about end-to-end management. This means managing from a single location all the different elements that form the WebSphere platform, monitoring application components and their dependencies on the underlying infrastructure, and being able to correlate performance metrics end to end to rapidly find the true root cause of problems or performance degradations in real time. I like to refer to this end-to-end management strategy as a "divide and conquer" approach, in the sense that you start by considering your application architecture in terms of individual

  • Elements of the infrastructure
  • Application components
  • Topological relations, of both application component to application component, and application component to underlying infrastructure

    Once you have management tools in place to discover and monitor the performance of individual infrastructure elements and application components - tools that allow you to visualize from a central location topological relationships as well - you can start building up your management and go to the next level, which is monitoring interactions among components and end-to-end SLAs (servicelevel agreements).

    Managing Infrastructure and Application Components
    Let's back up at this point, and take a look at the first step of this approach in more detail. You need individual management solutions to manage each piece of the infrastructure, e.g., WAS, WebSphere MQ, Web servers, databases, CICS, messaging systems, network elements, etc., - and to map different management solutions to all the elements of the WebSphere platform. At the same time, these individual management solutions, or agents, should have integration points among each other at different layers to be able to correlate performance metrics end to end. Some of the integration points that you should look for in your management tools are:

  • Global discovery: Ability to discover the end-to-end WebSphere infrastructure and application components from a central location
  • Central visualization: Helps you visualize problems, drill down to the affected area, and route issues to the department that needs to fix them.
  • Single point of notification/alerting/root-cause analysis: Allows intelligent filtering out of events
  • Customizable integrated reporting: Ability to group information in terms of individual elements, topological relationships, or business processes for both historical and real-time reports

    Now that you have your agents in place, the next step should be automatically discovering your application components, where they have been deployed, and their dependencies down to the business logic layer. For example, a particular EJB method in my Checkout EJB is executing a SQL query on my DB2 system A. Once you have the topological information of your enterprise application in place, you should start by looking at the performance metrics of the different systems, as well as the performance of each individual application component. You should look for a management tool that is proactive in the sense that it is based on configurable thresholds so that when these thresholds have been reached, alerts will be sent out to the central console, and automatic corrective actions can be taken to fix the problem without IT intervention.

    Managing Applications in the Context of Flows
    Now that you can oversee the availability, health, and performance of individual systems and each application component from a topological perspective, the next step should be managing interactions among application components in the context of flows. There are two ways to look at interactions, from a Web transaction perspective and from a WebSphere business process approach. Let's begin by focusing first on Web transactions.

    Because of the complexity of the WebSphere platform, managing Web transactions as they flow across your extended environment is critical to ensure a positive enduser experience. Each time an end user accesses a Web application, multiple transactions take place: from the Web browser to the Web server, from the Web server to a WAS system, from a WAS system to the database, and so on. Web transactions themselves are complex and heterogeneous operations, as personalization and different interests will usually lead end users to traverse different paths on the same application.

    Vendors have been addressing transaction management from two different perspectives: real-time versus synthetic monitoring. The reasoning behind these two approaches is that real-time monitoring can help you quickly detect and pinpoint application problems to an offending JavaBean method, servlet, or database connection in real time as soon as they happen, while synthetic monitoring proactively exercises applications to help prevent application crashes or wrong return data before real end users encounter those situations.

    An ideal management solution should deliver both approaches. In fact, you should start by identifying your real business objectives or scenarios - e.g., my goal is to get users to register for a seminar, or to sell item A - to identify which Web transactions are critical in your environment. Each one of these critical business scenarios or transactions should be managed synthetically and in real time as an object. Also, if any of the application components is executing SQL queries, you should look for a management tool that captures those in real time as well, presenting performance information for both the component that executed the SQL query as well as the SQL query statement, to help you determine if a problem is on the application server side or on the database side.

    Related to managing WebSphere business processes, a management tool can allow you to work with abstrac- tions of the real processes within the WebSphere Application Server platform, and monitor as a unit all the elements across the end-to-end environment that are critical to your key business processes, including specific application components, infrastructure elements, Java Virtual Machines (JVMs), WebSphere MQ systems, Web servers, database tables, and routers. Because of the dynamic nature of WebSphere environments, a management tool should handle these abstractions as dynamic entities, and quickly update and reflect changes in application components, application dependencies, or underlying infrastructures. In addition, a management tool should offer rule-definition capacities so you can associate rules to govern each of your WebSphere business processes or abstractions. Hence, these rules will help you determine, in the event of an infrastructure element malfunctioning, which business processes are going to be impacted, so errors can be prioritized and addressed accordingly.

    Managing End-to-End SLAS
    The effectiveness of an application can be measured accurately only from the service consumer's viewpoint. Now that you are overseeing infrastructure, application components, transactions, and business processes, the next step is managing end-to-end service-level agreements to ensure a positive end-user experience across the enterprise. A management tool should allow you to build a higher view out of the underlying complexity of routers, switches, application components, JVMs, response times, and the like, correlating data from different sources across the enterprise, calculating availability percentages, and sending potential breaches of end-to-end SLAs to the central notification console. Specifically, it would be very useful if you could use the WebSphere business processes or abstraction units I discussed in the previous section as a data point for your SLA management tools, so you can measure effectiveness from an application-centric perspective as well. Another useful feature is the ability to customize and present SLM reports on a business's process, geography, organization, customer service goals, and business-hours basis, allowing IT to refocus on services that contribute the most to corporate profitability. It will also enhance other business goals such as market share or shareholder value.

    Within Computer Associates' Unicenter portfolio, we map different Unicenter solutions to the different elements of the WebSphere platform so we can monitor the underlying extended WebSphere infrastructure, as well as the health, availability, and performance of individual application components and their interactions with each other in the form of Web transactions.

    All of our Unicenter solutions use CA Common Services (CCS) - a common set of APIs that leverage Web services- enabled technologies - to facilitate integration and communication among them, and correlate performance metrics across silos, and vertically across business processes. CCS provides multiple points of integration at different layers from which you can manage your end-to-end infrastructure, while also providing a central point of notification with advanced root-cause analysis capabilities.

    Conclusion
    Whatever management tool you choose, the goal is to maintain your critical Web applications and exceed user service levels by proactively managing the performance of your WebSphere platform and its underlying J2EE technologies - including real-time transaction monitoring, and your customized business logic - to help you locate and resolve problems in today's extended WebSphere environments.

  • More Stories By Marina Gil-Santamaria

    Marina Gil-Santamaria is the Director of Product Marketing for Ipswitch’s Network Management Division. During the past thirteen years Marina has held various positions in development, professional services, product management and product marketing organizations at CA, Wily, Empirix, Oracle and Gomez. Marina is a frequent contributor to industry publications and forums. Marina holds an MS in electrical engineering from the Universidad Politecnica de Madrid, Spain.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.