Method, device, and program storage device for autonomous software life cycle management

A method of searching for and installing a software product on a device is provided. One or more capabilities needed by the device to be served by a software product are determined. The one or more capabilities needed by the device are communicated from a software life cycle management agent on the device to a yellow pages agent outside the device, the communicating comprising formulating a request comprising a list of the capabilities encoded in a description language that defines the capabilities semantically. Then locations of one or more software products matching the one or more capabilities needed by the device may be received from the yellow pages agent. One of the one or more software products to install may be selected based on automatically evaluated criteria. Then the selected software product may be downloaded using its received location, and the selected software product may be installed on the device.

TECHNICAL FIELD

This application relates generally to software development and testing. More particularly, this application relates to an agent for autonomous software life cycle management.

BACKGROUND

Software life cycle management refers to the governance, development, and maintenance of computer software. Specifically, it typically encompasses requirements management, software architecture, computer programming, software testing, software management, change management, product management, and release management. The “life cycle” referred to involves the complete life of a software product, from design stages to distribution and release to maintenance.

While certain aspects of software life cycle management have been automated, it is still a largely manual process. For example, when testing computer software, a developer may utilize testing tools to help create test scenarios for the software, but the decisions as to which environments and configurations/settings to test are determined by a human. Furthermore, while tools exist to aid in update management, such as an automated tool that checks for an updated version of a software product every time the software product is run, such update management tools are limited in that they are only able to make a determination as to whether to update one particular software product with a newer version of the same software product. They are unable to, for example, determine when a different software product may be appropriate based on changed needs and/or changed capabilities of various software products.

DETAILED DESCRIPTION

Overview

In an example embodiment, an autonomous software life cycle management agent is provided with the technical effect of enabling the self-testing, self-healing, self-reporting, and self-configuration of a software product. Working through an autonomous agent on a device, the device is able to self-describe its needs to software providers. Upon getting informed about available software that addresses the described needs of the device, the device is able to download software (either immediately or scheduled for a later time). The device is also able to automatically test software features in a sandbox and make a decision as to whether to install the software. If such as decision is affirmative, then the device is able to self-install the software. A sandbox is a testing environment that isolates untested code changes and experimentation from a production environment or repository. Sandboxes typically replicate at least the minimal functionality needed to accurately test the programs or other code under development (e.g., usage of the same environment variables as, or access to an identical database to be used by, the stable prior implementation intended to be modified).

Traditionally software life cycle management is performed by a human user manually downloading software, installing it on a device (either a target device or a replica device), testing the software and then pushing the software to target devices. This approach is time consuming, error prone, and costly. In an example embodiment, the autonomous software life cycle management agent described herein reduces these drawbacks. It is able to perform its functions with limited or no human supervision, which avoids human errors, reduces the costs associated with utilizing human resources, and eliminates infrastructure needed to log information of all the assets. In another example embodiment, there are also minimal disruptions to the device/user operations, as devices decide for themselves an appropriate time to perform software life cycle management, and whether it is beneficial to even perform the life cycle operations. Additionally, in an example embodiment, new software is tested on the actual device it is intended for and not a replica device. Further, software is tested in an isolated environment, so if errors are encountered, there is no need to perform any rollbacks.

In an example embodiment, an autonomous software life cycle agent is provided that searches for a service or software that fulfills certain needs. The needs may be described in a semantic language. The software/service provider may or may not be known to the device. Indeed, the name of the software/service may not even be known to the device. Rather, the autonomous software life cycle agent may simply know what it wants the software/service to do.

In an example embodiment, an autonomous software life cycle agent is provided that searches for an update based on an updated set of capabilities, rather than on a strict “is there a newer version to this particular software product”-basis. It is not the currently installed software that is performing the search, it is the autonomous software life cycle agent. This allows for the possibility that the most appropriate update to a software product is actually to switch to a competitor's product. This also allows for factors other than the availability of a new software version to affect a decision as to whether or not to upgrade or switch to new software. Such factors may include, for example, a hardware upgrade specifying a new set of capabilities on the part of the software product.

