Abstract:
The present invention discloses a document for formally defining service level requirements in a service oriented architecture (SOA). This document can include a service specification that defines functional attributes and a capability specification that defines performance requirements. These functional attributes and performance requirements can influence the response of the SOA to a service request. For example, a dynamic interpreter of the requirements document can dynamically adjust SOA resources to ensure performance requirements specified in the requirements document are met.

Description:
BACKGROUND 
       [0001]    1. Field of the Invention 
         [0002]    The present invention relates to the field of service oriented computing and, more particularly, to a technique for defining and dynamically enabling service level requirements in a service oriented architecture (SOA). 
         [0003]    2. Description of the Related Art 
         [0004]    As enterprise information systems expand in both geography and capability, many businesses have implemented a service oriented architecture (SOA) to provide a consistent and re-usable interface for connecting requesting clients with any business process or information provider. The increase in popularity of SOA has resulted in the creation of a large number of software and middleware components that can be used in implementation. While some SOA solutions require specific software and middleware components, others can support a variety of components and protocols. Further, additional software components exist that can be added to the SOA to provide supplementary functions for governance. 
         [0005]    The current implementation of SOA has created an environment that impedes the implementation of service level requirements. Service level requirements are the generic language terms that define the implementation and performance criteria for a specific service, such as provide a real-time update. A service processing environment is typically used to provide a programming interface for a specific middleware component. A disconnect arises between the language used to document service level requirements and the language used by the service processing environment to define like items. That is, a one-to-one correlation does not exist to translate the generic natural language terms of the service level requirement into the terms used by the service processing environment. Therefore, implementing service requirements in a SOA requires in-depth knowledge of the service implementation and infrastructure capabilities of the service processing environment. Even with this in-depth knowledge, an implementer often uses subjective interpretations of the natural language used to define the service level requirements. Code maintainers or SOA architects may re-interpret these loosely specified requirements in the future, which can result in a SOA service malfunctioning. 
         [0006]    Because such a detailed level of knowledge is required, enabling service level requirements within a SOA environment incurs a high level of cost. Typically, available SOA knowledgeable personnel are limited. Despite this limitation, SOA knowledgeable personnel are required to design and modify SOA applications and to design and modify SOA infrastructure components. SOA knowledgeable personnel are presently diverted to coordinate with management personnel on requirement modification issues and/or interpretations. Similarly, coordination with these same knowledgeable people is needed to determine an effect of deploying new SOA services and an effect of changing the SOA infrastructure upon existing SOA services and their associated requirements. 
         [0007]    What is needed is a means to enable service level requirements within a SOA that does not require in-depth knowledge of service implementation and infrastructure capabilities. Ideally, such a means would utilize a formalized language for defining service level requirements that can be translated into the language used by the service processing environment by an interpreter program at runtime. Therefore, service level requirements would be consistently defined, which also provides a single location for applying modifications, and dynamically applied to each received service request. 
       SUMMARY OF THE INVENTION 
       [0008]    The present invention details a vehicle for defining and dynamically enabling service level requirements in a service oriented architecture (SOA). Service level requirements can be represented in a specialized document called a service level profile (SLP). The SLP can utilize a formalized language within a standardized format that can provide a consistent expression of service level requirements. A SLP handler can utilize the structure and language of the SLP to dynamically adjust the operating conditions of the SOA as service requests are processed. 
         [0009]    The present invention can be implemented in accordance with numerous aspects consistent with the material presented herein. For example, one aspect of the present invention can include a document for formally defining service level requirements in a service oriented architecture (SOA). This document can include a service specification that defines functional attributes and a capability specification that defines performance requirements. These functional attributes and performance requirements can influence the response of the SOA to a service request. 
         [0010]    Another aspect of the present invention can include a method for implementing service level requirements in a service oriented architecture (SOA). In the method, a service request can be received within a SOA. The service request can include information that identifies the requestor. Using this identifying information, a corresponding service level profile (SLP) can be obtained. The SLP can be interpreted, which can influence the configuration of the responsive service and/or the providing system. After interpretation, the service can be invoked and conveyed to the requestor. 
         [0011]    Still another aspect of the present invention can include a handler for service level profiles (SLPs). The handler can include a service level pre-processor and a service level interpreter. The service level pre-processor can be configured to retrieve the SLP from a profile directory that matches a service request. The service level interpreter can be configured to translate the SLP into a set of performance requirements and can dynamically adjust parameters of the SOA to meet the set of performance requirements. 
         [0012]    It should be noted that various aspects of the invention can be implemented as a program for controlling computing equipment to implement the functions described herein, or a program for enabling computing equipment to perform processes corresponding to the steps disclosed herein. This program may be provided by storing the program in a magnetic disk, an optical disk, a semiconductor memory, or any other recording medium. The program can also be provided as a digitally encoded signal conveyed via a carrier wave. The described program can be a single program or can be implemented as multiple subprograms, each of which interact within a single computing device or interact in a distributed fashion across a network space. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0013]    There are shown in the drawings, embodiments which are presently preferred, it being understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown. 
           [0014]      FIG. 1  is a schematic diagram of a system for dynamically enabling service level requirements in a service oriented architecture (SOA) in accordance with an embodiment of the inventive arrangements disclosed herein. 
           [0015]      FIG. 2  is an illustration that depicts the internal components of the service level profile (SLP) handler and profile directory and their operational relationship to the service processing environment in accordance with an embodiment of the inventive arrangements disclosed herein. 
           [0016]      FIG. 3  is a schematic diagram of a process illustrating interactions between the components of the service level profile (SLP) handler processing a service request in accordance with an embodiment of the inventive arrangements disclosed herein. 
           [0017]      FIG. 4  is a schematic diagram of a system illustrating a specific implementation for dynamically enabling service level requirements in a service oriented architecture (SOA) in accordance with an embodiment of the inventive arrangements disclosed herein. 
           [0018]      FIG. 5  is a collection of sample tables that illustrate the formalized language of service level profiles (SLP) and their use in accordance with an embodiment of the inventive arrangements disclosed herein. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0019]      FIG. 1  is a schematic diagram of a system  100  for dynamically enabling service level requirements in a service oriented architecture (SOA) in accordance with an embodiment of the inventive arrangements disclosed herein. In system  100 , a service request  150  can be made by a service requestor  105  over a network  140  for fulfillment by a service provider  135  utilizing a SOA infrastructure  110 . 
         [0020]    The service requestor  105  can represent a computing device having installed software that generates a service request  150  for a service to display or use with the computing device. A service requestor  105  can represent a variety of computing devices that can communicate with the SOA infrastructure  110  over a network  140 . For example, software running on a mobile telephone can request weather information for a specified location. 
         [0021]    Additionally, many computing devices that are considered a part of an overall computing system, such as the Interact or a corporate intranet, can act as service requestors  105 . For example, many Web sites utilize an advertisement service that places various ads on their Web pages. In this example, the server hosting the Web site is the requestor  105  since it requests the ad service from the provider  135 , which is a server owned by the ad company. 
         [0022]    The SOA infrastructure  110  can include the typical components for handling service requests  150  made by requestors  105 , namely, a service directory  115 , a service processing environment  120 , and a service provider  135 . These components  115 - 135  can be communicatively linked via network  140 . In another embodiment, these components  115 - 135  can communicate via a separate network (not shown) while only one of the components communicates with service requestor  105  over network  140 . 
         [0023]    In the SOA infrastructure  110 , the service request  150  can be received for processing by the service level profile (SLP) handler  125 . The service level profile handler  125  can represent a software component configured to process a service request  150  to generate an interpreted service request  152  for fulfillment by the service processing environment  120 . To process the service request  150 , the SLP handler  125  can retrieve an applicable service level profile  132  from the profile directory  130  and query the service directory  115 . Processing of the request  150  can also include taking into account the state of the service processing environment  120  and requestor  105  information, which can be included in the service request  150 . 
         [0024]    The service directory  115  can be an online directory that provides a uniform way for businesses and organizations to describe available services, service capability, required interface parameters, and output parameters resulting from the described services. In one embodiment, the service directory  115  can use an eXtensible Markup Language (XML) based directory of Web services. Web services specified in the service directory  115  can be described using a Web services description language (WSDL). The service directory  115  can be a universal description discovery and integration (UDDI) directory. 
         [0025]    The service level profile (SLP)  132  can represent a formalized data representation of a service level requirement for the SOA. Service level requirements can define the type of implementation to use to provide a requested service and the performance requirements that the service must meet. For example, a service level requirement can specify that a responding service must provide information in real-time. The SLP  132  can represent the parameters specified by a service level requirement in a standardized format that can be used by the SLP handler  125  to produce the interpreted service request  152 . 
         [0026]    The interpreted service request  152  can be conveyed from the SLP handler  125  to the service processing environment  120  for execution. The interpreted service request  152  can represent instructions, which have been influenced by the service level requirements contained in the SLP  132 , for the service processing environment  120  to use in order to provide the service to the requestor  105 . For example, the interpreted service request  152  can specify a particular service of a specific service provider  135 . The interpreted service request can also detail which resources  122  are to be used for the invoked service  154 . Also, the resources  122  can be dynamically adjusted depending upon a load placed upon the environment  120  to handle the various services in accordance with the associated requests  152 . In one embodiment, different services provided by the environment  120  can have service specific priority levels associated with them, which are used to determine which resources  122  are dedicated to which services. 
         [0027]    The service processing environment  120  can include distributed computing resources  122  representing the hardware, software, and middleware necessary to perform service processing and invocation functions in a SOA computing system. These distributed computing resources  122  can include items that are located in a variety of geographic locations. For example, mirror Web sites located in various states and/or countries can be used to provide better transmission rates for customers in different locations. Additionally, these distributed computing resources  122  can be communicatively linked with additional networks (not shown) and can include a multitude of different operating platforms. 
         [0028]    Network  140  can include any hardware/software/and firmware necessary to convey data encoded within carrier waves. Data can be contained within analog or digital signals and conveyed though data or voice channels. Network  140  can include local components and data pathways necessary for communications to be exchanged among computing device components and between integrated device components and peripheral devices. Network  140  can also include network equipment, such as routers, data lines, hubs, and intermediary servers which together form a data network, such as the Internet. Network  140  can also include circuit-based communication components and mobile communication components, such as telephony switches, modems, cellular communication towers, and the like. The network  140  can include line based and/or wireless communication pathways. 
         [0029]    The service directory  115  and the profile directory  130  can be a physical or virtual storage space configured to store digital information. The directories  115  and  130  can be physically implemented within any type of hardware including, but not limited to, a magnetic disk, an optical disk, a semiconductor memory, a digitally encoded plastic memory, a holographic memory, or any other recording medium. Each of the directories  115  and  130  can be a stand-alone storage unit as well as a storage unit formed from a plurality of physical devices. Additionally, information can be stored within the directories  115  and  130  in a variety of manners. For example, information can be stored within a database structure or can be stored within one or more files of a file storage system, where each file may or may not be indexed for information searching purposes. Further, each directory  115  and  130  can utilize one or more encryption mechanisms to protect stored information from unauthorized access. 
         [0030]      FIG. 2  is an illustration  200  that depicts the internal components of the service level profile (SLP) handler  210  and profile directory  225  and their operational relationship to the service processing environment  205  in accordance with an embodiment of the inventive arrangements disclosed herein. The contents of illustration  200  can be used within the context of system  100  or any other service oriented architecture (SOA) in order to dynamically enable service level requirements. 
         [0031]    As shown in the illustration  200 , the SLP handler  210  and the service level profile directory  225  can operate at a level above that of the service processing environment  205 . That is, the SLP handler  210  can perform functions that are broader in scope and that can affect multiple service requests, whereas the service processing environment  205  can perform functions that are specific to the processing of a single service request. 
         [0032]    For example, the SLP handler  210  can prioritize the processing of received requests prior to passing the associated interpreted request to the service processing environment  205 . Additionally, the SLP handler  210  can monitor the load of various servers within the service processing environment  205  to determine on which server to invoke a service. 
         [0033]    In order to provide direction to the service processing environment  205 , the SLP handler  210  can include a service level pre-processor  215 , a service level interpreter  220 , and a resource monitor  223 . The service level pre-processor  215  can represent a software component of the handler  210  that includes algorithms for determining the applicable service level profile (SLP)  230  for a service request and retrieving it from the SLP directory  225 . Selection of the pertinent SLP  230  can be based on a variety of criteria, including, but not limited to, an identifier of the requestor, the state of the overall system, a business rule or requirement, an internal procedure, and the like. 
         [0034]    In order to create relationships between factors and identifiers within the SLP  230 , the pre-processor  215  can be given permission to access the data stores of other business systems (not shown). For example, the pre-processor  215  can lookup the service level of a requestor in a customer relationship management (CRM) database to determine which of the SLPs  230  that are based on service level is applicable to the service request. 
         [0035]    It should be noted that the algorithms of the service level pre-processor  215  create an environment in which the service level requirements contained within the SLPs  230  are consistently applied to all service requests. 
         [0036]    A SLP  230  can be comprised of a service specification  233  and a capability specification  234 . The service specification  233  can be a section of formalized data defining the nature and type of the service provider that implement the service. For example, the service specification  233  can specify that the service provider should update information in real-time, near real-time, or with certain amount of delay. 
         [0037]    The capability specification  234  can be a section of formalized data defining the performance requirements for the provided service. For example, the capability specification  234  can specify a priority for fulfilling the interpreted service request or a degree of processing that should be taken when handling the service request. 
         [0038]    The service level interpreter  220  can represent a software component of the handler  210  that interprets the contents of the SLP  230 , modifies the service request to convey the interpretation, and/or adjusts system resources to meet service delivery requirements. That is, the interpreter  220  can execute algorithms that translate the data of the SLP  230  into instructions for the service processing environment  205  to execute. For example, the interpreter  220  can translate the requirement for a real-time service in the SLP  230  by addressing the request to server “known” to run the requested service at a real-time rate. Alternately, the interpreter  220  can set the value of an attribute within the request that is understood by the processing environment  205  to represent the service rate (e.g., service_rate=real-time). 
         [0039]    By utilizing resource data from the resource monitor  223 , the interpreter  220  can adjust the allocation of system resources in order to provide the requested service. That is, the interpreter  220  can increase the granularity of instructions given to the service processing environment  205 , as well as provide additional guidance. For example, when a specific service is highly requested, as indicated by the server loads reported by the resource monitor  223 , the interpreter  220  can instruct the service processing environment  205  to transfer running services to servers that are geographically closest to the requestor (i.e., move all Oregon requests from the Florida server to the California server) in order to meet the requirements of an incoming Florida service request. Alternately, the interpreter  220  can direct the use of reserve servers as service providers to accommodate high volume. 
         [0040]    The resource monitor  223  can be a software component that provides information that pertains to the state of the system to the service level pre-processor  215  and/or interpreter  220 . The resource monitor  223  can report on system resources such as available communication media, available bandwidth, available CPU cycles, server loads, and the like. 
         [0041]    In an alternate embodiment, the resource monitor  223  can be implemented as multiple monitors (not shown) within the service processing environment  205 , such as a monitor for each geographic location of resources, that can report information to the resource monitor  223  within the SLP handler  210 . 
         [0042]      FIG. 3  is a schematic diagram of a process  300  illustrating interactions between the components of the service level profile (SLP) handler processing a service request in accordance with an embodiment of the inventive arrangements disclosed herein. Process  300  can be performed in the context of system  100  and/or utilizing the relational structure of illustration  200 . 
         [0043]    Process  300  can begin with the receipt of a service request  305  by the service level pre-processor  310 . The service level pre-processor  310  can query the resource monitor  340  to receive information regarding the current resource state of the system. Utilizing the resource information and the contents of the service request  305 , the pre-processor  310  can determine which service level profile (SLP)  320  is applicable to the request  305 . 
         [0044]    The applicable SLP  320  can then be retrieved from the SLP directory  315  and attached to the service request  305 . The service request  305  and the SLP  320  can then be passed to the service level interpreter  325 . Interpretation of the service request  305  and SLP  320  by the service level interpreter  325  can utilize a service selector  330  and a service determiner  335 . 
         [0045]    The service selector  330  can be a component of the interpreter  325  configured to select a service whose implementation matches the specification in the SLP  320 . For example, the request  305  can be for a stock quote and the SLP  320  can specify that this specific requestor requires a real-time service from Company A. Thus, the service selector  330  can note the selection for a service from Company A that provides a real-time stock quote service. 
         [0046]    Then, the service determiner  335  can determine how to meet the performance requirements specified in the capability specification of the SLP  320  for the selected implementation. The service determiner  335  can utilize data from the resource monitor  340  when making the determination. For example, by examining the current server loads, the determiner  335  can ascertain which server can provide the necessary performance requirements for the service request  305 . 
         [0047]    The instructions pertaining to the service implementation and performance requirements to fulfill the service request  305  can be placed within the interpreted service request  345  by the service selector  330  and service determiner  335 . The interpreted service request  345  can then be conveyed to the service processing environment for execution and fulfillment. 
         [0048]      FIG. 4  is a schematic diagram of a system  400  illustrating a specific implementation for dynamically enabling service level requirements in a service oriented architecture (SOA) in accordance with an embodiment of the inventive arrangements disclosed herein. System  400  can be an implementation of system  100  utilizing WebSphere components. It should be noted that although this example depicts a service requestor  405  that is external to the SOA infrastructure  410 , a service requestor  405  can also be a computing device within the SOA  410 . 
         [0049]    In system  400 , service requestor  405  can request a service from the SOA infrastructure  410  over a network  440 . The SOA infrastructure  410  can consist of a WebSphere Enterprise Service Bus (ESB)  415 , a service directory  417 , a WebSphere process server  420 , a service level profile (SLP) handler  425  with an associated SLP directory  430 , and a WebSphere application server  435 . 
         [0050]    The WebSphere ESB  415  can provide the communications infrastructure between the other components of the SOA  410 . When the WebSphere ESB  415  is coupled with the WebSphere process server  420 , these components  415  and  420  can provide the functions necessary for the execution of service request similar to the service processing environment  120  of system  100 . 
         [0051]    Since the functions of the SLP handier  425  overlay the service processing environment, the handler  425  can exist as a component whose implementation spans both the WebSphere ESB  415  and process server  420 . This configuration can allow the service level pre-processor  427 , the service level interpreter  428 , and the resource monitor  429  components of the SLP handler  425  to have access to the functions of the ESB  415  and process server  420  as well as the data contained within the SLPs  432  of the SLP directory  430  when processing service requests. 
         [0052]    Once the SLP handler  425  addresses an incoming service request, execution instructions can be conveyed to the ESB  415  and/or process server  420 , as required. When fulfilling a service request, the ESB  415  can use the service directory  417  to locate the necessary service provider, such as a WebSphere application server  435 . The WebSphere application server  435  can then provide the service requestor  405  with a service application  436  via the ESB  415  and network  440 . 
         [0053]      FIG. 5  is a collection  500  of sample tables  505 ,  510 , and  520  that illustrate the formalized language of service level profiles (SLP) and their use in accordance with an embodiment of the inventive arrangements disclosed herein. It should be noted that the data contained within these tables  505 - 520  are for illustrative purposes only and are not meant as representation of implementation or as an exhaustive listing. 
         [0054]    Table  505  can contain data representing service level requirements prior to implementation within a service oriented architecture (SOA) environment. This service level requirements table  505  can contain data describing a client class  507  and a description  508  of the class. 
         [0055]    As shown in this example, the list of identifiers defining the client classes  507  can include gold, silver, and bronze. Each client class  507  can have an associated description  508  that can describe the type of service to be provided to clients associated with that class. 
         [0056]    The description  508  can be written using terminology that is generic and easy for people to understand. Additionally, terminology can differ depending on the person who writes the description  508 , though the meaning of the description can be preserved. For example, Mr. X writes service level requirements using the term “real-time”, whereas Mr. Z uses is “instantaneous response”. Regardless of terminology, the components of a SOA cannot comprehend natural language terminology. 
         [0057]    In order to understand the meaning of a written description  508 , a computing system can require additional assistance. Currently, such assistance can require highly trained personnel who are intimately familiar with the SOA to translate the written words into terms and values that can be understood by the system. A service level profile, such as those shown in table  510 , can help to relieve this burden by providing a formalized structure that utilizes standardized terminology. 
         [0058]    Table  510  contains example service level profiles that correspond to the written descriptions  508  of table  505  (e.g. the P_Gold service level profile  512  corresponds to the gold client class  507 ). The correlation between the written description  508  and the data fields of the service level profile table  510  can be illustrated using the gold client class  507  as an example. 
         [0059]    As previously noted, the gold client class  507  can be translated into a service level profile  512  with the identifier P_Gold. The first sentence of the description  508 , “Real-time quote service has to be used” can be translated into the service specification  513  as the value “RealTimeSQ”. Entries in the service specification  513  and capability specification  514  can include baseline and preferred values to denote preferences between different levels of requirements. Since a real-time service is always required, both the baseline and preferred values of the service specification  513  can be set to “RealTimeSQ”. 
         [0060]    The entries and values of the capability specification  514  can represent the second sentence of the description  508 , “Quote results have to be delivered with high priority and audited for response time of less than 3 seconds”. The high priority of delivery requirement can be expressed in the delivery priority attribute  516  and the auditing requirement can be expressed in an audit attribute  518 . 
         [0061]    Once all the written service level requirements of table  505  are translated into the service level profiles of table  510 , the identifiers  512  for the service level profiles can be used in tables, such as client table  520 . The client table  520  can contain associations between client IDs  521  and client classes  522 . This table  520  can be used by the pre-processor of the SLP handler to determine which SLP of table  510  to use based on the client ID  521 , which can be included in the service request. 
         [0062]    The present invention may be realized in hardware, software, or a combination of hardware and software. The present invention may be realized in a centralized fashion in one computer system, or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software may be a general purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein. 
         [0063]    The present invention also may be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer program in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form. 
         [0064]    This invention may be embodied in other forms without departing from the spirit or essential attributes thereof. Accordingly, reference should be made to the following claims, rather than to the foregoing specification, as indicating the scope of the invention.