System and method for providing service level management

A system and method for providing service level management in a web-based environment are provided. In one embodiment, the method includes intercepting a communication between a web-based environment and a client. The client is identified based, at least in part, on the communication. A web-based application is also identified based, at least in part, on the communication, with the web-based application associated with the web-based environment. The communication is processed using the identified web-based application. A real-time service level is determined for the identified client based, at least in part, on the processing of the communication by the web-based application.

TECHNICAL FIELD

This disclosure relates generally to the field of network processing and, more specifically, to providing service level management.

BACKGROUND

Microsoft's .NET application is software that includes the .NET Framework, which is typically used for developing and running certain network-based or web-enabled applications and web services. These applications often operate over a network through standard, platform-independent protocols including, for example, extensible Markup Language (XML), Simple Object Access Protocol (SOAP), and Hypertext Transfer Protocol (HTTP). The .NET Framework often includes, references, or invokes, one or more HTTP modules and/or HTTP handlers, which are operable to suitably process HTTP, TCP, or other requests. Once an HTTP (or other similar protocol) request is received, the request may be processed by multiple HTTP modules and processed by a single HTTP handler. HTTP modules allow developers or administrators to intercept, perform custom processing on, or modify particular requests. HTTP modules often implement the IHttpModule interface, which is located in the System.Web namespace. HTTP handlers are generally operable to process endpoint requests. For example, HTTP handlers enable the.NET Framework to process HTTP URLs within a web-enabled or .NET-compatible application. HTTP handlers normally implement the IHttpHandler interface, which is also located in the System.Web namespace.

SUMMARY

A system and method for providing service level management in a web-based environment are provided. In one embodiment, the method includes intercepting a communication between a web-based environment and a client. The client is identified based, at least in part, on the communication. A web-based application is also identified based, at least in part, on the communication, with the web-based application associated with the web-based environment. The communication is processed using the identified web-based application. A real-time service level is determined for the identified client based, at least in part, on the processing of the communication by the web-based application. The details of one or more embodiments of the disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the disclosure will be apparent from the description and drawings, and from the claims.

DETAILED DESCRIPTION

FIG. 1illustrates a system for service level reporting for applications and web services in a network framework (or other web-enabled environment) according to certain embodiments of the disclosure. At a high level, system100is a client/server environment comprising at least one client or management workstation104, a server or host102, and network108, but may also be a standard or local computing environment or any other suitable environment. For example, system100may include or host a network framework or web-based environment. In general, system100allows a customer to request a particular web-enabled application160or method, dynamically determines the customer from request140, and automatically provides various administration, billing, and reporting abilities based on this request140. More specifically, server102may provide a plurality of applications160for a particular fee, monitor the service level of various requests140for the provided applications160, and debit/credit a customer's account based on requests140and the determined service level. The term “automatically,” as used herein, generally means that the appropriate processing is substantially performed by at least part of system100. It should be understood that “automatically” further contemplates any suitable user or administrator interaction with system100without departing from the scope of this disclosure. The term “dynamically,” as used herein, generally means that certain processing is determined, at least in part, at run-time based on one or more variables.

Server102includes memory120and processor125and comprises an electronic computing device operable to receive, transmit, process and store data associated with system100. Server102may comprise a general-purpose personal computer (PC), a Macintosh, a workstation, a Unix-based computer, a server, or any other suitable device. For example, server102may be a blade server or a web server. In short, server102may comprise software and/or hardware in any combination suitable process requests140and provide service level reports150based on these requests140.FIG. 1only provides one example of computers that may be used with the disclosure. For example, althoughFIG. 1provides one example of server102that may be used with the disclosure, system100can be implemented using computers other than servers, as well as a server pool. The present disclosure contemplates computers other than general purpose computers as well as computers without conventional operating systems. In other words, as used in this document, the term “computer” is intended to encompass any suitable processing device. Computer server102may be adapted to execute any operating system110including Windows NT, Windows 2000, Windows Server, Windows Storage Server, Windows XP home or professional, Unix, Linux, or any other suitable operating system including, referencing or linking to an extensible instrumentation layer130and an event tracer132. In one embodiment, operating system110includes a network framework, such as Microsoft's .NET framework.