In an example embodiment, the autonomous software life cycle agent is also able to get informed about updated versions by receiving an indication of updated capabilities of software. This allows for a scenario where, for example, the device was looking for capabilities for which it couldn't find a good match and settled on a software product with limited capabilities, while the autonomous software life cycle agent causes instructions to be indicated to one or more servers to inform the autonomous software life cycle agent when a software/service with the desired capabilities becomes available.

There may be instances where more than one software product may be suitable for meeting the needs of the device as described by the autonomous software life cycle agent. In an example embodiment, the autonomous software life cycle agent is then able to make a choice among the multiple matches, based on capabilities desired and constraints imposed.

In an example embodiment, a technical effect is that the autonomous software life cycle agent is able to make a decision as to whether or not it is beneficial to upgrade to a new version of a software product/service and/or switch to a different software product/service. This decision may be based on many factors, including, for example, upgraded features, service provider credibility, resources needed to run the updated version, and cost.

In another example embodiment, the autonomous software life cycle agent is able to interact with a test bed and evaluate test results to make a decision as to whether or not to trust the software, which ultimately affects the autonomous software life cycle agent's decision as to whether to install the software product.

FIG. 1is a block diagram illustrating a system100in accordance with an example embodiment. The system100includes a device102on which a software product may be executed. The device102may include a software inventory database104where one or more software product installed on the device102may be stored. A software life cycle management agent106may act to locate appropriate software for download, testing, and possible installation on the device102. An autonomy agent108may act as a manager in the device102to define and execute various goals for the device102.

Based on instructions from the autonomy agent108, the software life cycle management agent106may act to query or subscribe to a device community110for information about available software. The device community110may include a yellow pages agent112. A yellow pages agent is a module or component that organizes information (in this case available software) based on category and/or capability. The device community110may also include a white pages agent114. A white pages agent is a module or component that organizes information (in this case available software) based on title or other identification.

The software products and/or new versions that are capable of being downloaded may be hosted on a software hosting server116. A software provider118may upload the software products and/or new versions to the software hosting server116. In an example embodiment, the software provider118may also provide a detailed listing of the capabilities/functionality of the software product/new version when it is uploaded. This detailed listing may take the form of a software metadata file that accompanies the software product.

In an example embodiment, the software hosting server116may advertise the availability of the software product/new version. This may be performed by a software advertising agent120, which may maintain a list of subscriptions of various software life cycle management agents, including, for example, software life cycle management agent106.

In an example embodiment, communication between the software life cycle management agent106and the device community110and/or software hosting server116may be performed via the Message Transport Service (MTS). MTS may provide a protocol that allows software product capabilities and/or device requirements to be described semantically. This means that, for example, a list of the capabilities and/or device requirements is encoded in a description language that defines the capabilities semantically. For example, if a desired capability is the ability to edit text on a computer display, this characteristic may be defined by the description language as a possible value for a variable of the description language. The communication itself may take a number of forms.

As described earlier, the software advertising agent120may advertise new software products and/or new versions of existing software products. This may include, for example, communicating capabilities of the new software products and/or new versions of existing software products to the software life cycle management agent106, which may have previously subscribed to receive such advertisements. The subscriptions may either be general (e.g., “send me information about any new software you receive”) or specific (e.g., “send me information about new versions of software X,” “send me information about new software products having the following capabilities . . . ”).

Additionally, the software life cycle management agent106may generate direct queries to the yellow pages agent112and/or white pages agent114to proactively locate software products meeting various requests and/or requirements of the device102. The yellow pages agent112and/or white pages agent114may send results to the software life cycle management agent106in the form of locations of one or more software products on the software hosting server116. The software life cycle management agent106may then utilize this location information to initiate a download of appropriate software products. It should be noted that while a single software hosting server116is depicted inFIG. 1, in some example embodiments there may be a plurality of different software hosting servers and the yellow pages agent112and/or white pages agent114may provide the location of not just where a particular software product can be found within a single software hosting server, but also a location of the software hosting server hosting the software product (as well as any other instructions needed by the software life cycle management agent106to download the software product).

