as) United States
`a2) Patent Application Publication co) Pub. No.: US 2008/0072178 Al
`
`(43) Pub. Date: Mar.20, 2008
`Budzisch et al.
`
`US 20080072178A1
`
`(54) GRAPHICAL USER INTERFACE (GUD FOR
`DISPLAYING SOFTWARE COMPONENT
`AVAILABILITY AS DETERMINED BY A
`MESSAGING INFRASTRUCTURE
`
`(76)
`
`Inventors:
`
`Janko Budzisch, Reilingen (DE);
`Pavel Kojevnikov, Rauenberg
`(DE); Stephen Pfeiffer,
`Schrieshem (DE)
`
`Correspondence Address:
`SAP/BLAKELY
`1279 OAKMEAD PARKWAY
`SUNNYVALE, CA 94085-4040
`
`(21) Appl. No.:
`
`10/749,769
`
`(22)
`
`Filed:
`
`Dec. 30, 2003
`
`Related U.S. Application Data
`
`(60) Provisional application No. 60/513,942, filed on Oct.
`24, 2003.
`
`Publication Classification
`
`(51)
`
`Int. Cl.
`(2006.01)
`GO6F 3/048
`(2006.01)
`GO6F 15/173
`(52) U.S. C0.
`ceceescsssssssssteseseesssssseessessen 715/853; 709/223
`
`(57)
`
`ABSTRACT
`
`An IS monitoring approach is described that is capable of
`monitoring the availability of various software components.
`A further capability is that the availability of the individual
`software components upon which a specific business logic
`process depends mayeach beindividually and continuously
`checked, in a combined fashion that is referenced to the
`specific business logic process, so that the status of the
`business logic processitself (e.g., operable or non-operable)
`can be continuously determined on an on-going basis. More-
`over, operability or non-operability can be established over
`a wide range of different business logic processes on a
`process by process basis.
`In various embodiments,
`the
`results of the monitoring may be continuously updated and
`displayed in a display so that an IS administrator can
`visually ascertain the status of the enterprise’s various
`business logic processes.
`
`
`
`ERROR Oe
`ALERT
`
`
`
`
`MONITOR
`Lins @)@)
`
`APPLICATION
`
`TREE
`203 APPLICATION
`
`
`
`215
`SERVER
`
`202 (h.GRMG APPLICATION
`
`
`GRMG REQUEST
`217
`MESSAGE 211
`
`
`
`CUSTOMIZING
`FILE
` SERVER
`
`213
`
`219
`GRMGAPPLICATION
`220
`
`
`NESSAGE4
`
`
`JSP
`SERVLETONGRMG APPLICATIO
`
`
`ENGINE
`205
`
` J2EE
`
`SERVER
`EJB
`208
`
`N
`
`Data Co Exhibit 1028
`Data Co v. Bright Data
`Data Cov. Bright Data
`
` Data Co Exhibit 1028
`
`
`
`
`JAVA
`GRMG
`WEB
`INFRASTRUCTURE
`
`
`
`SERVER
`209
`
`
`
`204
`
`
`
`
`
`GRMG
`
`MESSAGE
`
`

`

`Patent Application Publication Mar. 20, 2008 Sheet 1 of 11
`
`US 2008/0072178 Al
`
` APPLICATION
`
`103 APPLICATION
`SERVER
`
`102
` JAVA WEB
`
`SERVER
`104
`
`JSP
`SERVLET
`ENGINE
`105
`
`JNL
`
`DB
`106
`
`FIG. 1
`
`

`

`Patent Application Publication Mar. 20, 2008
`
`Sheet 2 of 11
`
`US 2008/0072178 Al
`
`
`
`DISPLAY
`
`ERROR
`ALERT
`
`
`216
`TREE
`
`MONITOR
`APPLICATION
`
`
`
`214
`TREE
` 203 APPLICATION
`
`
`215
`
`
`SERVER
`
`202 CY}.
`GRMG APPLICATION
`
`GRMG REQUEST
`217
`MESSAGE 211
`
`
`
`GRMGAPPLICATION
`220
`
` JAVA
`WEB
`
`SERVER
`
`
`204
`
`
`GRMG
`RESPONSE
`
`MESSAGE
`
`
`
`
`
`GRMG
`INFRASTRUCTURE
`
`209
`
`
`
`
`
`
`212
` JSP
`C>4.GRMG APPLICATION
`SERVLET
`
`210
`
`
`ENGINE
`
`205.
`
`
` J2EE
`SERVER
`
`EJB
`
`
`208,
`
`FIG. 2
`
`

`

