Patent Application
20120254278
This disclosure relates generally to the field of computer software. More particularly, but not by way of limitation, it relates to a technique for controlling the processing of a software function.
A distributed software system is a software system whose functionality is distributed across a plurality of software components and computer nodes, or a system that is architected in a manner that it is capable of being distributed across a plurality of software components and computer nodes. One of the challenges in dealing with a distributed software system is deciding which software component and/or computer node should process a software function. Another major problem has been a difficulty in extending control functions without having to upgrade the entire system. There are many algorithms and architectures that enable distributed software systems. However, they are usually quite rigid and do not allow the system to adapt to new resource types, resource topologies, and larger scale.
In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention may be practiced without these specific details. In other instances, structure and devices are shown in block diagram form in order to avoid obscuring the invention. References to numbers without subscripts or suffixes are understood to reference all instance of subscripts and suffixes corresponding to the referenced number. Moreover, the language used in this disclosure has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter. Reference in the specification to “one embodiment” or to “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least one embodiment of the invention, and multiple references to “one embodiment” or “an embodiment” should not be understood as necessarily all referring to the same embodiment.
The techniques disclosed herein allow invocation of an operation for a class without knowing in advance what provider will perform the operation. Each invocation of the operation may vary from each other invocation, performing different activities by different actors, without the invoker having to understand or even be aware of the way in which the invocation is processed. The operation invocation may be considered a black box, and does not require knowledge of subclass or force the invoker to make decisions about how the invocation is to be processed.
Embodiments disclosed below apply concepts from programming language implementations such as the JAVA® programming language. (JAVA is a registered trademark of Oracle America, Inc.) In these object-oriented languages, there exists a concept called dynamic dispatch. This concept enables run-time modification of the semantics of a function. For example, let us consider, in JAVA, a function called modify defined on a class Controller, and let us consider a sub-class of Controller called SpecificController. The JAVA language semantics state that both classes can define semantics for the modify function that are different from each other. At run-time, the JAVA Virtual Machine will dynamically dispatch to the correct implementation based on the object context in which the function is invoked.
To illustrate dynamic dispatch, let us consider the following code snippets:
Controller c1=new Controller( )
Controller c2=new SpecificController( )
c1.modify( )
c2.modify( )
The first call to modify invokes the semantics of the Controller class, and the second call invokes the semantics of the SpecificController class. The second call illustrates how dynamic dispatch does not depend on the type of the variable, but on the type of the object on the heap.
The embodiments disclosed below apply these concepts to expose an object-oriented software system where, at run-time, software components can extend semantics of software functions. In addition, the same concept allows dynamic modification of the way the software system distributes software functions. This lets administrators of the software system easily add scale, new resources, and new resource types, without affecting the end-users of the system.
To summarize, various embodiments introduce the concept of a Provider Definition and a Provider. A Provider Definition is metadata about a Provider (an instance of a Provider Definition), which is code that implements the semantics of an operation in the application. The possible operations on every class in the application are modeled and associated with one or more Provider Definitions.
Providers are themselves hosted on Nodes and may be distributed. Providers may be integration points to other management systems.
Class object instances are created by dynamically dispatching the create operation to a Provider associated with the create operation on the class. Other types of operations on class objects are similarly dynamically dispatched. If there are multiple eligible Providers of a given operation, selection of a Provider can be done any number of ways, including by defining selection policies, as described below. Operations on existing class instances are dispatched to the appropriate Provider based upon eligibility, policy, and/or relationships among Providers, in various embodiments.
Because different instances of the same class can have different Providers, the same operation, such as “create” for application software (essentially, install the software), can result in different Providers performing what are quite different processes under the covers. New classes, operations, Provider Definitions, Providers, and Nodes may be introduced without impact to the dynamic dispatching architecture.
The same instance of a class may have several Providers (belonging to one or more Provider Definitions) for the same operation. The dispatch may be based on any kind of selection policy, most likely involving external conditions to the system. For example, an application software instance may be shut down (i.e., the shutdown operation is invoked) in a different way, by a different Provider, based on the current state of the application software relative to the state of the multi-tier application it is part of. A frequent special case of this involves the same instance having different Providers for different operations. One Provider may be able to start and stop the instance, and another may be able to patch it or upgrade it.
The system exposes an object-oriented application programmer interface (API). End users of the system may interact with this API, usually indirectly through a user interface (UI) that in turn uses the API. Any desired UI may be used, and the UI is not further described herein. The API exposes the concepts of objects and object classes. The most common interactions will be to either create a new object given a class, destroy an existing object, or to invoke a function on an object. Object creation and destruction may be exposed as specially named functions, so we may reduce every interaction to a function invocation either on a class or on an object. The system may dynamically dispatch each function invocation differently, depending on the class or object upon which it is invoked.
In normal object-oriented systems, each object class has specific semantics, and all object instances of a given specific class must have the same semantics for every function. Sub-classing is the typical way to allow two different objects to have different semantics of the same function. This is typically called “subtype polymorphism” in computer science. Embodiments disclosed herein add an extra level of indirection to account for the distributed, heterogeneous, and dynamic nature of the software system. A system according to various embodiments may control a heterogeneous set of resources, while exposing a common categorization and semantics for those resources.
In one embodiment, a software system controls compute resources, network resources, and storage resources to manage a cloud. The compute resources may be of different types; for example, some virtual compute resources may be XEN® resources and others VMWARE® resources. (XEN is a registered trademark of Citrix Systems, Inc.; VMWARE is a registered trademark of VMWare, Inc.) However, the management system abstracts the vendor-specific differences behind the object-oriented API, and introduces a class called VirtualGuest, with the functions create, destroy, start, and stop. The semantics of these functions may differ depending on which instance of the class is the subject of the function.
To accommodate this level of flexibility, we introduce the notion of provider definitions and providers. A provider definition represents the code that implements the semantics of one or more functions. A provider represents a specific instance of a provider definition. Each object in the system has all of its functions implemented by one or more providers. A component of the system called the provider registry maintains a mapping of providers and functions is defined by the provider definitions. When handling a request to invoke a function, the system dynamically dispatches to the correct provider based on this mapping.
Various embodiments may implement various ways for the provider registry to select a provider dynamically for a function call. In some embodiments, the provider registry may determine a set of eligible providers for a call, and pick one of them by applying a policy through a policy engine. Policies may be based on many kinds of conditions, including service level agreements (SLA), location, quality of service (QOS), etc. The policy engine itself may be modeled as a provider of advice, and therefore the selection of an appropriate policy may be itself dynamically dispatched. In other embodiments, the system may determine a set of eligible providers by organizing providers into peer sets, groups of providers that collaborate to provide semantics to a set of objects that they own.
We have so far seen how the mechanism of dynamic dispatch has enabled the management of a heterogeneous set of resources with a common API. We now summarize how the concept of Provider allows us to use these concepts to enable a more scalable and flexible software topology. A normal approach in object-oriented systems is to enable extension via sub-classing. This has the disadvantage of requiring that the end user become aware of the various sub-classes, or requires use of various design patterns to ignore the sub-classes. Concerning a class that represents a resource which has multiple dimensions of heterogeneity, sub-classing imposes an extensive, repetitive class hierarchy. With the Provider approach, we need merely add a new Provider Definition, and create new Providers to manage a new kind of resource under the same class, without the addition of any sub-classes.
As mentioned above, most object-oriented systems allow the extension of the system semantics via end-users adding new classes to the system. Embodiments disclosed herein need not require this (through use of Provider Definitions for existing classes). However, in some embodiments, end users may want to add entirely new types to the system. For example, in one embodiment, a software system may expose telemetry information about objects named VirtualClusters, in the form of a class representing the telemetry. An end user may want to expose telemetry information that only they understand how to compute. They may do this by adding a new class, and a new relationship between the VirtualCluster class and their new class. In addition, they may register a Provider Definition that implements the semantics of their class (i.e. that can compute the telemetry information.) Once this registration is complete, the new telemetry class is indistinguishable from any other object in the system. The dynamic-dispatch notions continue to work using exactly the same syntax as any other class that was part of the original system.
The techniques described above are different from event-based systems. Event-based systems exhibit some of the same multi-node aspects, as well as the benefits of not forcing sub-classing on the model. However, event-based systems inherently require special design patterns for client code, as most common programming languages are not inherently event-based. The disclosed approach has all of the benefits of an event-based approach with the benefits of a more common object-oriented language approach. The advantages include (a) control of heterogeneous resources without forcing subclassing, which leads to a more flexible API; (b) seamlessly adding scale to a software system without affecting end users; and (c) seamlessly reconfiguring the software system topology without affecting end users. While one use of such a software system may be a system for managing a distributed network of information technology (IT) resources, the techniques described herein are not limited to IT resource management systems, but may be used on any distributed software system.
In block 110, the provider system looks up the object class definition for the operation on the specified object. In block 120, the provider system determines what providers are registered as providing the requested operation for the relevant object class.
In block 130, the provider system selects which registered provider should be requested to perform the operation. If more than one provider can perform the operation for the requested class, then the provider system uses a technique for choosing which of the plurality of possible providers should perform the operation, using techniques described in more detail below. In block 150, the selected provider is passed the invocation to perform the requested operation.
In one embodiment, the provider system comprises software provided on multiple computers, as illustrated in the block diagram of
If the provider database 240 indicates that only a single provider is registered for providing the requested operation, then the provider registry 230 may pass the request to that registered provider for execution.
In one embodiment, provider registry 230 may request advice from advisor software running on server 270 on which of provider 250 and 260 should be selected by the provider registry 230 to perform the requested operation. The advisor software 270 may use policies or rules stored in a policy database 280 to make the decision and respond to the provider registry 230. Some embodiments of a provider system 200 may omit the advisor software 270. In one embodiment, the identity of the advisor software 270 is also determined by the provider registry 230 using the API, with the advisor software 270 registered as providing the advice operation in the provider database 240.
The provider definition database 240 may be implemented in any convenient or desired way, including structured databases that are controlled by a database management engine, flat files, or any other type of data storage. In some embodiments, the provider definition database 240 may be an in-memory data structure of the provider registry 230.
An example embodiment of provider definition database 240 is illustrated in block diagram form by
In one embodiment, the provider registry 230 also keeps track of which provider created the object on which the operation is to be performed, and by default, that provider is given the opportunity to provide the operation. In a further embodiment, a provider may be queried by the provider registry 230 to determine if that provider can provide the operation. This allows a provider that may be overloaded or where there is some other reason that provider should not or cannot provide to the operation to refuse a request by the provider registry 230 to provide the operation. In one embodiment, the provider may locate a substitute provider for the operation by making its own call to the API. In other embodiments, the provider may simply refuse the request to perform the operation, causing the provider registry 230 to make another selection.
In one embodiment, the column 308 keeps track of peers of a provider. If the provider originally selected by the provider registry 230 does not handle the operation on that object, then one of the peers of that provider may be chosen, by random choice or otherwise, to provide the operation. This embodiment also allows for situations in which the provider that created the object does not handle the requested operation on that object. Thus, a creator of an object is not required to handle all operations performed on that object. In other embodiments described below, trees of related providers may be employed.
In the example table 300 of
Row 330 and row 340 illustrate that providers on other nodes, in this case node 260 of
Although illustrated as a single table in
Dynamic dispatch in the context of a programming language is normally applied on a single node. In the system described herein, each provider is mapped to a node, intrinsically making the operation's dynamic dispatch distributed. Thus, to add more scale to the software system, we need merely add new nodes and create new providers on those new nodes. The provider registry 230 automatically starts dispatching to the correct providers, including the newly added providers. Furthermore, merely by modifying the provider registry 230, the network topology of the software system itself can be reconfigured at runtime.
In one embodiment, providers may be linked in parent-child relationships that may be used by the provider registry 230.
The provider registry 230 responds to the lookup request 521 based on the provider definitions 240, indicating that provider 410, which is registered as providing the operation on the object, should provide the operation on the object. The API 520 may then send request 522 to provider 410 to perform the operation on the object. The provider 410 acknowledges the request in response 541 and the API acknowledges the original request from client 510 in response 523. The operation may then be performed on the object asynchronously with the original request 511.
In this situation, the provider 410 does not wish to provide the operation on the object. This may be for any reason, including overloading of the provider 410 or any other reason whatsoever. Therefore, the provider 410 initiates a request 542 to the API 520 to find a substitute provider.
The API 520 again requests the provider registry 230 in request 524 to identify a provider. In request 524, the API 520 instructs the provider registry 230 to limit the search for a provider to children of provider 410. Referring back to the provider tree of
Provider 430 also does not wish to provide the operation on the object, and initiates request 552 through the API 520 to find a substitute provider. The API 520 then sends lookup request 527 to the provider registry 230 specifying that the provider search should be limited to children of provider 430. Both of the children 440 and 450 of provider 430 are registered to provide the operation of the object, and in this instance, the provider registry 230 selects provider 440 and responds with response 533 to the API 520 indicating provider 440 is to provide the operation on the object.
The API 520 then sends request 528 to provider 440. Provider 440 acknowledges the requests with response 561 back to the API 520, which then responds to provider 430 with response 529. The provider 440 can provide the operation on the object and performs that operation asynchronously (not shown in
In one embodiment, the techniques described above may be implemented in a distributed management system. Different nodes in the management system may provide management functions as operations on objects in the management system. The techniques described herein, however, are not limited to management systems and may be used in any distributed object-oriented software system.
Referring now to
System unit
It is to be understood that the above description is intended to be illustrative, and not restrictive. For example, the above-described embodiments may be used in combination with each other. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the invention therefore should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein.”
