Abstract:
Embodiments of the present invention address deficiencies of the art in respect to SOA virtualization and provide a novel and non-obvious method, system and computer program product for service endpoint virtualization and dynamic dependency management. In one embodiment of the invention, a method for service endpoint visualization and dynamic dependency management can be provided. The method can include issuing a ticket in lieu of a service endpoint to a querying client for an identified service, subsequently redeeming the ticket with a service endpoint to an instance of the identified service, and re-redeeming the ticket at a later time to provide a service endpoint to a different instance of the identified service.

Description:
BACKGROUND OF THE INVENTION 
       [0001]    1. Field of the Invention 
         [0002]    The present invention relates to the field of component based distributed computing and more particularly to component based distributed computing in a service oriented architecture (SOA) environment. 
         [0003]    2. Description of the Related Art 
         [0004]    It is now a common trend that business oriented applications are produced from one or more components which can be individually re-used to create business processes for different solutions. Each of these components can expose itself as a set of reusable business functions, also referred to as “services” comporting with computing standards for deploying enterprise level logic that facilitate an open service oriented architecture (SOA). An SOA essentially can be defined as a system where all exposed business and technical functions are in the form of reusable services. These reusable services can be accessed by a wide range of clients and can communicate with each other to engage either in simple data passing between two or more services, or in activity coordination by two or more services. 
         [0005]    In an SOA, a client can invoke an operation on a service to perform a function and, optionally the client can receive a response. Invoked services are generally business functions configured to fulfill the needs of business customers, whether those customers are individual consumers or other businesses. In the example of a commerce application, the functions can be grouped into various services where each service can specialize in functions such as catalog management, shopping cart management, credit card transaction processing, sales tax computation and the like. By utilizing an SOA, services in such a solution can easily interoperate with other business processes in a larger solution involving one or more separate business entities and one or more separate consumer entities. The entire solution can also evolve and adapt, adding or changing some functions without displacing others. This is because the service access is based on standards and interfaces, and not on proprietary dependencies. 
         [0006]    SOAs are based on loose coupling between service providers and service consumers. Connections between providers and consumers are negotiated based on interfaces rather than implementations. These connections are ideally made using a late binding approach, where a needed provider endpoint address is resolved at runtime with the aid of a registry such as the Universal Description, Discovery and Integration (UDDI) registry. Specifically, an important benefit of SOA is the ability to realize service virtualization. In virtualization, service consumers bind to virtual endpoints; then some logic or mechanism in the virtual endpoint ultimately resolves a connection to a desired, concrete endpoint. The value of virtualization is that services are defined logically, allowing clients to bind to a single, unchanging entity, while the actual functional service implementation can be redirected or changed at any time. 
         [0007]    The SOA approach implicitly creates new requirements for management of systems. In an open environment, with large numbers of providers and consumers and the ability to easily make connections between any two endpoints, the logical links that comprise the overall system can easily grow in number. Each of these links represents a dependency that potentially requires management. Since the links are so easy to establish, new dependencies can arise at any time. Some dependencies may be long-lived, some temporary, and some intermittent. In managing such a wide range of dependency types, it is unlikely that a single, formal or process-oriented system can be successful. 
       BRIEF SUMMARY OF THE INVENTION 
       [0008]    Embodiments of the present invention address deficiencies of the art in respect to SOA virtualization and provide a novel and non-obvious method, system and computer program product for service endpoint virtualization and dynamic dependency management. In one embodiment of the invention, a method for service endpoint visualization and dynamic dependency management can be provided. The method can include issuing a ticket in lieu of a service endpoint to a querying client for an identified service, subsequently redeeming the ticket with a service endpoint to an instance of the identified service, and re-redeeming the ticket at a later time to provide a service endpoint to a different instance of the identified service. 
         [0009]    In one aspect of the embodiment, issuing a ticket in lieu of a service endpoint to a querying client for an identified service can include receiving a query for a service type, locating a ticket for the service type, and returning the located ticket to the querying client. Furthermore, returning the located ticket to the querying client further can include determining expiration information for the ticket and embedding the expiration information in the ticket. In another aspect of the embodiment, the method can include expiring the ticket after a duration specified by the expiration information, and requiring a new ticket redemption for the service endpoint for the identified service. 
         [0010]    Notably, subsequently redeeming the ticket with a service endpoint to an instance of the identified service can include receiving the ticket from the querying client, locating a service endpoint to an instance of the identified service, extracting a callback for the querying client and storing the extracted callback for later retrieval, and returning the service endpoint to the querying client. In this regard, the method also can include detecting a change in the instance of the identified service, and notifying the querying client through the callback that a new ticket redemption for a new service endpoint for a different identified service is required. 
         [0011]    In another embodiment of the invention, a service endpoint binding data processing system can be provided. The system can be configured for service endpoint visualization and dynamic dependency management and can include a registry interface to a registry of service endpoints for different services in an SOA component based system, and a virtualization server coupled to the registry interface. The virtualization server can include program code enabled to issue a ticket in lieu of a service endpoint to a querying client for an identified one of the services, to subsequently redeem the ticket with a service endpoint to an instance of the identified service, and to re-redeem the ticket at a later time to provide a service endpoint to a different instance of the identified service. 
         [0012]    The system further can include a data store of callback addresses for different querying clients bound to different service endpoints for the different services. In the latter circumstance, the virtualization server can include program code enabled to notify a selected one of the different querying clients to refresh a respective ticket through a corresponding callback in the data store for the selected one of the different querying clients. 
         [0013]    Additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The aspects of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed. 
     
    
     
       BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS 
         [0014]    The accompanying drawings, which are incorporated in and constitute part of this specification, illustrate embodiments of the invention and together with the description, serve to explain the principles of the invention. The embodiments illustrated herein are presently preferred, it being understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown, wherein: 
           [0015]      FIG. 1  is a schematic illustration of a service endpoint binding data processing system configured for service endpoint visualization and dynamic dependency management; and, 
           [0016]      FIGS. 2 through 5 , taken together, illustrate a process for service endpoint visualization and dynamic dependency management. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0017]    Embodiments of the present invention provide a method, system and computer program product for service endpoint visualization and dynamic dependency management. In accordance with an embodiment of the present invention, a registry interface for a service registry can manage access to a requested service through the issuance of a service ticket providing a time limited binding endpoint for a service. Upon issuing a service ticket within the binding endpoint to a requesting client, the registry interface can record a callback to the requesting client. Subsequently, run-time changes in the binding endpoint can be managed by issuing a notice to the callback and by issuing a new ticket referencing a new binding endpoint. 
         [0018]    In further illustration,  FIG. 1  is a schematic illustration of a service endpoint binding data processing system configured for service endpoint visualization and dynamic dependency management. The system can include a host computing platform  110  supporting the operation of a registry interface  140  to a registry  180  of service endpoints for different services in an SOA architected system. The host computing platform  110  can be communicatively coupled to multiple different service hosts  120  over a computer communications network  100 , each of the service hosts  120  supporting the operation of a corresponding service  130 . 
         [0019]    The registry interface  140  can provide query access to the registry  180  on behalf of communicatively coupled querying clients  150  over the computer communications network  100 . In this regard, the registry interface  140  can be configured to receive a query for a service type and to locate a corresponding service endpoint for the service type in the registry  180 . Notably, a virtualization server  200 A can be coupled to the registry interface  140  as a corresponding virtualization client  200 B can be coupled to the querying client  150 . In concert together, the virtualization server  200 A and virtualization client  200 B can implement service endpoint visualization and dynamic dependency management. 
         [0020]    Specifically, instead of the registry interface  180  returning to the querying client  150  a direct binding to a particular one of the services  130  in response to a service query, the virtualization server  200 A can return to the querying client  150  a ticket  190 A for the particular one of the services  130 . The ticket  190 A can be time lapsing such that after the expiration of a specified period, the querying client  150  will be required to refresh the ticket  190 A. In any event, the virtualization client  200 B in the querying client  150  can store the ticket  190 A in memory  160  and, when requiring a binding to the particular one of the services  130 , the virtualization client  200 B can forward a combined ticket/callback  190 B to the virtualization server  200 A. The combined ticket/callback  190 B can include both the ticket  190 A and a callback address for the querying client  150 . 
         [0021]    Upon receiving the ticket/callback  190 B, the virtualization server  200 A can store the callback address in association with the querying client  150  and can return a valid endpoint address  190 C to the virtualization client  200 B which in turn can bind to the particular one of the services  130  using the endpoint address  190 C. Subsequently, when a change to the binding of the particular one of the services  130  is required, the virtualization server  200 A can forward a change event  190 D to the virtualization client  200 B. The virtualization client  200 B, in turn, can reissue the ticket/callback  190 B in order to receive a new endpoint address  190 C for a different one of the services  130  to which to bind. 
         [0022]    Finally, reporting logic  170  can be coupled to the registry interface  140 . The reporting logic  170  can include program code enabled to report on the number and identity of querying clients  150  dependent upon a particular one of the services  130 . Additionally, the program code of the reporting logic  170  can be enabled to provide statistics as to the pattern of tickets redeemed by different query clients  150  and also a classification of the different querying clients  150 . Using reports generated by the reporting logic  170 , tickets  190 A can be invalidated not only for individual querying clients  150 , but also for whole classes of querying clients  150 . Likewise, different tickets  190 A can be issued for different classes of querying clients  150 . 
         [0023]    In yet further illustration,  FIGS. 2 through 5 , taken together, illustrate a process for service endpoint visualization and dynamic dependency management. Beginning in block  210  of  FIG. 2 , a service query can be received from a querying client for a particular service type. In block  220 , a service can be located in the registry corresponding to the service type. Thereafter, an identifier for the located service can be returned in a result set to the querying client along with descriptive information pertaining to the located service. In block  310  of  FIG. 3 , a ticket request can be received from a querying client for the identifier previously provided for the service type. In block  320 , a ticket can be generated for the service identifier for the querying client and returned to the querying client in block  330 . 
         [0024]    In block  410  of  FIG. 4 , a ticket can be provided by a querying client in association with a particular service. In block  420 , an endpoint can be located corresponding to the ticket. Importantly, in block  430  a callback address can be extracted from the ticket for the querying client and stored in association with the querying client. Thereafter, the located endpoint and expiration information can be returned to the querying client in block  440 . In this regard, the expiration information can include an expiration time or date, or a period of time during which the ticket is considered valid and subsequent to which a refreshed ticket will be required. 
         [0025]    In block  510  of  FIG. 5 , the status of an endpoint for a service bound to one or more dependent querying clients can be determined. In decision block  520 , if the status indicates that a change in binding for the service is required, in block  530 , each dependent client can be identified for the binding and in block  540 , the callbacks for each identified dependent client can be retrieved. Finally, in block  550 , each dependent client can be notified through the callback that a change in binding is required in response to which each dependent client can resubmit the ticket in exchange for a new endpoint for binding. 
         [0026]    Embodiments of the invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, and the like. Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. 
         [0027]    For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD. 
         [0028]    A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers. Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.