`Patent Application Publication Mar. 20, 2008 Sheet 3 of 11
`
`US 2008/0072178 Al
`
`INFRASTRUCTURE
`SIDE
`
`APPLICATION
`SIDE
`
`
`
`
`302 RECEIVE REQUEST
`
`MESSAGE, PERFORM
`AVAILABILITY
`MONITORING, SEND
`RESPONSE MESSAGE
`
`
`
`
`RECEIVE RESPONSE
`
`MESSAGE,
`UPDATE DISPLAY|393
`
`
`FIG. 3
`
`

`

`Patent Application Publication Mar. 20, 2008 Sheet 4 of 11
`
`US 2008/0072178 Al
`
`CONTROL
`
`401
`
`401
`RUNLOGS-~— 2
`RUNERROR «—~_- 4013
`
`SCENARIO_1
`
`SCENARIO_2
`
`SCENARIO_3
`
`SCENARIO_N
`
`024
`
`4029
`
`023
`
`é
`
`402y
`
`SCENARIO.NAME4—— 403
`SCENARIO_VERSION 4—~— “4
`SCENARIO_INSTANCE 4—_- 405
`SCENARIO_TYPE 4—~_- 406
`START URL 4—~—-497
`STARTMOD #—~—408
`SCENARIO_DESCRIPTION 4—_- 409
`SCENARIO_LANGUAGE «—_- 410
`att;
`
`COMPONENT.1
`COMPONENT_2
`COMPONENT.3
`;
`
`COMPONENT_X
`
`419
`
`4119
`4113
`A11y
`
`$
`
`COMPONENT_NAME «123
`COMPONENT_VERSION 4—~—
`COMPONENT_DESCRIPTION <—~—-4"4
`COMPONENT_LANGUAGE 4«—_— 415
`PROPERTY_NAME 4—_- 416
`PROPERTY_TYPE «—~_-417
`PROPERTY_VALUE «—_-418
`
`FIG. 4
`
`

`

`Patent Application Publication Mar. 20, 2008 Sheet 5 of 11
`
`US 2008/0072178 Al
`
`FILE
`
`501 READ CUSTOMIZING
`
`GENERATE REQUEST
`MESSAGE
`
`902
`
`FIG. 5A
`
`SCENARIO_NAME 4~— 503
`SCENARIO_VERSION “~~ 504
`SCENARIO_INSTANCE 4~— 505
`
`COMPONENT_1
`
`COMPONENT_1
`
`COMPONENT_1
`
`COMPONENT_1
`
`5114
`
`5119
`
`5113
`
`51 1y
`
`
`
`
`
`
`
`COMPONENT_NAME 4~— 512
`COMPONENT_VERSION 4~— 513
`COMPONENT_NAME
`4~— 516
`COMPONENT_VALUE
`4-~— 518
`
`FIG. 5B
`
`

`

`Patent Application Publication Mar. 20, 2008 Sheet 6 of 11
`
`US 2008/0072178 Al
`
`
`
`RECEIVE
`REQUEST
`MESSAGE
`
`602
`
`
` MONITOR NEXT
`COMPONENTIN
`SCENARIO
`
`
`
`
`
`
`
`ALL
`COMPONENTS
`IN SCENARIO
`MONITORED?
`
`COMPILE MONITORING
`RESULTS INTO
`RESPONSE MESSAGE
`AND SEND RESPONSE
`MESSAGE
`
`FIG. 6A
`
`

`

`Patent Application Publication Mar. 20, 2008 Sheet 7 of 11
`
`US 2008/0072178 Al
`
` 610
`
`GET URL OF
`COMPONENT
`
`TRY TO
`CONNECT TO
`URL
`
`YES
`
`NO PAGE
`RETURNED?
`
`
`
`
`
`
`
`RESULT =
`OKAY
`
`
`
`
`RESULT =
`ERROR
`
`614
`
`FIG. 6B
`
`