In some example embodiments, the yellow pages agent112and/or white pages agent114may provide information about a software product to the software life cycle management agent106. This information may include a name of the software product and additional details about the software product (e.g., manufacturer, version number, date of creation). In another example embodiment, the software life cycle management agent106is never informed of information about the software product other than its location and/or information needed to download the software product. In other words, the device102may be kept in the dark as to what the software product is, and instead rely on the device community110to provide an appropriate software product that matches the desired capabilities. This same anonymity may also be extended in the other direction: namely, the software hosting server116may not be made aware of the device102and/or any characteristics of the device102.

Once the software product/version is selected by the software life cycle management agent106and downloaded, it may be run in a sandbox122on the device102. Execution of the software product/version in the sandbox122allows it to be tested on the device102without causing any runtime or other issues or errors in the device102. The testing may be performed by a software testing agent124, which may be instructed to perform the testing by the software life cycle management agent106and then may inform the software life cycle management agent106of the results of the tests. The software life cycle management agent106can then make a decision as to whether or not to install the software product/version based on the results of the testing.

In an example embodiment, installation and use of the software product/version may be performed using an Open Service Gateway Initiative (OSGi) container. OSGI is a specification that describes a modular system and service platform for the Java description language that implements a dynamic component mode. Applications or components, in the form of bundles for deployment, can be remotely installed, started, stopped, updated, and uninstalled without requiring a reboot. The OSGi container126for a software product/version can describe all that is needed in order to successfully install the software product/version.

In an example embodiment, the architecture described above is implemented on top of a Java Agent Development Framework (JADE). Additionally, an agent communication language (ACL) may be provided to enable the communications between the various agents, including the software life cycle management agent106, autonomy agent108, yellow pages agent112, white pages agent114, software advertising agent120and software testing agent124.

It should be noted that the software life cycle management agent106and autonomy agent108work together to operate the various functions of coordinating the determination to search/subscribe to new software products and/or versions, coordinate the testing of the new software products and/or versions, and decide ultimately which software products and/or version to install on the device102. In various example embodiments, the precise functionality performed by each of the software life cycle management agent106and autonomy agent108may differ, and nothing in this disclosure shall be interpreted as limiting the functionality to only being performed by one or the other.

FIG. 2is a flow diagram illustrating a method200, in accordance with an example embodiment, for searching for and installing a software product on a device in accordance with an example embodiment. At operation202, a list of needed capabilities of the device (e.g., device102ofFIG. 1) is prepared. In an example embodiment, this list may be prepared by an autonomy agent operating on the device. The autonomy agent may perform an analysis of the device including, for example, hardware capabilities of the device, operating system installed on the device, additional software installed on the device, settings configured by a user of the device, etc. The autonomy agent may also take into account additional factors such as specified desires by a user or users of the device (e.g., an indicated desire to obtain a word processing program) as well as various dynamically determined characteristics such as device location, environmental factors, other devices to which the device communicates, and any other factor that might affect a decision as to which type of software product would be appropriate for the device.

At operation204, a request may be sent to a yellow pages agent (e.g., yellow pages agent112) for a list of software products that meet the needed capabilities. In an example embodiment, operation204is performed by a software life cycle management agent (e.g., software life cycle management agent106) operating on the device. It should be noted that the software products referred to may include aspects of a software product which may be considered by some to be services, for example, software as a service (SaaS)-type software where only a small portion of code is downloaded and installed on the device, with the bulk of the software functionality residing on external servers communicated with by the device, or may include more traditional software that is fully installed on the device itself prior to running. The request may include the list of needed capabilities prepared in operation202. This list may be stored in accordance with, for example, a semantic language. It should be noted that in some example embodiments, the request may also include instructions to the yellow pages agent as to how to determine possible software products that have services that meet the needed capabilities. These instructions may include, for example, an indication on how stringent the yellow pages agent should be with regard to selecting the possible software product candidates. For example, the instructions may indicate that this particular device only wants to be presented with available software products that meet all of the listed needed capabilities. Alternatively, the instructions may indicate that this particular device desires to be presented with software product candidates that meet a certain number of the needed capabilities (the number exceeding a particular threshold specified in the instructions). In some example embodiments the instructions may be even more detailed, specifying weighting to be applied to each of the needed capabilities in the list and a threshold above which a software product candidate is to be recommended based on the weights, or the highest ranking such candidate.