Extensible instrumentation layer130exposes namespaces, classes, methods, and properties for hardware devices, operating system110, and various applications160. For example, extensible instrumentation layer130may be Windows Management Instrumentation (WMI). Event tracer132is any module operable to provide a high-performance, commonly available ability to issue and format tracing events. Event tracer132may be controlled by tracelog functions including StartTrace( ), EndTrace( ), and UpdateTrace( ), as well as others. For example, event tracer132may log or write and suitable information or data associated with service levels, such as the time of the event, a process ID under which the event occurs, thread ID under which the event occurs, a user-mode CPU time, and/or kernel-mode CPU time.

Memory120may include any hard drive, memory, or database module and may take the form of volatile or non-volatile memory including, without limitation, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media, or any other suitable local or remote memory component. In this embodiment, illustrated memory120includes database124, at least one web-enabled application160, and one or more customer accounts170, but may also include any other appropriate data. For example, memory may include fee tables and service level threshold tables. Database124stores one or more database tables, with each table including one or more columns. Database124may receive records, schemas, or any other suitable data through interface112or from another process running on server102. In one embodiment, database124may be a relational database management system (or DBMS). Relational databases often use sets of schemas to describe the tables, columns, and relationships between the tables using basic principles known in the field of database design. But while described as a relational database, database124may be any data repository of any suitable format including XML documents, flat files, Btrieve files, comma-separated-value (CSV) files, an object oriented database, name-value pairs, and others.

Applications160include any standard or custom .NET-compatible or web-enabled software (including ASP.NET applications, remoting applications, and particular web services) associated with a web-based environment, such as Microsoft's .NET framework. Each application160may be written or developed in any appropriate language such as C, C++, C#, Java, J#, and VB.NET. Typically, server102offers applications160for use by clients104based on predetermined account information. Memory120also stores one or more customer accounts170. Customer account170generally includes or references associated applications160, account balances, and service level parameters or thresholds. Each customer account170may be an XML document, a table or record in database124, a binary file, a text file, a CSV file, an object, an array, or any logical or physical component operable to store information associated with a customer requesting application160. Indeed, as illustrated inFIG. 3, customer account170may include a plurality of tables (or files), with each table associated with a portion of the account. For example, customer account170may include a first table associated with account management and a second table associated with a customer's service level parameters. Further, it will be understood that customer account170may be local or remote, as well as temporary or persistent, without departing from the scope of the disclosure.