`

`Patent Application Publication Mar. 20, 2008 Sheet 8 of 11
`
`US 2008/0072178 Al
`
`HTTPServiet_Request 800
`
`CREATE REQUEST
`OBJECT FROM THE
`SERVLET INPUT
`STREAM
`
`RESPONSE MESSAGE
`
`CREATE SCENARIO
`OBJECT FROM
`REQUEST OBJECT
`
`EXECUTE COMPONENT
`AVAILABILITY
`TEST(S)
`
`CREATE RESPONSE
`OBJECT
`
`PREPARE DOCUMENT
`AND SEND AS
`
`FIG. 6C
`
`

`

`Patent Application Publication Mar. 20, 2008 Sheet 9 of 11
`
`US 2008/0072178 Al
`
`SCENARIO_NAME “~~ 703
`SCENARIO_VERSION “~~ 704
`SCENARIO_INSTANCE 4—— 705
`
`
`
`
`
`
`
`COMPONENT_1
`
`COMPONENT_2
`
`COMPONENT_3
`3
`
`COMPONENT_X
`
`
`
`
`
`
`7144
`
`7119
`
`7113
`
`711y
`
`
`
`
`
`COMPONENT_NAME 4~— 712
`COMPONENT_VERSION4—~— 713
`COMPONENT_HOST 4~— 720
`COMPONENT_INSTANCE4—~— 721
`
`MESSAGES
`
`722
`
`ALERT “~~ 7224
`SEVERITY 4~— 7225
`AREA 4~— 7223
`NUMBER 4—— 722,
`PARAMETERS 4~_ 7225
`TEXT 4~_ 7226
`
`FIG. 7
`
`

`

`Patent Application Publication Mar. 20, 2008 Sheet 10 of 11
`
`US 2008/0072178 Al
`
`<SCENARIO_NAME> “~~ 801
`
`<COMPONENT_1> 4—~— 802 4
`
`
`
`
`
`
`
`<COMPONENT_3> “~~ 8023
`
`<COMPONENT_X> 4—— 802 y
`
`HOST/SERVER “~~ 803
`
`L INSTANCE 4—~— 804
`
`AVAILABILITY 4 805
`
`HEARTBEAT 4~— 806
`
`FIG. 8
`
`

`

`Patent Application Publication Mar. 20, 2008 Sheet 11 of 11
`
`US 2008/0072178 Al
`
`<APPLICATION NAME>_SELF MONITORING #~— 901
`
`SCENARIO ERROR “~— 902
`
`AVAILABILITY “~— 903
`
`HEARTBEAT 4~_ 904
`
`FIG. 9
`
`

`