At this point the yellow pages agent may or may not communicate a list of software products found that meet the requirements specified in the request in operation204. It should be noted that in some example embodiments the software products found are somewhat anonymous, in that the yellow pages agent may just indicate a location where a candidate software product can be downloaded; however, in other embodiments, specific details about the candidate software product may be provided. In the case the yellow pages agent does communicate a list (of at least one software product), in an example embodiment this communication may be in the form of an “inform message” from the yellow pages. In other words, in some example embodiments the yellow pages agent may simply not respond to a request to which it can find no suitable software products. Nevertheless, at operation206, it may be determined if software products were found by the yellow pages agent and if it is a good time to install one or more of the software products. Both of these conditions have to be true in order for a “yes” path from this operation to be followed. If either condition is not true, then the process may proceed to operation208. At operation208, a request may be sent to the yellow pages agent to inform the device if software product candidates matching the needed requirements become available in the future. In an example embodiment this may represent a “subscription” to future notifications of software products/updates. In an example embodiment, both operation206and operation208are performed by the software life cycle management agent.

The determination at operation206as to whether or not it is a good time to install one or more of the software products may be based on a number of different factors. In one example embodiment, these factors may include the current processing load on one or more processors of the device, current memory utilization, and/or current load on any other system resources of the device. In another example embodiment, additional analysis of past usage may help make certain predictions of future use of the device, which may influence whether or not now is a good time to install the software products. For example, it may be 3:55 pm now and system resources may be available to install the software products now, but the system may learn through analysis of past usage that the user typically runs a system resource heavy process from 4 pm-5 pm every day, and thus the system may determine that now would not be a good time to install the one or more software products. The system may also take into account predicted time to install the one or more software products, as well as the resources such installation are likely to tie up during the installation process.

It should be noted that the term “install” is intended to be interpreted broadly to cover all steps of installing (or determining not to install) a software product on the device. This includes the process of testing the software prior to installation and the process of determining, based on results of the testing (and possibly other factors as well), whether or not to install the software. Thus, at operation206(when it is being determined whether or not it is a good time to install one or more of the software products offered by the service providers) this analysis may take into account how long it will take to test the software products, determine if the software products should be placed in a non-sandbox area on the device, and the acts involved in actually placing the software products in the non-sandbox area on the device.

If at operation206it is determined that software products matching the needed capabilities were found by the yellow pages agent and it is a good time to install one or more of the software products found by the yellow pages agent, then the process may proceed to operation210.

At operation210, it may be determined if multiple software products were found by the yellow pages agent in response to the request. If so, then at operation212the system picks a single software product among the multiple software products. In an example embodiment, operation212may involve an analysis of many different factors, such as the level of trust between the device and the provider of the software product, the set of capabilities valued most by the device, previous experience with the provider of the software product, price of the software product, etc.

Once the single software product is selected, or if at operation210it was determined that multiple software products were not found by the yellow pages agent, then the process moves to operation214and the system may request that a testing agent test the selected software product. At operation216, test results may be received from the testing agent. At operation218, the test results may be utilized to determine whether to complete installation of the selected software product. This determination may be performed in a number of different ways. In one example embodiment, the test results include a binary determination of whether the software product “passed” or “failed” the testing. In such a case, operation218may involve accepting this binary determination and acting accordingly. In another example embodiment, a more detailed analysis may be determined based on the results of the testing. For example, the testing may produce a report that includes an indication of how various system resources were utilized during the testing, and the software life cycle management agent or autonomy agent may determine, based on this information and preset thresholds, whether or not the software should be installed. Additionally, performance information from the testing may also be included in this determination. For example, the software life cycle management agent or autonomy agent may allow a certain level of system resources to be utilized if particular performance thresholds are met, but not allow that level of system resource to be utilized if the performance thresholds are not met. Additionally, factors such as cost may be utilized in this determination as well. For example, the software life cycle management agent or autonomy agent may accept a certain performance level and a certain amount of system resources utilized if the cost of the software product is low, but may not accept them if the cost of the software product is high.