Server102also includes processor125. Processor125executes instructions and manipulates data to perform the operations of server102such as, for example, a central processing unit (CPU), an application specific integrated circuit (ASIC) or a field-programmable gate array (FPGA). AlthoughFIG. 1illustrates a single processor125in server102, multiple processors125may be used according to particular needs, and reference to processor125is meant to include multiple processors125where applicable. In the embodiment illustrated, processor125executes management engine115that processes requests and reporting on service levels in system100. Management engine115could include any hardware, software, firmware, or combination thereof operable to receive or intercept communications between server102and client109. For example, management engine115may provide client104with supervisory or account management views (such as account balance, selected assemblies and methods, service levels, and others. It will be understood that while management engine115is illustrated as a single multi-tasked module, the features and functionality performed by this engine may be performed by multiple local or distributed modules such as, for example, an HTTP module, an account management module, a correlator, and a user interface module. Moreover, while not illustrated, management engine115may be a child or sub-module of any other appropriate software module, such as an enterprise infrastructure management application, without departing from the scope of this disclosure.

Server102also often includes interface112for communicating with other computer systems, such as client104, over network108in a client-server or other distributed environment via link118. Network108facilitates wireless or wireline communication between computer server102and any other computer. Network108may communicate, for example, Internet Protocol (IP) packets, Frame Relay frames, Asynchronous Transfer Mode (ATM) cells, voice, video, data, and other suitable information between network addresses. Network108may include one or more local area networks (LANs), radio access networks (RANs), metropolitan area networks (MANs), wide area networks (WANs), all or a portion of the global computer network known as the Internet, and/or any other communication system or systems at one or more locations. Generally, interface112comprises logic encoded in software and/or hardware in a suitable combination and operable to communicate with network108. More specifically, interface112may comprise software supporting one or more communications protocols associated with communications network108or hardware operable to communicate physical signals.

Client104comprises any computer and may include input devices, output devices, mass storage media, processors, memory, interfaces, communication ports, or other appropriate components for receiving commands from and present at to the user of client104. It will be understood that there may be any number of clients104coupled to server102or client104may comprise a management component of server102. Moreover, “client104,” “user of client104,” and “customer” may be used interchangeably as appropriate without departing from the scope of this disclosure. Moreover, a customer may be am organization, business, or enterprise with a number of clients104and users. As used in this document, client104is generally intended to encompass a personal computer, workstation, network computer, kiosk, wireless data port, personal data assistant (PDA), one or more processors within these or other devices, or any other suitable processing or display device or software. For example, client104may comprise a computer that includes an input device, such as a keypad, touch screen, mouse, or other device that can accept information, and an output device that conveys information associated with the operation of server102or clients104, including digital data, visual information, or reports150. Both the input device and output device may include fixed or removable storage media such as a magnetic computer disk, CD-ROM, or other suitable media to both receive input from and provide output to users of clients104through a portion of the output device, namely graphical user interface (GUI)116.

GUI116comprises a graphical user interface operable to allow the user of client104to interface with system100and view the reports of service level performance of a plurality of software products and application160. Generally, GUI116provides the user of client104with an efficient and user-friendly presentation of data provided by system100, such as a display or report150based on applications160. GUI116may comprise a plurality of displays having interactive fields, pull-down lists, and buttons operated by the user. In one example, GUI116presents formatted output to and receives commands from client104. It should be understood that the term graphical user interface may be used in the singular or in the plural to describe one or more graphical user interfaces and each of the displays of a particular graphical user interface. Further, GUI116contemplates any graphical user interface, such as a generic web browser, that processes information in system100and efficiently presents the information to the user. Server102can accept data from client104via the web browser (e.g., Microsoft Internet Explorer or Netscape Navigator) and return the appropriate HTML or eXtensible Markup Language (XML) responses. For example, GUI116may comprise a front-end of management engine115, with the front-end operable to view account balances historical service levels. Accordingly, for ease of understanding, the term GUI116and management engine115may be used interchangeably; although, it will be understood that management engine115will often include more functionality than a graphical user interface.

In one aspect of operation, management engine115receives or otherwise intercepts a request140between client104and server102. For example, request140may comprise a URL, an HTTP POST, or any other suitable communication. Once retrieved, management engine115identifies the customer (or client104) that communicated the intercepted request140. In one embodiment, management engine115is operable to identify client104through a form, a window, a passport, private cookie authentication, or other appropriate technique. For example, management engine115may identify an IP address from request140and compare the IP address to an IP mask to identify an address of the client machine. In another example, management engine115may implement a “set cookie” command prior to intercepting a request and then determining a password for the customer from the cookie installed on client104. In yet another example, management engine115may identify the client from HTTP POST data.

Once a client has been suitably identified, management engine115accesses customer account170using the client or customer identification. Management engine115then identifies the customer's account balance, service level parameters and thresholds, associated applications160, and any other suitable information. According to one embodiment, management engine115may automatically communicate an alert to system administrators if the customer's account balance is insufficient for to satisfy request140. Further, management engine115may deny request140if the customer has insufficient funds. Once this request140has been authenticated and the account information gathered, management engine115manages or monitors the execution of request140to determine at least one real-time service level for the process. Next, management engine115compares the real-time service level to the service level thresholds stored in customer account170. Management engine115may then assign a monetary value to request140based on predetermined fees, determine a chargeback value if the real-time service level fails to meet the service level thresholds, and debit or credit the customer's account balance in customer account170based on these values. At any suitable time, management engine115may also generate reports, graphs, or other presentations of the service level data and communicate these outputs150to client104.

FIG. 2is data flow diagram including an example embodiment of management engine115generally illustrated inFIG. 1. At a high level,FIG. 2illustrates the flow of information between management engine115, database124, example WMI130, and event tracer132. In this embodiment, management engine115includes profiler202, correlator204, HTTP plug-in206, compiled instrumentation208, poll thread210, and pull thread212. While illustrated as internal to management engine115, it will be understood that each of these components may individually or collectively be a callable remote function, a service, a dynamic-linked library (DLL), a daemon, a Component Object Model (COM) function, or any other local or remote function, method, object, or sub-module. Moreover, the functionality of these various components may be executed by one component without departing from the scope of the disclosure.

Profiler202generally implements profiler techniques and algorithms such as callbacks and providing a user with in-depth instrumentation involving web-enabled application160. For example, profiler202may be a COM server that implements callbacks such as “class load started,” “class load finished,” “function entered,” “function leave,” and many others. In certain embodiments, these callbacks are instrumented using event tracer132. Profiler202may include a profile mask operable to identify or determine active profiler functions. Profiler202may include a thread that listens for a “profiler notification” message operable to instruct profiler202to reload a configuration file and reset the mask based on this reload. Moreover, profiler202may be registered or coded as a provider, or a source of information associated with an event, with event tracer132. Correlator204is an example component operable to i) collect, gather, or combine one or more event tracing logs170; ii) correlate start and end events included in event tracing logs170; iii) certain chargeback functions; and iv) generate database-compliant data structures based on event tracing logs170. Correlator204may be further operable to identify and process individual records or entries in event tracing log170to perform function name processing and/or to efficiently correlate the start/end events. As described above, correlator204may be implemented as a plurality of plug-ins or DLLs without departing from the scope of this disclosure.