`US 2008/0072178 Al
`
`Mar. 20, 2008
`
`GRAPHICAL USER INTERFACE (GUI FOR
`DISPLAYING SOFTWARE COMPONENT
`AVAILABILITY AS DETERMINED BY A
`MESSAGING INFRASTRUCTURE
`
`CLAIM OF PRIORITY
`
`[0001] The present application hereby claims the benefit
`of the filing date of a related Provisional Application filed on
`Oct. 24, 2003, and assigned Application Ser. No. 60/513,
`942.
`
`FIELD OF INVENTION
`
`Thefield of invention relates generally to Informa-
`[0002]
`tion Systems (IS); and, more specifically, to a graphical user
`interface (GUI) for displaying software component avail-
`ability as determined by a messaging infrastructure.
`
`BACKGROUND
`
`[0003] The information systems (IS) of an enterprise are
`often responsible for performing the enterprise’s database
`and business logic functions. Database functions involve the
`management or usage of the enterprise’s records (such as
`accounting records, sales records, billing records, employee
`records, etc.). Business logic functions are underlying pro-
`cesses of the enterprise that have been reduced to automated
`execution (e.g., automatically calculating revenues, auto-
`matically scheduling services, etc.). Often, a business logic
`function depends upon the use of a database function (e.g.,
`an automated billing system that invokes the customer order
`records of the enterprise). Moreover, database application
`software is often supplied with its own “business logic”
`software that enables business logic processes that invoke
`the core database function to be executed.
`
`In modern day enterprises, a complicated infra-
`[0004]
`structure of inter-networked computing systems and their
`corresponding software are typically orchestrated to per-
`form, as a cooperative whole, the database and business
`logic tasks of the enterprise. An exemplary arrangementis
`depicted in FIG. 1. FIG. 1 showsa network 101, which may
`be viewedas an enterprise’s internal intranet or the Internet
`(or some combination thereof),
`to which an application
`server platform 102-103 and a Java based platform 104-108
`are communicatively coupled. Through the immediately
`following discussion of each of these various functional
`elements 102-108 and some oftheir possible inter-relation-
`ships amongst each other, techniques employed by IS per-
`sonnel
`in building the IS infrastructure of an enterprise
`should be better appreciated.
`[0005] An application server 102 is often used to host a
`variety of applications (such as application 103). Business
`logic application software and/or database application soft-
`ware are frequent types of application software that are
`hosted by an application server 101. Here, “hosting” gen-
`erally means being responsible for interpreting and/or for-
`matting messages received/sent to network 101 so that the
`application 103 is properly used by the enterprise. For
`example, in a basic case where application 101 is a business
`logic application, the application server 102 responds to a
`request from the network 101 for application 103 (ie. a
`request from some entity that has expressed a need for
`application 103 through network 101) by properly invoking
`application 103 in response to the request; and, forwards the
`result(s) of the application’s execution to the requester.
`
`In other instances the application server 102 may
`[0006]
`perform additional business logic/database functionality “on
`top of” basic functionality provided by application 103 (e.g.,
`so as to precisely respond to the request that was received
`from the network 101). The additional business logic/data-
`base functionality may involve the invocation of other
`application software. In further instances the application
`server 102 may physically assist in the downloading of
`executable application software to a requester. Many appli-
`cation servers are responsible for overseeing a plurality of
`different application software platforms. Moreover, one or
`more computing systems may be used to perform the
`application server 102 function. These same one or more
`computing systems may also be used (depending on imple-
`mentation preference) to execute one or more of the hosted
`applications themselves.
`[0007] Functional elements 104-108 depict a web server
`104 andits corresponding Java based “back-end” function-
`ality 105-108. The term “web server” 104 is largely under-
`stood to mean being capable of presenting a web based
`interface (e.g.,
`through the downloading of web pages
`scripted in HTML format) over a network 101. Accesses to
`specific web pages associated with the web based presen-
`tation are typically formatted in the HTTPprotocol. Often,
`useful tasks that are dependent on business logic and/or
`database functions are made accessible through a web based
`presentation. FIG. 1 suggests such an approach by way of
`the back end servlet engine 105, database (DB) 106 and
`Enterprise Java Beans (EJB) 107 applications, and J2EE
`server 108.
`
`[0008] A servlet is a body of software typically geared to
`perform a specific database and/or business logic function
`(or at least oversee the execution of a specific database
`and/or business logic function). A servlet engine 105 is an
`entity capable of supporting the execution of a plurality of
`servlets and is the “target” for requests that
`invoke its
`constituent servlets. The architecture of FIG. 1 suggests that
`one or more of the various servlets supported by the servlet
`engine 105 depend upon separately packaged: 1) database
`software 106; 2) business logic software implemented with
`Enterprise Java Beans 107; and, 3) database and/or business
`logic software made accessible in a Java environment
`through a J2EE server 108.
`[0009] The servlet engine 105 can also be used to generate
`web page matter that is forwardedto a user over the network
`by the web server 104. “Java Server Pages” (JSPs) are web
`pages having extended embedded software routines (which
`are often used for displaying dynamic content on a web
`page). The notion that the servlet engine 105 is a JSP servlet
`engine indicates that the servlet engine 105 of FIG. 5 is
`capable of providing JSP type web pages.
`[0010] Enterprise Java Beans is a Java based application
`software development environmentthat produces software
`routines having a proficiency at being run in a distributed
`fashion(1.e., across multiple computing systems). Here, EJB
`107 and 108 would be understood to correspond to a
`collection of programs(e.g., business logic programs) writ-
`ten with EJB. J2FEis a Java software platform for building
`applications that can be executed in a distributed fashion.
`EJB is a component of J2EE along with Java Server Pages
`(JSPs) and a variety of interfaces.
`[0011]
`J2EE servers are servers retrofitted with J2EE
`software and are largely used as “middleware” servers that
`allow legacy, non Java applications to be made accessible
`
`

`