If it is determined at operation218that installation of the tested software product should not be completed, then at operation220it may be determined if there are any additional software products found by the yellow pages agent to test. If not, then the process may return to operation208and the yellow pages agent may be requested to inform the software life cycle management agent if software product(s) matching the needed capabilities are found in the future. If it is determined at operation220that there are additional software products found by the yellow pages agent to test, then the process may return to operation210.

If it is determined at operation218that the installation of the tested software product should be completed, then at operation222it is determined if the software product is a remote service. If not, then at operation224OSGi may be instructed to move the software from the sandbox to an OSGi container from which installation can be completed. Then at operation226the autonomy agent can be informed to begin using the software and store information about the software in a software inventory database. If at operation222it is determined that the software product is a remote service, then operation224may be skipped and the process may move directly to operation226. Finally, at operation228, the yellow pages agent may be requested to inform the software life cycle management agent if an update to the capabilities of the software product becomes available in the future (either by, for example, an updated version of the software product, or by a competitor software product).

As described earlier, one of the factors that may be considered by the system in operation212is the level of trust of the service provider distributing the software product. This characteristic may also be a factor in operation218as well. There are a number of different mechanisms by which a system can determine a level of trust. Information relevant to a trust determination can come from a number of different sources, such as direct interaction (one's own experience working with the service provider), direct observation (acting as a third party and observing behavior of the service provider with others), witness information (reports from others on their interactions), sociological information (based on the role the service provider plays in society and judging behavior based on that rather than specific interaction), and prejudice (the assignment of a property to an individual based on some specific feature that allows it to be considered as part of a group that has the property). One characteristic that might be of concern is whether the service provider leaks information learned from the deployment of the software product on a device to users or entities not in control of the device. This is of particular concern with regards to so-called “spyware” which is software that may be installed intentionally by a user without the user realizing that it gathers and leaks information about the user and/or user's device.

One mechanism to detect such leaks is running the software product in a sandbox on the device and performing tests specifically to detect leaks. This activity could be expanded to include artificial compatriots to test the fidelity of the software product with respect to contractually agreed limits on retention or use of information. However, this solution may not detect a condition where the software product is written to behave normally until or unless a particular (non-present) agent initiates communication to begin the leak process.

One solution would be to run the software product on a known trusted server that has sandboxing capabilities which allow for remote testing and examination of the agent. As such, in an example embodiment, the testing of the software product installed in the sandbox of the device may be expanded to include testing and/or analysis of testing performed on the software product in a sandbox of another device, such as a server (although embodiments are possible where information is obtained from other devices similar to the device in question).

In an example embodiment, trust may be represented using a combined trust model. In a combined trust model, trust characteristics are modeled across multiple dimensions, such as quality, cost, likelihood of success, and timeliness. Trust can be updated based on interactions with the software product and/or service provider, and can also be based on reputation (e.g., the reported trust score from some other agent that has interacted with the software product and/or service provider).

FIG. 3is a flow diagram illustrating a method300, in accordance with an example embodiment, for preparing a list of needed capabilities of a device. In an example embodiment, this diagram may illustrate operation202ofFIG. 2in more detail, although in other embodiments a different process may be used to perform operation202ofFIG. 2.

At operation302, hardware of the device is scanned to determine hardware capabilities of the device. This may include examining, for example, processing power (e.g., central processing unit (CPU) type and speed, graphical processing unit (GPU) type and speed, etc.), memory capacity, memory speed, display type and size, user input capabilities (e.g., mouse, keyboard, touchpad, microphone, webcam, etc.), speaker type and parameters, and any other hardware information that may be relevant to a determination of capabilities of the device. At operation304, input may be received from a user of the device regarding desired features of software to be installed on the device. For example, a user may specify a desire for a word processing program.

At operation306, software currently installed on the device may be scanned. This may include, for example, an operating system and any applications installed on the device. The system may learn, for example, the operating system type and version, and the fact that certain types of software are already installed on the device. Additional information, such as configuration settings and other run-time variables, may be gleaned during this scan as well.

At operation308, hardware capabilities, user input, and software installed on the device are utilized in order to formulate a list of capabilities desired in a software product. This list at this point may be informal. At operation310, the list of capabilities is formalized by, for example, storing it in a semantic language where the format of the language allows for the storage of “needs” of a system.

FIG. 4is a flow diagram illustrating a method400, in accordance with an example embodiment, for finding matching software products at a yellow pages agent. This method400may be performed by a yellow pages agent in between operations204and206ofFIG. 2. At operation402, a request containing a list of needed capabilities is received from a software life cycle management agent. At operation404, a database of software products is searched for one or more software products matching the needed capabilities. In an example embodiment, the request from the software life cycle management agent includes an indication of criteria to be used to identify matching software products. For example, the criteria may include a threshold level of how many matching capabilities are needed in order for the yellow pages agent to determine that a match occurs. If the request contains such an indication of criteria, this indication of criteria may be utilized by the yellow pages agent in searching the database. The database itself may be organized in a manner that allows for efficient searching based on capability. For example, a directory of the database may be maintained that includes a mapping of capabilities to various software products stored in the database. At operation406, it is determined if there are software products matching the needed capabilities. If so, then at operation408, a location of the software products matching the needed capabilities is transmitted to the software life cycle management agent. If not, the process may end.

FIG. 5is a flow diagram illustrating a method500, in accordance with an example embodiment, for determining that software products matching the needed capabilities were found by the yellow pages agent and that it is a good time to install one or more of the software products found by the yellow pages agent. In an example embodiment, this method500represents operation206ofFIG. 2in more detail. At operation502, it is determined if software products matching the needed capabilities were found by the yellow pages agent. If not, then method500ends and a “No” is returned. If so, then at operation504, the current processing load of the device is determined. This may include scanning current CPU, GPU, and memory utilization, for example. At operation506, an estimated installation time and utilization (e.g., how much processing and memory usage is needed for installation) for each of the software products is determined. At operation508, past usage of the device, the estimated installation time and utilization, and the current processing load of the device is utilized in a determination of whether or not now is a good time to install one or more of the software products. If now is not a good time, then the method500ends and a “No” is returned. If now is a good time, then the method500ends and a “Yes” is returned.

FIG. 6is a flow diagram illustrating a method600, in accordance with an example embodiment, of installing a software product using a white pages agent. At operation602, a desired software product to install is identified. This may be performed in a number of different ways. In one example embodiment, a user may specify the desire to download a particular software product. In another example embodiment, an updated version of a currently installed software product on the device is identified. In another example embodiment, the system may scan the device and determine on its own what software product would be appropriate to install. At operation604, the location of the desired software product is requested from a white pages agent. At operation606, the location of the desired software product is received from the white pages agent. At operation608, it is determined if now is a good time to install the white pages agent. This operation may be similar to operation206ofFIG. 2and method500ofFIG. 5, with the exception of the lack of a need to determine whether one or more matching software products were found.

If it is determined that now is a good time to install the software product, then at operation610the software product is downloaded and stored in a sandbox on the device. If not, then the process loops back to operation608until it is a good time to install the software product. At operation612, the system may request that a testing agent test the software product. At operation614, test results may be received from the testing agent. At operation616, the test results may be utilized to determine whether to complete installation of the software product. This determination may be performed in a number of different ways. In one example embodiment, the test results include a binary determination of whether the software product “passed” or “failed” the testing. In such a case, operation616may involve accepting this binary determination and acting accordingly. In another example embodiment, a more detailed analysis may be determined based on the results of the testing. For example, the testing may produce a report that includes an indication of how various system resources were utilized during the testing, and the software life cycle management agent or autonomy agent may determine, based on this information and preset thresholds, whether or not the software should be installed. Additionally, performance information from the testing may also be included in this determination. For example, the software life cycle management agent or autonomy agent may allow a certain level of system resources to be utilized if particular performance thresholds are met, but not allow that level of system resource to be utilized if the performance thresholds are not met. Additionally, factors such as cost may be utilized in this determination as well. For example, the software life cycle management agent or autonomy agent may accept a certain performance level and a certain amount of system resources utilized if the cost of the software product is low, but may not accept them if the cost of the software product is high.

If it is determined at operation616that installation of the tested software product should not be completed, then the process ends. Otherwise, at operation618it is determined if the software product is a remote service. If not, then at operation620OSGi may be instructed to move the software from the sandbox to an OSGi container from which installation can be completed. Then at operation622the autonomy agent can be informed to begin using the software and store information about the software in a software inventory database. If at operation618it is determined that the software product is a remote service, then operation620may be skipped and the process may move directly to operation622. Finally, at operation624, the yellow pages agent may be requested to inform the software life cycle management agent if an update to the capabilities of the software product becomes available in the future (either by, for example, an updated version of the software product, or by a competitor software product).

FIG. 7is a sequence diagram illustrating a method700, in accordance with an example embodiment, for searching for and installing a software product on a device in accordance with an example embodiment. The method700may utilize an autonomy agent702, software life cycle management agent704, yellow pages agent706, software provider708, software testing agent710, and database712. At operation714, the autonomy agent702may determine needed capabilities of a device. At operation716, the autonomy agent702may send a request for software with the capabilities to the software life cycle management agent704. At operation718, the software life cycle management agent704may request a software product with the capabilities from the yellow pages agent706. The yellow pages agent706may respond with a location at operation720.

At operation722, the software life cycle management agent704may request the software product from the software provider708using the location. At operation724the software product is returned. At operation726, the software life cycle management agent704may store the software product in a sandbox. At operation728, the software life cycle management agent704may request testing on the software product by the software testing agent710. The software testing agent710may then test the software product in the sandbox at operation730, and then return the results at operation732.

At operation734, the software life cycle management agent704may determine whether to install the software product based, at least partially, on the test results. At operation736, if the software product is to be installed, the software product is installed to the database712.

Example Mobile Device

FIG. 8is a block diagram illustrating a mobile device800, according to an example embodiment. The mobile device800can include a processor802. The processor802can be any of a variety of different types of commercially available processors suitable for mobile devices800(for example, an XScale architecture microprocessor, a Microprocessor without Interlocked Pipeline Stages (MIPS) architecture processor, or another type of processor). A memory804, such as a random access memory (RAM), a Flash memory, or other type of memory, is typically accessible to the processor802. The memory804can be adapted to store an operating system (OS)806, as well as application programs808, such as a mobile location-enabled application that can provide location-based services (LBSs) to a user. The processor802can be coupled, either directly or via appropriate intermediary hardware, to a display810and to one or more input/output (I/O) devices812, such as a keypad, a touch panel sensor, a microphone, and the like. Similarly, in some embodiments, the processor802can be coupled to a transceiver814that interfaces with an antenna816. The transceiver814can be configured to both transmit and receive cellular network signals, wireless data signals, or other types of signals via the antenna816, depending on the nature of the mobile device800. Further, in some configurations, a GPS receiver818can also make use of the antenna816to receive GPS signals.

Modules, Components and Logic

The various operations of example methods described herein can be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors can constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein can, in some example embodiments, comprise processor-implemented modules.

Similarly, the methods described herein can be at least partially processor-implemented. For example, at least some of the operations of a method can be performed by one of processors or processor-implemented modules. The performance of certain of the operations can be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processor or processors can be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors can be distributed across a number of locations.

The one or more processors can also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations can be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application program interfaces (APIs).)

Electronic Apparatus and System

Example Machine Architecture and Machine-Readable Medium

The example computer system900includes a processor902(e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory904and a static memory906, which communicate with each other via a bus908. The computer system900can further include a video display unit910(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system900also includes an alpha-numeric input device912(e.g., a keyboard or a touch-sensitive display screen), a user interface (UI) navigation (or cursor control) device914(e.g., a mouse), a disk drive unit916, a signal generation device918(e.g., a speaker), and a network interface device920.

The disk drive unit916includes a machine-readable medium922on which is stored one or more sets of data structures and instructions924(e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. The instructions924can also reside, completely or at least partially, within the main memory904and/or within the processor902during execution thereof by the computer system900, with the main memory904and the processor902also constituting machine-readable media922.

Transmission Medium