HTTP module206(or plug-in) is operable to monitor, track, or otherwise process ASP.NET and web services. HTTP module is further operable to intercept requests140, responses, or other communications between client104and server102(or an associated web-based environment). For example, HTTP module206may implement an iHTTPModule interface and present “OnBeginRequest” and “OnEndRequest” functions and may be enabled by an <httpModules> tag. In another example, HTTP module206may intercept incoming and outgoing communications to identify customers and clients104, determine real-time service levels, and others. In one embodiment, HTTP module206may be further operable to monitor or process Transmission Control Protocol (TCP) or other protocol requests. Compiled instrumentation208is any component operable to easily instrument or manage internal applications or new .NET applications160. Poll thread210is any plug-in or sub-module operable to poll WMI130for certain metrics such as, for example, number of compilations, number of sessions, number of applications, and many others. Typically, these metrics are converted to database-compliant data structures and inserted in to database124. Pull thread212is any plug-in or sub-module operable to locate, identify, or otherwise retrieve or process event tracing logs.

FIG. 3illustrates an example entity-relationship (E/R) diagram300of one embodiment of data structures used for providing service level management and reporting in a web-based environment. Illustrated ER diagram300includes five example tables: applications table302, path table304, request table306, customer table308, and fee table310. It will be understood that these tables are for illustration purposes only and any number of tables, including any number of fields and in any particular format, may be used without departing from the scope of this disclosure. Further, it will be understood that the data illustrated in diagram300may be partially or entirely included or stored in customer account170. Returning to the illustrated embodiment, applications table302includes a list of a plurality of available applications160. For example, applications table302may include one entry for an ASP.NET application and a second entry for a web service. Applications table302may also include data such as current sessions, error counts, and associated service level parameters and thresholds. Table302may be automatically populated on system startup and accessible to one or more customers. Example path table304includes any system path, location, or other appropriate command for locating or executing application160. Path table304may also include response time and unsuccessful request thresholds. Request table306may store management information including request ID (which may be generated by server102), a success code, response time for filling a particular request140, and links or references to path table304and customer table308. Customer table308may include a customer ID or client ID, an account balance, an email or other contact information, and billing information. Each record may be generated or populated during an account setup session by customer interested in accessing applications. Fee table310may include a plurality of records, with each record associating a customer, an application160or method, and the costs for the customer to execute that method. For example, illustrated fee table310includes a customer ID, a path, method identifier, cost, a minimum response time threshold, and a minimum failing requests threshold. In one embodiment, fee table310may be input by an administrator or salesman after negotiations with the customer. Of course, the various thresholds included in the tables illustrated (including session failures, option failures, response time, unsuccessful requests, and others) may be stored in one threshold table without departing from the scope of this disclosure.

FIG. 4illustrates an example view presented by one of the graphical user interfaces used by the system ofFIG. 1. It will be understood that this view is for illustration purposes only. System100may utilize or present any graphical display or element in any format, with any suitable data, without departing from the scope of this disclosure. Illustrated view116provides client104with a subscription maintenance screen. This subscription maintenance screen may contain a child page of an overall login screen or account maintenance screen. Example view116includes customer name or ID, a list or matrix of associated applications160, drop down lists for assemblies or methods, a customer chargeback type or other billing method, the customer's account balance, and an expiration date (if any). As illustrated, the cost matrix includes one assembly (factorywebservice) and three methods: GetOverheadRate, GetlaborRate, and GetInventory. Each of the example methods costs the example customer (ACME) 50 cents per request140. This can be determined using the costing method “by method call.” Each request140may then subtract 50 cents from the customer's current example balance of $2,000.00. Further, while not illustrated, a real-time service level for executing one of these methods may result in a chargeback to the customer's account balance and reported to the customer using view116.

FIGS. 5Aand B illustrate example methods for providing service level establishment, management, and reporting in a web-based environment according to certain embodiments of the disclosure.FIG. 5Aillustrates method500, which generally described establishment and management of a customer account170and service level thresholds associated with web-enabled applications160. Method500begins at step502, where server102receives customer subscription information. This customer subscription information may be received using any suitable technique including HTML posts, forms, and others. Once received, management engine115uses the customer subscription information to generate one or more customer account records170at step504.