`US 2008/0072178 Al
`
`Mar. 20, 2008
`
`and useable in a Java based environment. For example, the
`J2EE server associated with EJB 108 may be communica-
`tively coupled to older non Java softwarethatis still used to
`execute specific database and/or business logic routines. In
`this case, the J2EE server would be responsible for putting
`a “Java face” to the legacy software from the perspective of
`the servlet engine 105 (e.g., by accepting Java commands
`and interpreting them into an format understandable to a
`legacy routine).
`[0012] Note that programs associated with EJB 107 and
`database (DB) 106 are configured to be accessible through
`a Java Native Interface (JNI) while programs associated
`with EJB 108 are configured to be accessible through one or
`more of the native interfaces associated with J2EE. JNI is a
`
`programming interface that may be used for function calls
`such asthe functions/programs implementedin database 106
`and EJB 107.
`
`[0013] The exemplary IS infrastructure of FIG. 1 also
`shows an HTTP server 118 communicatively coupled to a
`J2EE server 119. An HTTP server is a server that can
`
`respond to requests from a network authored in the HTTP
`protocol
`(which is the primary web page identification
`protocol—thus, HTTP server 118 can also be viewed as a
`web server). The HTTP server 119 is communicatively
`coupled to a J2EE server 119.
`[0014] Many business logic processes require a numberof
`different software components to be invoked in a specific
`sequence. For example, an automated billing process might
`first run a database application to check the customer order
`records of the enterprise and then run an automatedscripting
`application to create a custom tailored invoice for each
`order. Many business logic processes invoke a significant
`numberofdifferent software components over the course of
`their execution.
`
`[0015] An issue with enterprise information systemsis the
`ability to continuously monitor the specific software com-
`ponents that are used by a particular business logic process.
`Ifa particular software component becomes unavailable (for
`whatever reason) so as to render a business logic process
`unworkable, the existence of the “problem” may not be
`known until after the next attempt to use the process after the
`component became unavailable. This represents an effi-
`ciency loss in cases where the “problem” could have been
`fixed (or at least routed around) during the time period that
`elapsed from the moment the component became unavail-
`able to the next attempt to run the process.
`
`FIGURES
`
`invention is illustrated by way of
`[0016] The present
`example and not limitation in the figures of the accompa-
`nying drawings, in which like references indicate similar
`elements and in which:
`
`FIG. 1 shows components of an exemplary enter-
`[0017]
`prise information system;
`[0018]
`FIG. 2 shows an Information Systems (IS) moni-
`toring approach capable of monitoring the availability of
`different software applications;
`[0019]
`FIG. 3 shows a methodology that can be executed
`by the IS monitoring approach of FIG. 3;
`[0020]
`FIG. 4 shows an embodimentof a customizingfile
`such as customizing file 213 of FIG. 2;
`[0021]
`FIG. 5a shows a methodology that can be executed
`by the GRMGinfrastructure 209 of FIG. 2;
`
`FIG. 5shows an embodiment of a GRMGrequest
`[0022]
`message such as the GRMGrequest message 211 of FIG.2;
`[0023]
`FIG. 6a shows a methodologythat can be executed
`by the Generic Request and Message Generation (GRMG)
`application 210 of FIG.2;
`[0024]
`FIG. 66 shows a methodology for the monitoring
`of a componentin scenario as initially depicted in FIG. 4a;
`[0025]
`FIG. 6c shows an embodiment of an object onri-
`ented GRMGapplication flow;
`[0026]
`FIG. 7 shows an embodiment of a GRMGresponse
`message such as the GRMGresponse message 212 of FIG.
`2;
`FIG. 8 shows an embodimentof an alert monitor
`[0027]
`tree structure that indicates scenario component availability
`that may be displayed on a display such as display 216 of
`FIG.2;
`FIG. 9 shows9 is an embodiment of an errortree
`[0028]
`structure that indicates scenario availability that may be
`displayed on a display such as display 216 of FIG.2.
`
`SUMMARY
`
`[0029] An IS monitoring approach is described that is
`capable of monitoring the availability of various software
`components. A further capability is that the availability of
`the individual software components upon which a specific
`business logic process depends may each be individually
`and repeatedly checked,
`in a combined fashion that
`is
`referenced to the specific business logic process, so that the
`status of the business logic processitself (e.g., operable or
`non-operable) can be continuously determined on an on-
`going basis. Moreover, operability or non-operability can be
`established over a wide range of different business logic
`processes on a process by process basis.
`[0030]
`In this manner, an IS administrator can keep
`abreast of the status of the IS infrastructure from a perspec-
`tive that reflects an important purpose of the IS infrastruc-
`ture: to execute business logic processes that depend upon
`lower level software components. In various embodiments,
`the results of the monitoring may be continuously updated
`and displayed in a display so that an IS administrator can
`visually ascertain the status of the enterprise’s various
`business logic processes. The monitoring approach mayalso
`be capable of performing technical monitoring in which
`“foundational” operational features of the IS infrastructure
`(e.g., a JNI interface) are checked without reference to any
`particular business logic process.
`
`DETAILED DESCRIPTION
`
`[0031] An IS monitoring approach is described that is
`capable of monitoring the availability of various software
`components. A further capability is that the availability of
`the individual software components upon which a specific
`business logic process depends may each be individually
`and continuously checked,
`in a combined fashion that is
`referenced to the specific business logic process, so that the
`status of the business logic process itself (e.g., operable or
`non-operable) can be continuously determined on an on-
`going basis. Moreover, operability or non-operability can be
`established over a wide range of different business logic
`processes on a process by process basis.
`[0032]
`In this manner, an IS administrator can keep
`abreast of the status of the IS infrastructure from a perspec-
`tive that reflects an important purpose of the IS infrastruc-
`
`

`

`US 2008/0072178 Al
`
`Mar. 20, 2008
`
`ture: to execute business logic processes that depend upon
`lowerlevel software components. In various embodiments,
`the results of the monitoring may be continuously updated
`and displayed in a display so that an IS administrator can
`visually ascertain the status of the enterprise’s various
`business logic processes. The monitoring approach mayalso
`be capable of performing technical monitoring in which
`“foundational” operational features of the IS infrastructure
`(e.g., a JNI interface) are checked without reference to any
`particular business logic process.
`[0033] Overview
`[0034] The monitoring approach of FIG.2 is an exemplary
`depiction that applies software monitoring techniquesto the
`particular IS arrangement originally depicted in FIG. 1.
`According to the monitoring techniques depicted in FIG.2,
`a Generic Request Message Generation (GRMG)infrastruc-
`ture unit 209 is responsible for repeatedly sending a GRMG
`request message 211 (hereinafter, “request message’’) to a
`GRMGapplication 210. The request message 211 identifies
`the various software components of a higher level “sce-
`nario”. For example, in a typical implementation, the “sce-
`nario” might correspond to a business logic process that
`invokes a numberof lowerlevel software components(.e.,
`any one or more of: processes, programs, web pages); and,
`the request message 211 for the scenario identifies each of
`these components.
`[0035] The GRMGapplication 210 is a unit of software
`that is designed to receive the request message 211 and
`“check into” the availability of each of the software com-
`ponents that are identified by the request message 211. The
`results of the inquiries into the software components are
`collected and placed into a GRMGresponse message 212
`(hereinafter “response message’’). For example, a functional
`disposition (e.g., “OKAY” or “ERROR”) for each of the
`scenario’s software componentsis included in the response
`message 212.
`[0036]
`Ina typical situation the GRMGapplication 210 is
`installed at a location where a plurality of business logic
`processes are overseen, managed and/or executed. In the
`exemplary depiction of FIG. 2, note that GRMGapplication
`210 is installed with the servlet engine 205. As discussed in
`the background, a servlet engine 205 is an entity that is
`capable of supporting the execution ofa plurality of servlets.
`As servlets are often used to perform business logic pro-
`cesses (which may or may not involve the preparation of
`web pages), the platform used to implement servlet engine
`205 is also an appropriate location for a GRMGapplication
`210 that is configured to test the availability of the software
`componentsthat the servlets supported by servlet engine 205
`depend upon. For example, under the assumption that a
`numberofservlets (whose execution is supported by servlet
`engine 205) are designed to employ as sub-functions one or
`more database 206 and/or EJB 207, 208 software compo-
`nents, the GRMGapplication 210 can best determine the
`availability of these same software components from the
`perspective of the servlet engine 205 if the GRMGappli-
`cation 210 is situated with the servlet engine 205 itself.
`the
`[0037] After
`the GRMG application 210 forms
`response message 212, it is sent to the GRMGinfrastructure
`209. In the particular embodiment of FIG. 2, the response
`message 212 is sent by the servlet engine 205 to the web
`server 204; which, in turn, forwards the message into the
`network 201. The GRMGinfrastructure 209, in response to
`its reception of the response message 212, provides the
`
`availability test results that were expressed within the
`response message 212 to software that is responsible for
`generating images on a display 216. The results are then
`graphically depicted on the display 216 (e.g., in an “alert
`monitor tree” 215) so that an IS administrator can visually
`determine the status of the scenario (which, as discussed,
`may represent a business logic process).
`[0038] The display 216 may also graphically depict(e.g.,
`in an error tree 214) which scenario monitoring schemesare
`working and which scenario monitoring schemes are not
`working. Here, a scenario monitoring scheme should be
`understood to include the entire monitoring process includ-
`ing: 1) request message 211 generation by the GRMG
`infrastructure 209 and transportation over the network 201;
`2) request message processing and software availability
`testing by the GRMGapplication 210; 3) response message
`212 generation by the GRMGapplication 210 and transpor-
`tation over the network 201; and, 4) response message
`processing by the GRMGinfrastructure 209. Here, a sce-
`nario monitoring scheme may “fail” for reasons unrelated to
`the availability of its corresponding software components.
`For example, if network 201 is “down”a scenario’s request
`and response messages 211, 212 can not be exchanged even
`if the scenario’s corresponding software components do not
`have any availability problems with respect to the servlets
`that use them.
`
`[0039] Thus, having an alert monitor tree 215 (which
`indicates which scenarios do not have software component
`availability problems and which scenarios have software
`component availability problems) and an error tree 214
`(which indicates which scenario monitoring schemes are
`“working” and which scenario monitoring schemesare “not
`working”) allows an IS administrator to distinguish between
`problemsthat cause software component unavailability and
`other problems (that are perhaps more fundamental to the
`workings of the IS infrastructure and the overall scenario
`monitoring scheme such as those involving network con-
`nections)
`that cause a scenario monitoring scheme to
`execute improperly.
`[0040] The GRMGéinfrastructure 209 is a body of soft-
`ware that
`is responsible for the continuous sending of
`request messages on a scenario by scenario basis. As the
`above described example to which messages 211, 212 were
`applied was written in the context of a single scenario, note
`that multiple scenarios may exist that each invoke repeated
`request and response message exchanges. For example, the
`GRMGinfrastructure 209 might be configured to implement
`a unique scenario for each unique business logic process that
`the servlet engine 205 supports; and, orchestrate the sending
`and receiving of GRMG messages for each of these sce-
`narios.
`
`[0041] The GRMGinfrastructure 209 may also be con-
`figured to communicate with multiple GRMGapplications
`found in different
`locations across the enterprise. For
`example, another GRMGapplication 217 might be included
`in application server 202 (which is responsible for hosting
`application 203 among possible others); and, another
`GRMGapplication 220 might be included in HTTP server
`218 (which is responsible for providing web access for
`software components located on J2EE server 219). Here, the
`GRMGinfrastructure 209 might be configured to not only
`orchestrate the sending/receiving of GRMG messages for
`each of the business logic processes supported by servlet
`engine 205 but also orchestrate the sending/receiving of
`
`

