Referring now to the drawings wherein like elements are numbered alike in the several FIGURES:
The present invention and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the present invention in detail. The examples used herein are intended merely to facilitate an understanding of ways in which the invention may be practiced and to further enable those of skill in the art to practice the invention. Accordingly, the examples should not be construed as limiting the scope of the invention.
As discussed above, a manageable resource is a specialization of a Web services resource. As defined in the WSRF Resource Properties specification, the state of a Web services resource is exposed through the definition of a resource property document. The resource property document may be defined by an XML schema, and is intended to provide an external view of all of the state information that makes up a particular aspect of a physical IT resource. The properties that are exposed in the resource property document may not necessarily be provided by a single source, i.e. agent, management system, and the like. Some properties may be taken from a management system, such as an object manager (e.g., a CIM Object Manager), and others may be taken from another management system or some other agent/provider. In order to accurately reflect the state of a manageable resource, in support of some management capability, a federated view across these potentially disparate sources is provided.
For example, in one embodiment the manageable resource may be a printer. In this case, an implementer may choose to expose properties associated with the physical printer, such as a descriptive name for the printer being managed, the manufacturer of the printer, and the number of pending jobs for the printer. According to the MUWS specification, all manageable resources must expose an identifying property, which is a resource ID. It is also desired that the printer be able to accept print requests through a print operation. For example, the number of pending print jobs may need to be queried on the physical IT resource, by some system that knows how to access the printer, in order to get the current count, but another property, such as the name alias, may come from some static data source such as Entity Enterprise JavaBeans (EJB), Relational Database, or a flat file on the file system.
In exemplary embodiments, the manageable resource may expose a set of operations that cannot all be handled by any single agent/management system. In order to support all the operations outlined by some manageability capability it may be necessary to provide a means for dispatching these operations to the correct management system that knows how to perform the desired operation on the physical IT resource. For example, the print operation exposed by the manageable resource may be pushed down to some management system in order to submit the job for printing on the physical IT resource.
As used herein, the term “federation” refers to the binding of the state and operations of a manageable resource to one or more providers (agents, management systems, etc). In order to describe the policy for binding state and operations to a provider, it is necessary to define a language for the federation engine to use. The language provides a mapping between a property and/or operation name to some provider. The language may also define any information that is necessary to facilitate a connection to the specified provider. In the case where this provider is an EJB, the Java Naming and Directory Interface (JNDI) name may be required to lookup the entity; in other cases this information may need to include an IP address, port information, or the like. Optionally, the language may provide any quality of service features such as reliability, performance, and serviceability.
Referring now to
Turning now to
A proxy registry 210 can be used to provide an extension point into the federation engine. The proxy registry 210 will store a mapping from the identifier used in the instance of the federation language provided to a concrete implementation of the proxy interface 206. This allows for the implementation of the proxy interface 206 to change without having to change the identifier in all instance documents. Also, the proxy registry 210 would allow for the dynamic registration and deregistration of proxy instances 206 and makes the federation engine 200 configurable at runtime. A proxy factory 212 is used to create instances of the correct concrete proxy implementation class 204 based on the mapping that is stored in the proxy registry 210.
Turning now to
In exemplary embodiments, all operations that are destined for a proxy instance may follow the same general pattern. In the case of a get multiple resource properties invocation, some optimizations may occur. Mainly, all properties that are destined for a single proxy instance, can be collected, and dispatched as a get multiple resource properties invocation, as opposed to a series of get multiple resource properties invocations on the same proxy instance. The get multiple resource properties may be optimized by a provider, and offer some benefit over single get multiple resource properties requests.
Turning now to
Referring now to
As described above, the embodiments of the invention may be embodied in the form of computer-implemented processes and apparatuses for practicing those processes. Embodiments of the invention may also be embodied in the form of computer program code containing instructions embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other computer-readable storage medium, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. The present invention can also be embodied in the form of computer program code, for example, whether stored in a storage medium, loaded into and/or executed by a computer, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. When implemented on a general-purpose microprocessor, the computer program code segments configure the microprocessor to create specific logic circuits.
While the invention has been described with reference to exemplary embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted for elements thereof without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the invention without departing from the essential scope thereof. Therefore, it is intended that the invention not be limited to the particular embodiment disclosed as the best mode contemplated for carrying out this invention, but that the invention will include all embodiments falling within the scope of the appended claims. Moreover, the use of the terms first, second, etc. do not denote any order or importance, but rather the terms first, second, etc. are used to distinguish one element from another.