This account generation may include any appropriate processing such as initialization of account balances, population of default values (fees, chargeback type, applications160, etc.), and such. At any subsequent time, server102may receive a customer login request to an account maintenance subsystem or web page at decisional step506. If received, then at step508management engine115may authenticate the customer login using the login request and information from customer account170. Next, at decisional step510, management engine115determines if a chargeback type is received from the customer to replace a possible default. For example, as described above, the chargeback type may comprise any billing category including “by method,” “monthly,” “weekly,” and others. If a new chargeback type is received, the management engine115updates customer account170with the received chargeback type at step512. Next, or if there is no chargeback type received, management engine115retrieves account balance information from any suitable provider at step514. For example, management engine115may retrieve or receive account balance information using a passport system. In another example, management engine115may include the account balance information in a subsystem or component stored in server102. Next, management engine115retrieves service level parameters and thresholds for the customer. As described above, the service level parameters may be stored in customer account170or in other local or remote tables. Management engine115then retrieves a list of web-enabled applications160associated with the customer at step518. This list of desired web-enabled applications160may have been selected by the customer during account generation. This list may also be dynamically generated based upon customer input. Once the information has been retrieved, management engine115generates at least one account maintenance web page or frame at step520for presentation to the customer through client104.

FIGS. 5B-Cillustrate method550, which generally describes server102providing web-enabled applications160for use by customers and management engine115reporting, managing, and billing based on determined service levels for this provision. Method550begins at step552, when server102receives an HTTP request140for web-enabled application160from client104. While described as HTTP, it will be understood that request140may be TCP or any other appropriate format or protocol without departing from the scope of this disclosure. Next, in example steps554through570, management engine115attempts to identify the customer based on the received request140. For example, at decisional step554, management engine115determines if request140includes an IP address. If it does, management engine115compares the IP address to an IP mask at step556. Based on this comparison, management engine115identifies the customer using client104. If a request does not include an IP address, then management engine115determines if server102has implemented the “set cookie” function. If it has, then management engine115retrieves a cookie from client104and extracts a password or other identifier from the retrieved cookie at step564. Based on this extracted password, management engine115identifies the customer using client machine104. If the “set cookie” function was not implemented or a cookie was not retrieved, then management engine115determines if request140includes the password at decisional step568. If it does not, then management engine115determines that it is currently unable to identify the customer using the disclosed techniques. Of course, while not illustrated, management engine115may use other techniques for identifying the customer including extracting a customer ID or password from the form, window, and others. If request140does include the password, then management engine115identifies the customer based on the HTTP POST data at step570.

Once the customer has been identified and/or authenticated using any appropriate technique, management engine115retrieves information from the appropriate customer account170at step572. Next, management engine115identifies the chargeback type for the customer using customer account170. Management engine115then determines if request140is associated with the chargeback type at decisional step576. For example, the requesting customer may be associated with a chargeback type of “per method.” Based on this, management engine115is able to determine that request140includes the method and that the customer should be billed for this request140. If request140is associated with the predetermined chargeback type, then management engine115determines the monetary value or other debit amount based on request140and the account information at step578. If the request is not associated with the chargeback type (for example, if the chargeback type is “per month”) or once the debit amount has been determined, then server102executes request140for web-enabled application160at step580. It will be understood that the debit amount may be initialized to zero resulting in a zero dollar debit amount for request140if it is not associated with the chargeback type. Management engine115then determines a real-time service level for the execution of requested application160at step582. This real-time service level determination may include monitoring execution of requests140to identify any criteria including response time, error counts, and others. Next, at step584, management engine114compares the determined real-time service level with the customer's service level parameters and thresholds. If the real-time service level fails to meet the customer's service level threshold at decisional step586, then management engine115automatically communicates an alert to a system or network administrator at step588. Next, management engine115may determine a credit amount based on the real-time service level and then subtracts the determined credit amounts from the currently used debit amount at step592. Next, at step594, management engine115applies the determined debit amount to the customer's account170.

Although this disclosure has been described in terms of certain embodiments and generally associated methods, alterations and permutations of these embodiments and methods will be apparent to those skilled in the art. For example, management engine115and/or HTTP module206may be operable to process TCP requests, XML requests, or any communication according to any other suitable protocol such that the customer's service level may be determined. Accordingly, the above description of example embodiments does not define or constrain this disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of this disclosure.