`

`US 2008/0072178 Al
`
`Mar. 20, 2008
`
`GRMG messages for each of the business logic processes
`supported by application server 202 and HTTPserver 218.
`[0042] The message exchange approaches discussed fur-
`ther below inherently support a range of deploymentoptions
`with respect
`to “how many” GRMG applications are
`installed per scenario. At a first extreme, only one GRMG
`application exists at a location from which multiple sce-
`narios are tested for component availability. For example,
`only the single GRMGapplication 210 is called upon forall
`of the scenarios to be tested from servlet engine 205. As such
`request message 211, which is destined for GRMGappli-
`cation 210, could identify any of a plurality of different
`scenarios.
`
`[0043] Alternatively, different GRMG applications may be
`maintainedfor different scenarios at a same testing location.
`For example, at the other extreme, GRMGapplication 210
`may be implemented for only a particular scenario. Thus,
`request message 211, which is destined for GRMGappli-
`cation 210, would be capable of only identifying a single
`scenario. Continuing with such an extreme, for each sce-
`nario to be tested for component availability as a servlet
`from servlet engine 205, a separate GRMG application
`would be instantiated. Likewise, a different GRMGappli-
`cation may be maintained for each scenario testing scheme
`to be carried out from application server 202 and HTTP
`server 218.
`
`[0044] Embodiments between the extremes discussed
`above are also inherently supported. Irrespective of how
`many GRM applications exist per scenario, GRM applica-
`tion 210 may be implementedas a servlet (having its own
`unique URL) that
`is dedicated to execute the software
`componentavailability testing for its constituent scenario(s).
`Request message 211 would therefore identify the URL of
`GRMGapplication 210 so that it could be executed as a
`consequence.
`[0045] Also, as a monitoring option, “single” component
`scenarios are possible. Single component scenarios are use-
`ful for monitoring the availability of a software application
`as a whole. For example, the GRMGapplication 220 of
`HTTPserver 218 might be configured to monitor the avail-
`ability of an entire software application whichis installed on
`J2EE server 219. In this case, because the J2EE server 219
`contains the application to be monitored, the HTTP server
`218 is an appropriate location from which to determine the
`availability of the application (e.g., because, during normal
`usage,
`the HTTP server 218 is configured to “call” the
`application in response to a request that was received from
`the network 201); and, therefore, the HTTP server 218 is an
`appropriate location for GRMGapplication 220.
`[0046] As another side note, a complete GRMGapplica-
`tion may be configured into a software package aspart ofits
`standard set of available services; or, a GRMGapplication
`may be custom tailored by IS personnel so as to service a
`custom arrangement of software components. For example,
`the business logic processes associated with servlet engine
`205 may have been “custom crafted” by IS personnel
`because they are unique to the enterprise that the IS intra-
`structure of FIG. 2 serves. As a consequence, GRMG
`application 210 may likewise be created by IS personnel so
`as to properly monitor these custom processes.
`[0047] By contrast, if the applications supported by appli-
`cation server 202 are standard “off the shelf” applications
`that are supplied as part of a software vendor’s standard
`product offering, GRMG application 217 may likewise be
`
`part of the software vendor’s product (that is, since the
`applications are supplied by the vendor, the vendoris also
`capable of developing a GRMGapplication to monitor
`them). In a further embodiment, which a standard product
`offering GRMGapplication may employ, a GRMGappli-
`cation (e.g., GRMG application 217) is geared to call on
`specific “function modules” that perform specific monitor-
`ing functions. Here, a GRMG request message can be
`configured to call out (e.g., by name) a specific function
`module to be executed for its corresponding scenario. The
`GRMGrequest message may further identify the name of
`the identified function module being executed.
`[0048] The monitoring approach of FIG. 2 may also be
`further used to support
`technical monitoring. Technical
`monitoring is the monitoring of foundational components of
`the IS infrastructure that support the execution of the busi-
`ness logic processes themselves (e.g., such as a Java Net-
`work Interface (JNI) through which certain software com-
`ponents are supposed to be accessible). Here, a request
`message would be sent by the GRMGinfrastructure 209 that
`describes a scenario which identifies one or more founda-
`
`tional components that are to be tested for availability.
`[0049]
`FIG. 3 outlines a high level methodology that is
`executed by the monitoring system observed in FIG. 2.
`According to the methodology of FIG. 3, the GRM infra-
`structure 209 sends a request message 301 for a scenario to
`a GRMGapplication. Upon receipt of the request message
`the GRMGapplication 210 performsavailability monitoring
`for the scenario, which may include individual monitoring
`of its constituent
`lower level components, and sends a
`response message 302 back to the GRMG infrastructure
`209. The response message provides the availability moni-
`toring results.
`[0050] The GRMGinfrastructure, upon receipt of the
`response message, forwards the results so that they can be
`displayed 303. The process then repeats for the scenario. The
`periodicity of the repetition of the message exchange may be
`targeted for a set interval (e.g., in minutes). In an embodi-
`ment, the process observed in FIG.3 is multi-dimensional in
`the sense that one such process is executed for each scenario
`to be monitored. For example, if 1,000 different scenarios
`are to be monitored, 1,000 instances of the methodology are
`effectively executed that may involve a plurality of GRMG
`applications distributed across various locations within the
`enterprise’s IS infrastructure.
`
`GRMGInfrastructure & Request Message
`
`FIGS. 4, 5@ and 56 relate to GRMGinfrastructure
`[0051]
`and request message embodiments. Specifically, FIG. 4
`provides an embodimentof an organization schemethat may
`be used for a customizing file; FIG. 5a showsa process that
`maybe executed by the GRMGinfrastructure; and, FIG. 55
`shows an embodimentof an organization scheme that ma