Abstract: A service container provides a runtime operating environment for services managed remotely, configured remotely, load their code remotely, and found and communicated with remotely. The container scheme is the concept of a generic service container into which arbitrary software services may be homed to a host server at runtime. Each virtual machine runs a small set of code which identifies it as a service container and registers it with registries for making the service container visible and allows for remote communication.

Abstract: The present invention is directed to a system, method and software product for balancing resource services are always available to match the desired work to be done through the use of “sticky services.”. Sticky services are defined as services that you know you want to have available as resources and as such they need to be present in the environment of cooperative applications; it may be that you want these always present or it may be that you want them present whenever certain conditions occur (see NewWave policy service). The general assumption of distributed systems is to not count on the environment you want being present, or put another way assume failure will occur. Therefore distributed environments like Jini assume all services are transient and will be garbage collected when not in active use. For the inside out approach to work, a mechanism should exist that, when desired, counters the transit design assumptions.

Abstract: The present invention is directed to a system, method and software product for balancing resource services are always available to match the desired work to be done through the use of “sticky services.”. Sticky services are defined as services that you know you want to have available as resources and as such they need to be present in the environment of cooperative applications; it may be that you want these always present or it may be that you want them present whenever certain conditions occur (see NewWave policy service). The general assumption of distributed systems is to not count on the environment you want being present, or put another way assume failure will occur. Therefore distributed environments like Jini assume all services are transient and will be garbage collected when not in active use. For the inside out approach to work, a mechanism should exist that, when desired, counters the transit design assumptions.

Abstract: In accordance with an exemplary embodiment of the present invention, an improved service container is presented. The present service container technology provides a runtime operating environment for services that must be managed remotely, configured remotely, load their code remotely, and found and communicated with remotely. The container scheme is the concept of a generic service container into which arbitrary software services may be homed to a host server at runtime. Each virtual machine runs a small set of code which identifies it as a service container and registers it with registries for making the service container visible and allows for remote communication. A service container must register itself with a domain registrar and/or enterprise repository to be visible in its home domain and with the enterprise repository to be visible to services across the enterprise. Registration involves passing service and service container configuration information to the registry.