|
Software Patent Abstract
A computer implemented method, data processing system, computer
usable program code, and active repository are provided for management
of a software service. A request is received to deploy the software
service in a computer network. A dependency analysis is performed
for the requested software service to determine component software
services and physical resources necessary to deploy and manage new
software service as a composite in responsive to the software service
being the new software service. An active object is created to manage
the new software service using an active template based on the analysis.
The new software service is deployed in the computer network using
the active object. The new software service is managed using the
active object.
Software Patent Claims
1. A computer implemented method for management of a software service,
the computer implemented method comprising:receiving a request to
deploy the software service in a computer network;responsive to
the software service being a new software service, performing a
dependency analysis for the requested software service to determine
component software services and physical resources necessary to
deploy and manage the new software service as a composite;creating
an active object to manage the new software service using an active
template based on the dependency analysis;deploying the new software
service in the computer network using the active object; andmanaging
the new software service using the active object.
2. The computer implemented method of claim 1, wherein the dependency
analysis is triggered by an imbalance in a current state and a desired
state of the software service, wherein the imbalance in the current
state and the desired state may occur in response to at least one
of a service request, a request from a dependent service, global
policies, global management actions, administrative actions, a supporting
service, a supporting physical resource, or a spontaneous change
in a state of the software service.
3. The computer implemented method of claim 1, wherein the active
object performs at least one of a monitoring function, an analyzing
function, a configuration function, or an execution function.
4. The computer implemented method of claim 1, wherein the active
template represents one of a plurality of physical resources or
one of a plurality of software service types in the computer network.
5. The computer implemented method of claim 1, wherein the active
object uses a plurality of management interfaces to manage the new
software service.
6. The computer implemented method of claim 5, wherein the plurality
of management interfaces comprises at least one of a service specification
interface, a dependency requirements interface, a service configuration
interface, a service deployment interface, a service state interface,
or a lifecycle management interface.
7. The computer implemented method of claim 6, wherein the service
specification interface identifies functionalities provided by the
new software service.
8. The computer implemented method of claim 6, wherein the dependency
requirements interface provides at least one of:identifying the
physical resources required for making the new software service
available; oridentifying the other software services required for
making the new software service available; oridentifying other software
services that depend on the new software service.
9. The computer implemented method of claim 6, wherein the service
configuration interface provides at least one of:managing information
on configuring supporting services so that the new software service
is deployed on top of the supporting services;managing information
on configuring the new software service given a set of the supporting
services that meet a dependency requirement; ormanaging a manner
in which the dependent services are to be configured.
10. The computer implemented method of claim 6, wherein the service
deployment interface provides at least one of:managing deployment
of the new software-service given a specific configuration of supporting
services;managing the new software service functionality to be enabled;
ormanaging higher-level software services to be supported.
11. The computer implemented method of claim 6, wherein the service
state interface provides at least one of:listing software service
functions selected and enabled;listing actual software service instances
selected to support the new software service;listing actual software
service instances supported by the new software service, demand
placed by the software service instances, or current usage by supported
services;listing any service level agreements with the supported
software service instances; orlisting any service level agreement
violations.
12. The computer implemented method of claim 6, wherein the lifecycle
management interface provides at least one of:managing a service
lifecycle;managing a lifecycle of a software package used to deploy
the new software service; ormanaging a lifecycle of a service management
layer.
13. The computer implemented method of claim 1, further comprising:responsive
to the software service being an existing software service, identifying
an existing active object that manages the existing software service;reconfiguring
and deploying the existing software service in the computer network
using the existing active object; andmanaging the existing software
service using the existing active object.
14. The computer implemented method of claim 1, wherein a plurality
of software services are simultaneously managed by a plurality of
active objects from an active repository, wherein each active object
responding to state imbalances in the software service it manages.
15. A data processing system comprising:a bus system;a communications
system connected to the bus system;a memory connected to the bus
system, wherein the memory includes a set of instructions; anda
processing unit connected to the bus system, wherein the processing
unit executes the set of instructions to receive a request to deploy
the software service in a computer network; perform a dependency
analysis for the requested software service to determine component
software services and physical resources necessary to deploy and
manage the new software service as a composite in response to the
software service being a new software service; create an active
object to manage the new software service using an active template
based on the dependency analysis; deploy the new software service
in the computer network using the active object; and manage the
new software service using the active object.
16. The data processing system of claim 15, wherein the dependency
analysis is triggered by an imbalance in a current state and a desired
state of the software service, wherein the imbalance in the current
state and the desired state may occur in response to at least one
of a service request, a request from a dependent service, global
policies, global management actions, administrative actions, a supporting
service, a supporting physical resource, or a spontaneous change
in a state of the software service.
17. A computer program product comprising:a computer usable medium
including computer usable program code for management of a software
service, the computer program product including:computer usable
program code for receiving a request to deploy the software service
in a computer network;computer usable program code for performing
a dependency analysis for the requested software service to determine
component software services and physical resources necessary to
deploy and manage the new software service as a composite in response
to the software service being a new software service,;computer usable
program code for creating an active object to manage the new software
service using an active template based on the dependency analysis;computer
usable program code for deploying the new software service in the
computer network using the active object; andcomputer usable program
code for managing the new software service using the active object.
18. The computer program product of claim 17, wherein the dependency
analysis is triggered by an imbalance in a current state and a desired
state of the software service, wherein the imbalance in the current
state and the desired state may occur in response to at least one
of a service request, a request from a dependent service, global
policies, global management actions, administrative actions, a supporting
service, a supporting physical resource, or a spontaneous change
in a state of the software service.
19. An active repository comprising:a plurality of active templates;
andan active object repository, wherein the active repository receives
a request to deploy the software service in a computer network;
performs a dependency analysis for the requested software service
to determine component software services and physical resources
necessary to deploy and manage the new software service as a composite
in response to the software service being a new software service;
creates an active object to manage the new software service using
an active template based on the dependency analysis; deploys the
new software service in the computer network using the active object;
and wherein the active object manages the new software service.
20. The active repository of claim 19, wherein the dependency analysis
is triggered by an imbalance in a current state and a desired state
of the software service, wherein the imbalance in the current state
and the desired state may occur in response to at least one of a
service request, a request from a dependent service, global policies,
global management actions, administrative actions, a supporting
service, a supporting physical resource, or a spontaneous change
in a state of the software service.
Software Patent Description
BACKGROUND OF THE INVENTION
[0001]1. Field of the Invention
[0002]The present invention relates generally to networked computer
systems. More particularly, the present invention relates to software
and systems management in networked computer environments.
[0003]2. Description of the Related Art
[0004]Distributed environments such as clusters of computing systems,
data centers, and grid systems involve managing a large number of
resources and service components. Typical end-service provided to
the users of such systems require composition of multiple resources
and service components, which together deliver the end-service that
is of interest to the users. Such composition of multiple components
require careful configuration of the components and deployment of
these components, such that they interface with each other in a
compatible manner so that the composite service is deployed, initialized,
handles the workload submitted by users, handles component level
faults gracefully, and provides robust service while handling fluctuations
in the workload.
[0005]Realizing such composition from components involve orchestration
of a large number of heterogeneous resources and service components.
Managing the various tasks manually tends to be tedious and error
prone. The magnitude of the complexity increases when resources
belong to multiple administrative domains. While grid-based systems
can facilitate resource sharing across multiple administrative domains,
the grid-based systems are much harder to manage from a system administration
point of view. One reason for the harder management is that the
current state-of-the-art in system management technology has not
kept pace with the advances in middleware and grid technologies.
Some progress has been made in managing single or cluster-based
systems. Even for such systems, system administrators face a much
higher level of complexity when they configure and deploy a new
service on an existing infrastructure or manage the lifecycle of
the existing service and software stack. The situation is much worse
in a complex application environment; for example, an environment
involving orchestration of a workflow formed by multiple business
processes. In such a case, deployment and life cycle management
solutions need to take an integrated view of the multiple tiers
involved and current system management technologies do not provide
the necessary means to build such solutions.
[0006]Traditional methods for configuration and deployment of software
components rely heavily upon domain experts' knowledge about the
component requirements, availability of middleware and the underlying
infrastructure, and overall IT environment. Using this background
knowledge, a system administrator is first required to configure
the existing infrastructure and then customize the configuration
and deployment steps for a new component, so the new component can
be deployed successfully. In case of distributed components, such
an approach can be time consuming, error prone, and non-scalable
to large scale installations. Further, such an approach does not
lend itself to automation as system administrators are key components
in the deployment workflow.
[0007]The ability to configure and manage large installations of
systems has been an active area of research within the information
technology community. The Local Configuration (LCFG) is a currently
used script based system that dynamically configures machines based
upon configuration information stored in a central database (Anderson,
P., "Towards a High-Level Machine Configuration System,"
LISA, 1994). The information pertains to network, system and services
that need to be configured on the system. Smart Framework for Object
Groups (SmartFrog) is a known system for specifying the configuration,
and deployment of distributed applications (Goldsack, P., Guijarro,
J., Mecheneau, G., Murray, P., Toft, P., "SmartFrog: Configuration
and Automatic Ignition of Distributed Applications," HP OVUA
2003). SmartFrog provides a language to specify the configuration
of applications and dependencies between them. SmartFrog provides
an infrastructure for processing and deploying applications on the
distributed systems. The GridWeaver project is exploring the notion
of combining LCFG and SmartFrog technologies for configuration management
of large systems. The Organization for the Advancement of Structured
Information Standards (OASIS) effort is looking at managing distributed
resources using Web services. The Grid Forum is attempting to standardize
the specification language as part of the Configuration Description,
Deployment, and Lifecycle Management (CDDLM) activity.
[0008]Some technologies provide means to monitor individual Java.TM.
2 Platform Enterprise Edition (J2EE) components that are participating
in providing a service. The technology helps system administrators
to monitor performance, identify failures, and check performance
bottlenecks.
SUMMARY OF THE INVENTION
[0009]A computer implemented method, data processing system, computer
usable program code, and active repository are provided for management
of a composite software service. The illustrative embodiments receive
a request for using the software service. If the software service
is not yet deployed in the computer network, the illustrative embodiments
configure and deploy a new instance of the software service in the
computer network. If the software service is deployed but is not
adequately configured and provisioned to perform at a level required
by the request, the software service is reconfigured and redeployed.
The illustrative embodiments perform an analysis of other supporting
software services and physical resources needed to deploy the software
service and may reconfigure and/or deploy additional software services
to enable the deployment of the software service.
[0010]To perform these management functions, the illustrative embodiments
create an active object in an active repository to manage the new
software service using an active template based on the analysis.
The illustrative embodiments deploy the new software service in
the computer network using the active object and manage the new
software service throughout its lifecycle using the active object.
The active objects in the active repository interact with one another
while controlling and managing the software services. These interactions
lead to service management actions such that desired service compositions
are realized by the software services and the compositions are maintained
in their desired states.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011]The novel features believed characteristic of the illustrative
embodiments are set forth in the appended claims. The illustrative
embodiments themselves, however, as well as a preferred mode of
use, further objectives and advantages thereof, will best be understood
by reference to the following detailed description of an illustrative
embodiment when read in conjunction with the accompanying drawings,
wherein:
[0012]FIG. 1 depicts a pictorial representation of a network of
data processing systems in which aspects of the illustrative embodiments
may be implemented;
[0013]FIG. 2 depicts a block diagram of a data processing system
in which aspects of the illustrative embodiments may be implemented;
[0014]FIG. 3 depicts a composition based service management infrastructure
using an active repository for configuration and deployment in accordance
with an illustrative embodiment;
[0015]FIG. 4 depicts the components of an active repository in
accordance with an illustrative embodiment;
[0016]FIG. 5 depicts the exemplary functional components and management
interfaces associated with an active object in accordance with an
illustrative embodiment;
[0017]FIG. 6 depicts macro-level controls for managing the composite
services in accordance with an illustrative embodiment; and
[0018]FIG. 7 depicts a flowchart of an operation used to deploy
and manage a software service in accordance with an illustrative
embodiment.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
[0019]The following document uses the term physical resource or
resource to mean a hardware resource such as a computer server,
a computer network, a file system, etc. Such resources may be turned
on or off, shared or used in dedicated mode, and have a physical
location. The term computer service is used to indicate a service
provided by a computer program that runs on top of one or more resources.
[0020]The illustrative embodiments provide a solution to the management
of software components and services. With reference now to the figures
and in particular with reference to FIGS. 1-2, exemplary diagrams
of data processing environments are provided in which embodiments
may be implemented. It should be appreciated that FIGS. 1-2 are
only exemplary and are not intended to assert or imply any limitation
with regard to the environments in which aspects or embodiments
may be implemented. Many modifications to the depicted environments
may be made without departing from the spirit and scope of the illustrative
embodiments.
[0021]With reference now to the figures, FIG. 1 depicts a pictorial
representation of a network of data processing systems in which
aspects of the illustrative embodiments may be implemented. Network
data processing system 100 is a network of computers in which embodiments
may be implemented. Network data processing system 100 contains
network 102, which is the medium used to provide communications
links between various devices and computers connected together within
network data processing system 100. Network 102 may include connections,
such as wire, wireless communication links, or fiber optic cables.
[0022]In the depicted example, server 104 and server 106 connect
to network 102 along with storage unit 108. In addition, clients
110, 112, and 114 connect to network 102. These clients 110, 112,
and 114 may be, for example, personal computers or network computers.
In the depicted example, server 104 provides data, such as boot
files, operating system images, and applications to clients 110,
112, and 114. Clients 110, 112, and 114 are clients to server 104
in this example. Network data processing system 100 may include
additional servers, clients, and other devices not shown.
[0023]In the depicted example, network data processing system 100
is the Internet with network 102 representing a worldwide collection
of networks and gateways that use the Transmission Control Protocol/Internet
Protocol (TCP/IP) suite of protocols to communicate with one another.
At the heart of the Internet is a backbone of high-speed data communication
lines between major nodes or host computers, consisting of thousands
of commercial, governmental, educational and other computer systems
that route data and messages. Of course, network data processing
system 100 also may be implemented as a number of different types
of networks, such as for example, an intranet, a local area network
(LAN), or a wide area network (WAN). FIG. 1 is intended as an example,
and not as an architectural limitation for different embodiments.
[0024]With reference now to FIG. 2, a block diagram of a data processing
system is shown in which aspects of the illustrative embodiments
may be implemented. Data processing system 200 is an example of
a computer, such as server 104 or client 110 in FIG. 1, in which
computer usable code or instructions implementing the processes
for embodiments may be located.
[0025]In the depicted example, data processing system 200 employs
a hub architecture including a north bridge and memory controller
hub (MCH) 202 and a south bridge and input/output (I/O) controller
hub (ICH) 204. Processor 206, main memory 208, and graphics processor
210 are coupled to north bridge and memory controller hub 202. Graphics
processor 210 may be coupled to the MCH through an accelerated graphics
port (AGP), for example.
[0026]In the depicted example, local area network (LAN) adapter
212 is coupled to south bridge and I/O controller hub 204 and audio
adapter 216, keyboard and mouse adapter 220, modem 222, read only
memory (ROM) 224, universal serial bus (USB) ports and other communications
ports 232, and PCI/PCIe devices 234 are coupled to south bridge
and I/O controller hub 204 through bus 238, and hard disk drive
(HDD) 226 and CD-ROM drive 230 are coupled to south bridge and I/O
controller hub 204 through bus 240. PCI/PCIe devices may include,
for example, Ethernet adapters, add-in cards, and PC cards for notebook
computers. PCI uses a card bus controller, while PCIe does not.
ROM 224 may be, for example, a flash binary input/output system
(BIOS). Hard disk drive 226 and CD-ROM drive 230 may use, for example,
an integrated drive electronics (IDE) or serial advanced technology
attachment (SATA) interface. A super I/O (SIO) device 236 may be
coupled to south bridge and I/O controller hub 204.
[0027]An operating system runs on processor 206 and coordinates
and provides control of various components within data processing
system 200 in FIG. 2. The operating system may be a commercially
available operating system such as Microsoft.RTM. Windows.RTM. XP
(Microsoft and Windows are trademarks of Microsoft Corporation in
the United States, other countries, or both). An object oriented
programming system, such as the Java.TM. programming system, may
run in conjunction with the operating system and provides calls
to the operating sy stem from Java programs or applications executing
on data processing system 200 (Java and all Java-based trademarks
are trademarks of Sun Microsystems, Inc. in the United States, other
countries, or both).
[0028]Instructions for the operating system, the object-oriented
programming system, and applications or programs are located on
storage devices, such as hard disk drive 226, and may be loaded
into main memory 208 for execution by processor 206. The processes
of the illustrative embodiments may be performed by processor 206
using computer implemented instructions, which may be located in
a memory such as, for example, main memory 208, read only memory
224, or in one or more peripheral devices.
[0029]The hardware in FIGS. 1-2 may vary depending on the implementation.
Other internal hardware or peripheral devices, such as flash memory,
equivalent non-volatile memory, or optical disk drives and the like,
may be used in addition to or in place of the hardware depicted
in FIGS. 1-2. Also, the processes of the illustrative embodiments
may be applied to a multiprocessor data processing system.
[0030]In some illustrative examples, data processing system 200
may be a personal digital assistant (PDA), which is generally configured
with flash memory to provide non-volatile memory for storing operating
system files and/or user-generated data. A bus system may be comprised
of one or more buses, such as a system bus, an I/O bus and a PCI
bus. Of course the bus system may be implemented using any type
of communications fabric or architecture that provides for a transfer
of data between different components or devices attached to the
fabric or architecture. A communications unit may include one or
more devices used to transmit and receive data, such as a modem
or a network adapter. A memory may be, for example, main memory
208 or a cache such as found in north bridge and memory controller
hub 202. A processing unit may include one or more processors or
CPUs. The depicted examples in FIGS. 1-2 and above-described examples
are not meant to imply architectural limitations. For example, data
processing system 200 also may be a tablet computer, laptop computer,
or telephone device in addition to taking the form of a PDA.
[0031]The aspects of the illustrative embodiments provide for a
computer implemented method, apparatus, and computer usable program
code for compiling source code. The methods of the illustrative
embodiments may be performed in a data processing system, such as
data processing system 100 shown in FIG. 1 or data processing system
200 shown in FIG. 2.
[0032]The illustrative embodiments provide a computer implemented
method, data processing system, computer usable program code and
active repository for the management of software services. A software
service is a service provided by a computer program or a collection
of programs that runs on a local and/or remote computer network,
provides partial or complete solution to a service request, and
does not require the requester to perform any of the management
tasks associated with the service including configuration, deployment,
and life-cycle management tasks. Some examples of a software service
are a payroll service, customer relation service, supply-chain management
service, search engine service, e-mail service, authentication service,
messaging service, a generic application management service such
as the one provided by WebSphere.RTM. Application Server, database
service, network connectivity service, and so on.
[0033]Software service management includes service dependency analysis,
planning and scheduling resources and deployed services, configuration
management, deployment management, and post-deployment lifecycle
management. These management functions are themselves software services.
The illustrative embodiments provide these management services so
that the necessary installation, configuration, and deployment of
software services are performed in a systematic and controlled manner
in response to service requests from users. Further, the embodiments
manage the deployed services so that the services perform at the
level desired by current request workload and/or anticipated future
workloads and these services are taken offline or terminated when
not required or require maintenance.
[0034]The illustrative embodiments provide management services
to maintain the deployed services in a desired state and take corrective
actions when the service state deviates from the desired state.
In response to an alert pertaining to a particular service, the
management services in the embodiments automatically trigger analysis
to determine the cause of the alert, determine if an alternate resource
or supporting service needs to be used, and redeploy the managed
services using alternate resources and/or services. These management
services are scalable, inherently autonomic, and may manage services
for multiple platforms.
[0035]FIG. 3 depicts a composition based service management infrastructure
using an active repository for configuration and deployment in accordance
with an illustrative embodiment. In composition based service management
infrastructure 300, new type of service requests 302 and service
requests of currently supported request types 304 arrive at service
infrastructure manager interface 306. A service request is a request
for service either from (i) an end-user, (ii) another service in
the system, or (iii) another service elsewhere in the network. The
requested service is a service that the system is capable of providing
using one or more software services and physical resources supported
by the system.
[0036]Note that a request may be processed by multiple software
services before completion and all such services need to be made
available by configuring, deploying, and managing at runtime. A
software service may be supported by the system, but the software
service may not be configured and deployed at all times. Even if
the software service is configured and deployed, the software service
may not be configured to fulfill the requirements of the service
request in terms of desired performance and/or the manner in which
the service is to be delivered; e.g., a request may ask for a service
to be delivered in secure or in dedicated service delivery mode.
[0037]New type of service requests 302 consist of requests for
software services, which are currently not configured and deployed
in the system. Service requests of currently supported request types
304 are those requests that are requesting services that are already
configured and deployed in the system. Also, note that the requests,
of new or currently supported types, are serviced by software services
that run on end-point resources 314. Processing of the requests
at service infrastructure manager interface 306 takes place transparent
to the service requesters.
[0038]Administrators may interact with the system for performing
actions, such as setting policies, configuring or reconfiguring
resource states, for configuring and deploying software services
by overriding default settings, etc. using administrator interface
308. Commands issued by administrators are sent via administrator
interface 308 to service infrastructure manager interface 306. At
the backend, service infrastructure manager interface 306 interacts
with orchestration and management services 310 and active repository
312. Active repository 312 consists of active objects and active
templates. The active objects interact with end-point resources
314 or with the software services that run on top of the end-point
resources via end-point management interface 316. In addition, orchestration
and management services 310 also interact with active repository
312. As mentioned earlier, requests are actually processed at end-point
resources 314.
[0039]FIG. 4 depicts the components of an active repository in
accordance with an illustrative embodiment. Active repository 402
may be an active repository, such as active repository 312 of FIG.
3. As described previously, active repository 402 consists of active
templates 404 and active objects 406. An active template is a template
for an active object. An active object is a management object that
is used to manage an instantiated or to be instantiated service
instance, such as one of managed service components 408, using available
resources and other managed service instances. Each physical resource
and service component in the system has a representative active
object in active repository 402. The active object manages that
resource or that service component by performing state and dependency
management, configuration, deployment, and lifecycle management.
For each type of service being managed, there is an active template
in active templates 404 in active repository 402.
[0040]Whenever a new instance of a service is instantiated, a new
active object is also instantiated in active objects 406 from an
active template in active templates 404 that represents the type
of service being instantiated. However, not every active template
in active templates 404 may have an instantiated active object in
active objects 406 at all times.
[0041]As new services are composed and instantiated on top of existing
services and/or physical resources, new active objects are instantiated
in active objects 406. Similarly, when a composite service is no
longer needed, both the composite service and the active object
used to manage that composite service are both terminated. The terminated
active object is garbage collected. In addition, the active objects
within active objects 406 corresponding to the component services
or resources used to support and compose the service being terminated
are all updated to reflect the fact that they are no longer supporting
the composite service. When a component service is no longer needed,
the corresponding active object within active objects 406 is destroyed
and garbage collected, unless the policies dictate otherwise. For
example, a policy may dictate that at least one service instance
be deployed at all times regardless of the current demand on that
service. In such a case all instances of that service, except the
last one, are terminated when there is no demand for that service.
[0042]Active templates 404 are updated as their scope changes or
as the environment controlled by the corresponding active object
within active objects 406 evolves or fixes are to be applied to
active objects 406. New active templates are also introduced into
active templates 404 when new types of resources or services are
introduced in the managed environment. For example, when WebSphere.RTM.
6.0 is introduced in the system as an Enterprise JavaBeans.TM. (EJB)
container service, a new template is introduced in active templates
404. This is done even if an active template for WebSphere.RTM.
5.x existed in the active templates 404. This is because managing
WebSphere.RTM. 6.0 is significantly different than managing WebSphere.RTM.
5.x containers. The active template has information on service being
provided, dependency requirements, configuration and deployment
information for one or more platforms.
[0043]When WebSphere.RTM. 6.01 is to be supported, a new template
is not introduced, but the existing template is updated to accommodate
the differences. The update is performed because the differences
in two release versions are small from the point of view of management.
The active objects derived from the template may manage a WebSphere.RTM.
6.0 container as well as a WebSphere.RTM. 6.01 container. Similarly,
if initially WebSphere.RTM. 6.0 is to be deployed only on Linux.RTM.
platforms, the template for WebSphere.RTM. 6.0 has the information
for managing the container on Linux.RTM. platforms only. If later,
WebSphere.RTM. 6.0 is to be deployed and supported on Windows.RTM.
platforms as well, the template for WebSphere.RTM. 6.0 needs to
be updated to add this capability, which is an example of changing
the scope of a template.
[0044]Each active object in active objects 406 in active repository
402 is programmed to manage a particular resource or a service component
to deliver component specific service by achieving a desired state.
A desired state is the state required to achieve a desired effect
or behavior from the actual service instance managed by the active
object. Each active object in active objects 406 is aware of the
current state and the desired state of the managed resource or service
component for which it has management responsibilities. The desired
state of an active object may be influenced by system administrators,
policy managers, or other objects in the system. Active repository
402 provides facilities for performing lookup, service/resource
brokering, for creating group memberships, setting policies, and
so on.
[0045]The controls for configuration and deployment are executed
at two levels: one is at micro-level and the other is at macro-level.
The micro-level controls operate at the level of service template
and service instance objects. Overall controls necessary to orchestrate
multiple services in support of one or more higher level services
are facilitated by the macro-level controls. The macro-level controls
allow management services to orchestrate actions such as federated
service configuration and deployment in a consistent manner. The
macro-level system controls are built on top of and by leveraging
the micro-level system controls.
[0046]All planning related logic such as for dependency resolution
and sharing of supporting services is encapsulated in active objects
406. This logic is dynamically updatable and plug-ins may be inserted
to add functionality that did not exist before.
[0047]Each of active objects 406 has four functional components
for managing the service the active object represents in the active
repository. The four management functional components in the illustrative
examples are: monitor, analyze, configure, and execute (MACE). These
are shown in FIG. 5.
[0048]FIG. 5 depicts the exemplary functional components and management
interfaces associated with an active object in accordance with an
illustrative embodiment. An active object is an active object such
as one of active objects 406 of FIG. 4. In these examples, monitoring
functional component 502 monitors the following entities: [0049](1)
state of the managed service; [0050](2) state of the services that
the managed service component depends upon; i.e., the state of the
service components that provide support to the managed service (if
any); [0051](3) state of service components supported by the managed
component, i.e., the state of the service components dependent on
the managed service component (if any); and [0052](4) administrative
input.
[0053]Analyze functional component 504 provides the decision making
capability to an active object. It is triggered into action by one
of the following events: [0054](1) imbalances in the observed and
desired state of the managed object; [0055](2) imbalances in the
functionality and service levels provided by the supporting components;
and [0056](3) imbalances in the functionality and the service levels
demanded by the components supported by this component.
[0057]Any of the above imbalances can occur because of changes
either (i) in the current state or (ii) in the desired state. For
example, consider a WebSphere.RTM. Application Server that is installed
on a server, but currently not launched. The current state of this
Application Server is "Off line." If the desired state
is set to "On line" with certain attributes (such as buffer
sizes, number of requests to handle, connections to a particular
database, etc.) this results in an imbalance that triggers the analyze
component in corresponding active object. After it is made "On
line" with the desired attributes, suppose that the current
state changes to "On line" and "Lost connection to
database." Again this results in an imbalance that triggers
the analyze component into action. Changes in the current state
are notified via the monitoring functional component 502. Changes
in the desired state are brought about either by (i) the orchestration
and management services or (ii) administrative actions via the administrative
interface, or (iii) a request for service from another active object
that requires action under the existing policies.
[0058]When analyze functional component 504 recognizes that there
is an imbalance between the current and the desired state of the
managed object, it performs an analysis to establishes an optimal
configurable state to which the managed service can be transformed
to. To perform this analysis, it takes into account the state and
the availability of other services and resources in the system,
as well as the demands and the priorities of the current and to
be supported service components or workload. At the end of this
analysis step the supporting resources and software services are
completely determined and the parameters characterizing the support
are finalized (e.g., number of connections, port number, expected
response time, minimum guaranteed bandwidth etc.). Similarly, the
characteristics of the supported services are also finalized.
[0059]The complexity and nature of the analysis depends on the
decision choices available to the analyze functional component 504.
The desired state may be specified with a high degree of precision
(e.g., "On line" Websphere.RTM. instance of specific version,
release, patch level, on a specific server with specific network
adapters enabled, with specific IP addresses, and specific Web services
deployed in a specific manner). In such cases, where there are no
choices, the analyze component identifies the resources and services
to use and configuration parameters to apply to the supporting services
so that the managed service can achieve the desired state as prescribed.
[0060]On the other hand, the desired state may be specified with
a range of possible states or with some degree of freedom (e.g.,
"On line" Websphere.RTM. instance that is version 6.0
compatible, on any of the servers in a particular network sub-domain,
or the desired state of application server may be set to "On
line" with no constraints on the server on which it is to be
launched and thus, it could be the first available server or the
constraint may require using a server with the largest amount of
memory from a set of servers). When there are choices in selecting
and configuring the supporting services and resources, analyze functional
component 504 makes the decisions by interacting with other active
templates and/or active objects.
[0061]This is accomplished by formulating and solving an optimization
problem based on the available capacities and performance levels
and the demands on those by existing and new services being considered
for configuration and deployment. The objectives of the optimization
problem are governed by the policies associated with the managed
object. Some examples of policies associated with a managed service
are exclusive use of the service by certain user groups at specified
time periods, time set aside for maintenance purposes, preferred
resource instances to use as support resources, and so on.
[0062]Analyze functional component 504 takes these policies into
account and tries to resolve as many imbalances in the system as
possible. If imbalances cannot be completely eliminated, analyze
functional component 504 tries to satisfy the dependencies such
that the achievable new state is closest to its desired state and
a transition is possible from the current state to this new state.
The outcome of this analysis determines the actual supporting services
and resources to be used to correct the imbalances in the system.
Since the state of these supporting services and resources determines
the ultimate state to which the managed service may be transformed
to, the managed service may not always realize the actual desired
state but may realize a suboptimal state. Depending on how far that
realized state is from the desired state, the analysis and the subsequent
configuration and deployment steps may repeat.
[0063]Configure functional component 506 takes the output from
analyze functional component 504 and performs the following tasks:
[0064](1) create a plan of action to configure or to reconfigure
the existing state of the managed service component so the managed
service component may transition from its current state to the new
state in an optimal manner; [0065](2) determine the actual commands,
scripts, and procedures to run to bring the actual changes in the
component; and [0066](3) send request messages to the supporting
service components before self configuration and send confirmation
messages to the dependent service after the configuration changes
are in place.
[0067]Execute functional component 508 performs the following tasks:
[0068](1) execution of the plan of actions determined by configure
functional component 506 so that risks of failure are managed according
to policies; [0069](2) execution of verification steps to confirm
that the desired changes have taken place; [0070](3) execution of
alternative action plans when initial plans do not succeed; and
[0071](4) verification of interactions with supporting and dependent
components after the configuration changes are in place.
[0072]The encapsulation of the MACE function within each active
object enables the corresponding managed software service to evolve
independently and concurrently with other services and to adapt
to the dynamic changes taking place in the system. Unlike prior-art
in this area, these illustrative embodiments do not require a completely
centralized evaluation of the service components to manage those
components. The system described here allows for global policies
to dictate the overall management of the system without requiring
centralized decision making and execution capability. Whenever an
active object needs to manipulate the managed object, the active
object triggers a system runtime. The system runtime merely examines
the state of the active object and performs actions contained in
the active object. Some of these actions operate on the managed
service and others on other active objects in the repository.
[0073]For example, an active object may issue a command asking
the managed object to "go offline." In another instance,
it may send a notification to another active object indicating that
the support services are no longer needed from the service managed
by the notified active object. The state of the active object may
be affected by the external events such as resource monitors, service
monitors, and other higher level active objects requesting management
actions. When an event changes the state of the active object, the
management components described earlier are activated and the active
object starts to steer the managed service to a more stable state.
[0074]Each active object in an active repository is associated
with management interfaces to monitor and control the behavior of
the managed resources or services. Exemplary management interfaces
provided by an active object, such as one of active objects 406
of FIG. 4 are shown in FIG. 5. The exemplary functional components,
described earlier, of an active object perform their management
actions over the managed object using the exemplary management interfaces.
Such management actions are referred to as micro-level controls
since the actions resulting from these controls affect individual
end-point resources and software service instance. Exemplary management
interfaces are as follows: [0075](1) Service specification 510;
[0076](2) Dependency requirements 512; [0077](3) Service configuration
514; [0078](4) Service deployment 516; [0079](5) Service state 518;
and [0080](6) Lifecycle management 520.
[0081]Active objects inherit these management interfaces from the
active template from which the active object was instantiated in
the first place. In the active templates the management interfaces
are represented in a more generic manner covering multiple possible
configurations and deployment and lifecycle management procedures.
[0082]Service specification 510 identifies the functionalities
provided by a service. The service functionality includes both the
actual physical value delivered to the client and the manner in
which the actual physical value is delivered. The functions provided
by a service may depend on the manner in which the service is configured
and deployed. For example, a stock-quote service may be deployed
to provide real-time quotes or delayed quotes. Similarly, a document
delivery service may be configured to deliver encrypted or unencrypted
documents. In a service template object, all available functions
are listed. A service instance object lists the specific functions
selected and those that are currently enabled in that instance.
[0083]Dependency requirements 512 has two parts: [0084](a) requirements
on dependent services; and [0085](b) requirements on depending services.
[0086]The first part of dependency requirements 512 describes the
dependency requirements for making the service available. In a service
template object, dependencies are listed for each function the service
is capable of delivering. In a service instance object, dependencies
are listed only for the functions enabled in that instance. In addition
to the resource dependencies (e.g., requires a server with at least
two CPUs and Red Hat.RTM. Linux.RTM. Enterprise AS Release 3 OS),
the dependency information also includes both the spatial (e.g.,
a service may depend on a database and a file system and these need
to be available on the same subnet where the service is deployed)
and temporal dependencies (e.g., a backup service may depend on
access to high bandwidth network from 2 AM to 3 AM on each Friday).
[0087]The second part of dependency requirements 512 describes
the requirements imposed on the services that depend on this service.
This part is meaningful only for services that are not deployed
as high-level services. A high-level service is one that does not
support any other service in the system, but may process end-user
requests. Some of these requirements are static (e.g., dependent
on the software version), some are semi-static (e.g., dependent
on the service functions enabled), and still some others may be
dynamic (e.g., depending on the quality of service delivered by
its supporting services, a service may adjust the requirements the
service imposes on the services that the service supports). In an
active object, the dependency requirements are exposed only for
the functions enabled in service specification interface 510.
[0088]Service configuration 514 has three parts: [0089](a) configuration
of supporting services; [0090](b) configuration of the managed service
instance; and [0091](c) configuration of supported services.
[0092]The first part of service configuration 514 manages information
on configuring supporting services so that this service instance
may be deployed on top of the supporting services. A versatile service
should be able to run on top of a large variety of supporting services
that provide similar functionality. For example, if service can
be deployed on server with AIX.RTM. operating system, then its range
of operation is limited. But if the service can run on any flavor
of Unix.RTM., then the services' range of operation is larger. The
service is even larger, if the service may also be deployed on servers
within the Windows.RTM. operating system.
[0093]However, as the range of acceptable supporting services grows,
the choices and associated deployment steps may become very complex
(in addition to managing multiple software packages). That complexity
is managed by the first part of service configuration 514. For each
acceptable type of supporting service, service configuration 514
maintains specific information on the parameters to be set and the
initialization steps to be performed (e.g., specific user and group
ids may need to be created prior to executing an installation step,
database tables may need to be initialized according to certain
schema, a specific file system may need to be mounted, and so on).
[0094]The second part of service configuration 514 manages information
on configuring the managed service instance given a set of supporting
services that meet the dependency requirements. Service configuration
514 also takes into account the specific service functionality to
be enabled (as described in the service specification section) and
manages the configuration steps such that only the selected service
functionality is enabled.
[0095]The third part of service configuration 514 manages the manner
in which the dependent services are to be configured. For example,
service configuration 514 may provide a plug-in so a client may
interact with service configuration 514 in a specific manner, or
listen on specific port so a dependent service may send requests,
or publish information using a client specific topic on pub-sub
messaging network, and so on.
[0096]Service deployment 516 manages the deployment of a service
instance given a specific configuration of supporting services,
the service functionality to be enabled, and the higher-level services
to be supported. Service deployment 516 consists of three parts:
[0097](a) deployment actions; [0098](b) verification and integration
tests; and [0099](c) recovery actions.
[0100]This section manages the actions based on the configuration
specified in service configuration 514. Verification and integration
tests are provided to manage complex deployment steps in an incremental
manner. Service deployment 516 also incorporates recovery actions
in case of failures during the verification and integration tests.
[0101]Service state 518 has three parts: [0102](a) state of the
service delivered; [0103](b) state of the supporting services; and
[0104](c) state of the supported services.
[0105]The first part of service state 518 lists the service functions
selected and enabled. For each one, service state 518 describes
the observed and expected performance ranges. The second part of
service state 518 lists the actual service instances selected to
support this service. Service state 518 also describes current usage
of each supporting service instance by this service, service level
agreements with each service instance, and any violations. It also
describes various attributes of the current state e.g., it may state
that the service is deployed in dedicated mode or in shared mode
and may point to corresponding policies or business rules. Similarly,
the third part of service state 518 lists the actual service instances
supported by this service instance, demand placed by those service
instances, and current usage by the supported services. Service
state 518 also lists any service level agreements with the supported
services and any violations.
[0106]Lifecycle management 520 has three parts: [0107](a) management
of the service lifecycle; [0108](b) management of the lifecycle
of the software package used to deploy the service; and [0109](c)
management of the lifecycle of the service management layer.
[0110]In the first part of lifecycle management 520, management
of the service lifecycle is primarily concerned with "start,"
"stop," "pause," and "restart" type
of lifecycle events on the service instance. In the second part
of lifecycle management 520, the software lifecycle management is
concerned with the location of the software package, actions and
permissions for accessing the software package, software versioning,
upgrade, and patch management. In the third part of lifecycle management
520, the lifecycle of the service management layer itself is managed.
This allows the service management layer to evolve or to terminate
if a particular service is to be eliminated entirely.
[0111]The activities within an active object leading to analyses
and subsequent actions are driven by the state imbalances observed
at the level of individual active objects. Decisions made at the
analyze functional component 504 of an active object are local taking
into account information available to the active object and policies
applicable to active object only. The decisions do not take into
account global policies or tradeoffs. For example, if an active
object discovers that it has a choice of using one of two groups
of supporting services that are functionally equivalent, but differ
in performance, it may select one group based on local requirements
using local criteria and policies without taking into account current
or future needs of other services. Multiple active objects are simultaneously
active and analyze functional components of multiple active objects
are continuously trying to optimize the state of the services they
manage, within their operational constraints. In the following,
these dynamics are explained in the context of a deployment of a
new service instance in response to a request for that type of service.
[0112]When a request for service cannot be served using an existing
service or service composite, the active template representing the
type of service requested is notified. In turn, that template evaluates
the request and either instantiates a new active object to manage
a new instance of that service or instructs an existing active object
to reconfigure the managed object to accommodate the new request.
The instructions for reconfiguration are performed simply by changing
the desired state of the managed service. The actions followed in
such a case are a subset of the actions followed when a new active
object is created. In the following, the set of actions performed
by a newly instantiated active object are described. These set of
actions lead to composing and deploying a composite service from
component services by recursively traversing down the dependency
tree and then building up the component service tree until the entire
composite service is fully configured and deployed.
[0113]At creation in the active repository, the immediate dependencies
of an active object are known but are unsatisfied. When an active
object is instantiated in active repository, the active object is
assigned a state called a desired state and another state called
the current state. The current state is the state of the service
or resource managed by the active object. The desired state is the
expected state of the managed service or resource.
[0114]Analyze functional component 504 in the active object continuously
monitors the two states. If the two states do not match, analyze
functional component 504 analyzes possible alternatives for transforming
the current state to the desired state and determines if there are
any dependency requirements that must be fulfilled to achieve the
desired state. Thus, if the current state is "off line"
and the desired state is "on line" at the time when an
active object is instantiated, analyze functional component 504
in the active object examines the dependencies that need to be satisfied
to make the managed service or resource go "on line."
The dependency information is stored in dependency requirements
512 interface, which is one of the six management interfaces for
the managed object. Each dependency is expressed in terms of the
type of service or resource required. The dependency analysis identifies
specific types of services or resources needed to transform the
current state to the desired sate. In addition, analyze functional
component 504 also determines the performance and any location constraints
on the other services/resources required to satisfy the dependencies.
This is a function of the desired state.
[0115]For example, if the desired state of a Web service requires
processing m transactions per minute (value of m is known at this
point), analyze functional component 504 first determines that the
Web service would depend on a database service and then it quantifies
the characteristics of the database service that can meet the performance
requirements. Since the database services are characterized by the
speed with which they can read and update database records, analyze
functional component 504 computes the minimum read and update speeds
of a database service that would qualify it as an eligible supporting
service. In other words, analyze functional component 504 computes
a set of performance constraints on the supporting database service.
The relation between m, u, and r may be expressed by a simple algebraic
formula or may require evaluation of a polynomial equation representing
the approximate behavior of a database system.
[0116]The performance specific characteristics for determining
the level of performance from supporting services needed to achieve
a certain desired state are encoded in dependency requirements 512
interface. Note that analyze functional component 504 does not identify
the exact instance of the managing service or resource to be used
to satisfy a particular dependency. Analyze functional component
504 only quantifies the type of management service or resource needed
and the performance, location, and security constraints on the supporting
components. The information on the desired state, dependencies to
be satisfied to arrive at that state, and constraints on the managing
services or resources is then handed over to configure functional
component 506.
[0117]Configure functional component 506 determines the actual
components and the portions of their capacities to be used to fulfill
the dependencies. To make this determination, for each unsatisfied
dependency, configure functional component 506 contacts the active
template representing the type of managing service or resource needed
to satisfy that dependency. To each such active template, configure
functional component 506 sends a request for the type of service
it is looking for and associated constraints that must be met. Each
such active template tries to fulfill the request in one of three
ways: (i) assign an existing managing service or resource to provide
the necessary support, (ii) reconfigure the existing service to
accommodate the new demand, or (iii) configure and deploy a new
service instance to provide the necessary support. When none of
these alternatives are possible, configure functional component
506 sends back a negative confirmation. When it is possible to provide
the support, configure functional component 506 sends back the address
of the corresponding active object that manages the supporting service.
Note that the performance constraints on the dependencies may be
expressed as an acceptable range. In this case, the identified supporting
service expected to deliver service in that range. Policies also
play a role here. A policy may specify conditions when the constraints
may be relaxed and may specify the extent to which they may be relaxed.
The supporting active templates take these policies into account
when making their decisions.
[0118]The steps followed at each supporting active template are
identical to the steps described above in the context of the original
request that triggered actions at the active object. These steps
are followed recursively until either all the dependencies are resolved
or it is determined that they cannot be resolved given a set of
system resources and with the current set of policies. Thus, the
entire dependency tree for providing support to any service component
is traversed top-down from active templates to active objects to
the supporting active templates and so on. The dependency tree of
the actual services is built in a bottom up manner by following
a concurrent depth-first traversal of the dependency graph.
[0119]Once the supporting services are configured and deployed
in a state ready to provide the necessary support, the requesting
active object is notified with a positive confirmation along with
the specifics of the active objects managing the supporting services.
At this point, all the managing service or resource components and
their current configurations, including their available capacities,
are known at for each node in the dependency graph. Using this information,
configure functional component 506 quantifies the actual parameters
to use in configuring the service on top of the supporting services.
The parameters may include, IP addresses, communication ports to
use, user ids, and passwords with access permissions to the supporting
services, buffer sizes, and so on. These details depend on the type
of service. This configuration information is then passed to execute
functional component 508.
[0120]Execute functional component 508 executes setup and installation
procedures and sends commands so that the managed service is instantiated
in its desired state on top of the supporting services. The commands
and procedures to be followed are stored in service deployment 516
interface of the active object. This completes the deployment of
the service as a composition of component services. Following this,
the user requests are processed or other higher-level services are
composed on top of such a service composite.
[0121]As noted earlier, the entire process of determining the dependency
tree from by the component services is traversed dynamically via
the active templates and active objects in the active repository.
The actual service components represented by the nodes in the dependency
graph are configured and deployed in a bottom up manner by following
a concurrent depth-first traversal of the dependency graph.
[0122]If the actual components are already deployed, but the actual
components need to be reconfigured, the corresponding active object
invokes specific actions to bring about the desired configuration
changes in the component. Once a component is configured and deployed
and its performance is satisfactory, the active object at the higher
level in the dependency graph is notified. The next level object
configures and deploys the actual component once all its supporting
components are known to be ready and functional. This continues
until all components, including the high-level service component
are configured, deployed, and brought to the service delivery state.
[0123]Thus, at the micro-level, active objects control the active
service instances they are responsible to manage. In doing so, they
also influence the behavior of the supporting and supported service
or resource instances. Moreover, they respond to the changes in
the behavior of the supported and the supporting resources. However,
the micro-level controls do not bring about simultaneous global
changes that take global constraints and policies into account.
Such changes are brought about by the macro-level controls. Macro-level
controls are needed to enforce global policies such as manner in
which critical resources are to be shared, manner in which demand
is to be prioritized and served, and so on. Such policies are necessary
when there are scarce resources and demand may exceed supply. The
policies are also necessary when complex decisions are to be made
and the tradeoffs are not clear-cut.
[0124]A novelty of this illustrative embodiment is that it enables
combining global control mechanisms with the local micro-level management
controls.
[0125]FIG. 6 depicts macro-level controls for managing the composite
services in accordance with an illustrative embodiment. Orchestration
and management services 600 are orchestration and management services,
such as orchestration and management services 310 of FIG. 3. Orchestration
and management services 600 consist of management services that
provide macro-level controls for managing the composite services.
Orchestration and management services 600 are provided by the analysis
and planning engine 602, configuration engine 604, deployment engine
606, monitoring engine 608, and lifecycle engine 610. Each of these
engines interacts with active repository 612 and the management
objects represented in the active repository 612.
[0126]As mentioned earlier, the analysis and subsequent actions
within an active object is driven by the desired state of the managed
service instance alone. However, critical services and resources
may require global considerations in deciding allocations, sharing,
and scheduling of such services and resources. In such cases, the
analysis and planning engine 602 performs the arbitration and decisions
on allocations, sharing, and scheduling. These decisions then determine
the desired states of one or more active objects. Similarly, global
configuration and deployment considerations result in scheduling
steps at the micro-level for one or more active objects in the active
repository, such as active repository 312 of FIG. 3. Thus, the macro-level
controls provided by the five engines shown in FIG. 6 are transformed
into micro-controls. Active objects in active repository 612 control
the corresponding resource and component services so that the desired
effects of the macro controls are realized at the micro-level.
[0127]As stated earlier, an active repository manages all life-cycle
aspects of software service components so as to deliver solutions
in response to service requests. The active repository performs
this function taking into account related system management policies
as well constraints placed by the availability of physical resources.
One aspect of this life-cycle management is the composition of a
complex service whenever there is a demand for such a service. Another
aspect is the tearing down or decomposition of a complex service
when there is no demand, or policies require such an action, or
one or more supporting services are unavailable.
[0128]As an illustrative example, FIG. 7 depicts a flowchart of
an operation used to deploy and manage a software service in accordance
with an illustrative embodiment. As the operation begins, a request
is received to deploy a software service in a computer network (step
702). If the requested software service is a new software service,
the existing active templates and active objects in the active repository,
such as active repository 312 of FIG. 3, perform an analysis of
physical resources associated with the requested software service
to be managed and a current set of software services using these
resources (step 704).
[0129]A new software service is a service that is not currently
managed by an existing active object. Following this analysis, the
active template representing the type of the new service to be created,
first instantiates an active object in the active repository (step
706). This active object manages the new software service. The active
repository deploys the software service in the network using the
active object (step 708) and the active object manages the software
service (step 710) with the operation ending thereafter. The actual
deployment of the software service is performed using methods described
in related applications. After the active object is created, the
active object manages the software service as described with relation
to FIG. 5.
[0130]If the requested software is an existing software service,
the active repository identifies an existing active object that
manages the existing software service. The existing software service
is deployed in the network using the existing active object and
managed using the existing active object.
[0131]Thus, the illustrative embodiments receive a request for
service. If the requested service is currently not deployed, the
embodiment, responsive to the requested software service being a
new software service, perform an analysis of physical resources
and other component software services required to configure and
deploy the requested software service to be managed so it can serve
this request and other similar requests. These steps may result
in identifying other component software services that may need to
be configured or reconfigured and deployed or redeployed. The illustrative
embodiments perform the necessary actions so the requested service
can be made available as a composition of one or more managed service
components to process the request.
[0132]The illustrative embodiments also respond to requests for
services that are currently deployed but not configured in a form
desired for processing the request. The illustrative embodiments
takes actions by reconfiguring and/or redeploying one or more service
components and resources so the requested service can be deployed
with the desired configuration. The illustrative embodiments create
an active object to manage the new software service using an active
template based on the analysis. Finally, the illustrative embodiments
deploy the new software service in the network using the active
object and manage the new software service using the active object.
The active objects in the active repository interact with one another
while controlling and managing the software services. These interactions
lead to service management actions such that desired service compositions
are realized by the component software services and the compositions
are maintained in their desired states.
[0133]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, etc.
[0134]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. For the purposes of
this description, a computer-usable or computer readable medium
can be any tangible 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.
[0135]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.
[0136]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.
[0137]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.
[0138]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.
[0139]The description of the present invention has been presented
for purposes of illustration and description, and is not intended
to be exhaustive or limited to the invention in the form disclosed.
Many modifications and variations will be apparent to those of ordinary
skill in the art. The embodiment was chosen and described in order
to best explain the principles of the invention, the practical application,
and to enable others of ordinary skill in the art to understand
the invention for various embodiments with various modifications
as are suited to the particular use contemplated. |