Method and system for managing partitioned data resources6922685Abstract In accordance with an exemplary embodiment of the present invention, association forming entities are: a) maintained as objects in a like manner to the data objects being associated; and b) are themselves partitioned objects comprising two or more association fragments, each association fragment being mostly concerned with the interfaces to a particular data object participating in the association. In accordance with an exemplary embodiment of the present invention, each association fragment affiliated with a particular data object is stored in a location that enhances the ease of interaction between the association fragment and the data object. For example, where a first data object and second data object are maintained in data stores at some distance from one another, physically or logically, then a first association fragment will be located with or near to the first data object, and a second association fragment will be located with or near the second data object, at least within the same partition. This arrangement may be preferable because the volume of interaction between a data object and its respective association fragment may far outweigh the interaction needed between the two association fragments. This arrangement may also be preferable as the volume of interaction between a client application and both the data object and respective association fragment may exceed the interaction needed between the two association fragments. Some interactions will employ only one of the association fragments with the net result being a reduction in communications requirements and an improvement in performance. The present invention further provides for defining logical domains which are arbitrary and entirely orthogonal to partitions. Claims 1. In a computing environment, a method for implementing an association among a first data object and a second data object, the method comprising: Description BACKGROUND OF THE INVENTION
In accordance with an exemplary embodiment of the present invention, association forming entities are a) maintained as objects in a like manner to the data objects being associated, and are b) themselves partitioned objects comprising two or more association fragments, each association fragment being mostly concerned with the interfaces to a particular data object participating in the association. In accordance with an exemplary embodiment of the present invention, each association fragment affiliated with a particular data object is stored in a location that enhances the ease of interaction between the association fragment and the data object. For example, where a first data object and second data object are maintained in data stores at some distance from one another, physically or logically, then a first association fragment will be located with or near to the first data object and a second association fragment will be located with or near the second data object, at least within the same partition. This arrangement may be preferable because the volume of interaction between a data object and its respective association fragment may far outweigh the interaction needed among the two association fragments. This arrangement may also be preferable as the volume of interaction between a client application and both the data object and respective association fragment may exceed the interaction needed among the two association fragments. Some interactions will employ only one of the association fragments with the net result being a reduction in communications requirements and an improvement in performance. The present invention further provides for defining logical domains which are arbitrary and entirely orthogonal to partitions. BRIEF DESCRIPTION OF THE DRAWINGS The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as an exemplary 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: The present invention is illustrated by way of example, and not by way of limitation, in the Figures of the accompanying drawings and in which like reference numerals indicate similar elements and in which: FIG. 1A depicts a point-to-point architecture where applications message one another directly according to prior art messaging techniques; FIG. 1B depicts a hub and spoke architecture where applications message one another via messaging middleware according to the prior art messaging techniques. FIG. 2 is a representative diagram of an application; FIG. 3 is a logical diagram of an enterprise network containing CORBA-enabled processes distributed in both domain 1 and domain 2; FIG. 4 is a diagram representing independent systems' stovepipe relationships as might be expected in a telecommunications enterprise according to the prior art; FIG. 5 is a diagram of the NewWave network management concept in accordance with an exemplary embodiment of the present invention; FIG. 6 is a diagram illustrating the concept of many, small generic servers in many geographic locations distributed for enterprise use in accordance with an exemplary embodiment of the present invention; FIG. 7 is a diagram illustrating various typical configurations of the small servers running various operating systems in which VM containers are running on host servers in accordance with an exemplary embodiment of the present invention; FIG. 8 is a conceptual diagram of distributive concepts for managing an ecosystem of interrelated services in accordance with an exemplary embodiment of the present invention; FIG. 9 is a diagram of service platform infrastructure of interrelated services relating to an enterprise is illustrated in accordance with an exemplary embodiment of the present invention; FIG. 10A is a diagram depicting launching and registering service in a global ecosystem of interrelated services in accordance with an exemplary embodiment of the present invention; FIG. 10B is a diagram depicting finding and implementing a local service in a global ecosystem of interrelated services in accordance with an exemplary embodiment of the present invention; FIG. 10C is a diagram depicting finding and implementing a non-local service in a global ecosystem of interrelated services in accordance with an exemplary embodiment of the present invention; FIG. 11A is a flowchart depicting a process for launching and registering service in a global ecosystem of interrelated services in accordance with an exemplary embodiment of the present invention; FIG. 11B is a flowchart depicting a process for finding and implementing a local service in a global ecosystem of interrelated services in accordance with an exemplary embodiment of the present invention; FIG. 11C is a flowchart depicting a process for finding and implementing a non-local service in a global ecosystem of interrelated services in accordance with an exemplary embodiment of the present invention; FIG. 12A is a flowchart depicting the process employed by the registrar for registering services in accordance with an exemplary embodiment of the present invention; FIG. 12B is a flowchart depicting the process for enterprise leasing in accordance with an exemplary embodiment of the present invention; FIG. 12C is a flowchart depicting a process employed by the registrar for looking up a service in accordance with an exemplary embodiment of the present invention; FIGS. 13A-13B are flowcharts depicting the transaction process employed by the transaction manager is illustrated in accordance with a preferred embodiment of the present invention; FIG. 14 is a diagram depicting a service failure and re-homing the service to a different server and further depicting self-healing a proxy reference using a smart proxy in a global ecosystem of interrelated services in accordance with an exemplary embodiment of the present invention, and further illustrates self-healing a proxy reference using a smart proxy; FIG. 15A is a flowchart depicting a service restarting process in a global ecosystem of interrelated services in accordance with the present invention; FIG. 15B is a flowchart depicting a process se for self-healing stale references using a smart proxy in accordance with the present invention; FIG. 16 is a diagram depicting a conceptual realization of the DataBus two-tier infrastructure concept for mediating data transactions and an enterprise-wide data persistence layer which allows clients to access shared enterprise data in accordance with an exemplary embodiment of the present invention; FIG. 17A is a traditional representation of an E-R diagram; FIG. 17B is a representation of nodes and arcs of the E-R diagram being mapped onto entity engine processes and association engine processes; FIG. 18 is a diagram illustrating three entities, entity A 1802, entity B 1804 and entity C 1806 partitioned in accordance with an exemplary embodiment of the present invention; FIG. 19 is a diagram illustrating three container-database partition pair in accordance with an exemplary embodiment of the present invention; FIG. 20 is a diagram depicting DataBus components necessary for creating an entity instance in accordance with an exemplary embodiment of the present invention; FIG. 21 is a flowchart depicting a process for creating an entity instance in accordance with an exemplary embodiment of the present invention; FIG. 22 is a diagram showing a read/write copy of the entity instance being streamed directly to the client in accordance with an exemplary embodiment of the present invention; FIG. 23 show the cache server approach where a copy of the entity instance is streamed to a cache server rather than the copy being directly steamed to the client in accordance with an exemplary embodiment of the present invention; FIG. 24 is a diagram showing the event notification approach where the client is using only read-only copies of the entity instance and receiving change notifications whenever an update is received in accordance with an exemplary embodiment of the present invention; FIG. 25, on the other hand, the optimistic concurrency approach depicts the client using a read/write copy that must stay in sync with a master copy in order for updates to be accepted in accordance with an exemplary embodiment of the present invention; FIG. 26 is a diagram depicting DataBus components necessary for performing the multi-hop find process in accordance with an exemplary embodiment of the present invention; FIG. 27 is a flowchart depicting a multi-hop find process in accordance with exemplary of the present invention; FIG. 28 is a diagram representing a logical domain boundary defined from partitions in each of several entities in accordance with one embodiment of the present invention; FIG. 29 is a diagram of NW service platform infrastructure of interrelated services relating to an enterprise is illustrated in accordance with an exemplary embodiment of the present invention; FIG. 30 is a flowchart depicting a process for finding entity instances that are associated with an instance in accordance with exemplary of the present invention; FIG. 31 is a diagram showing external central association engine 3102 which consists of a plurality of link records which describe associative relationships between Customer entity instances and Account entity instances; FIG. 32 is a diagram of NW service platform infrastructure of interrelated services relating to an enterprise is illustrated in accordance with an exemplary embodiment of the present invention; FIG. 33 is a flowchart depicting a process for getting all accounts instances that are associated with an identified customer instance in accordance with an exemplary embodiment of the present invention; and FIG. 34 is a flowchart depicting a process for getting all accounts instances that are associated with an identified customer instance using smart proxies in accordance with an exemplary embodiment of the present invention; FIG. 35 is a diagram of the MOC and associated NewWave service necessary for collecting events into policy-based work documents, and then directly routing work to the best currently available operations staff that is automatically assembled based on the individual staff members' aptitude for particular tasks in a process flow in accordance with an exemplary embodiment of the present invention; FIG. 36 is a functional diagram of the MOC depicting interactions between key MOC components interact in accordance with an exemplary embodiment of the present invention; FIG. 37 is a diagram of an assessor for assessing events based on organizational rules in accordance with an exemplary embodiment of the present invention; FIG. 38 is a diagram illustrating a basic design of an aggregator in accordance with an exemplary embodiment of the present invention; FIG. 39 is a diagram of a simplified version of a state machine in accordance with an exemplary embodiment of the present invention; and FIG. 40 which depicts a user avatar lookup in accordance with an exemplary embodiment of the present invention. Other features of the present invention will be apparent from the accompanying drawings and from the detailed description which follows. DETAILED DESCRIPTION OF THE INVENTION The present invention relates to data processing. More particularly the present invention relates to the management of information technologies. The automation of manual business processes was one of the first important tasks for which computers were employed. Prior to integrating to the business processes in computer applications for execution on computer-implemented systems, business processes were typically segmented along departmental lines, so naturally the computer business process applications that automated those business processes were likewise segmented along departmental lines. The resulting computer-implemented applications/systems were characterized as having narrow scope, rarely doing little more than automate the same steps and procedures that comprised the manual business process. Because of a lack of interoperability, they seldom integrated with other systems which likewise made sharing resources impossible. Normally, this way of providing answers to an enterprise can only tailor the answer from the perspective of the department that manages the stovepipe. An enterprise answer, or a solution to an enterprise level problem, might require that an enterprise user access several, or even all departmental stovepipe applications for the departmental perspective view in order to get a "piece" of the entire enterprise level solution. It would then be left to the user to coalesce the departmental answers from the respective stovepipe applications into a unified enterprise level solution by integrating the disparate departmental perspective answers into an enterprise level solution. Currently, within enterprises exist many stovepipe applications that address and solve very narrow problems within departments. For example, human resources, finance, timekeeping and even resume-tracking applications within human resources are natural stovepipe applications that address particular problems within an enterprise. Moreover, vendors of specialized stovepipe applications often become extremely proficient at solving penumbra issues that cross enterprise boundaries and are adopted by widely-diverse enterprises. An enterprise might be thought of as consisting of having umbra and penumbra functions, umbra being methods, processes and the associated resources necessary for accomplishing core enterprise charter goals, and penumbra being methods, processes and the associated resources necessary for accomplishing and supporting the charter goals. Alternatively, an enterprise's core functions can be described as revenue centers, while support functions can be characterized as cost centers. Examples of umbra stovepipe applications include inventory control applications and sales tracking applications that exist within a sales organization; reservoir management applications, downhole logging applications and production and field control applications that exist within an oil production company; admissions and discharge applications, medical record keeping applications and laboratory applications that exist within a healthcare provider; and even legal instrument-drafting applications, docketing applications and litigation toolkit applications that exist within a law firm. These applications came about when traditional mainframe systems failed to solve individual departmental problems or, more likely, were not flexible enough to solve the problems in a timely fashion. Because of this failure, a "departmentalized" solution ensued and critical, mission-critical departments implemented their own systems. These systems owned, maintained and protected the applications, hardware and resources necessary to efficiently perform their missions, resulting in an enterprise made up of independent "islands" of special purpose applications, hardware and resources. Even though departments were protective toward their stovepipe systems, that did not mean that departmental users did not want to share information or resources with the remainder of the enterprise. Instead, it was merely indicative of the processes, data and resources existing within a single department. Incontrovertibly, this reality demonstrated that the enterprise parts, or departments, were automated without regard for the enterprise level needs. Information, process and resource sharing among enterprise departments were rarely considered when selecting a vendor's stovepipe application/system. As a result, there were no open application programming interfaces (APIs), open architectures, or other mechanisms that allowed for ready access to the processes and data existing within these stovepipe systems. In order to achieve acceptable results with a department's stovepipe system, an enterprise user had to be proficient with a department's stovepipe application, system and GUI, as well as understand how the application managed its resources. Traditional systems (also known as "legacy systems") are applications that exist as stovepipes, such as departmental or vendor stovepipes, in a centralized enterprise environment. Mainframe-based systems make up a majority of traditional systems, while minicomputers and large UNIX-based systems might also be correctly referred to as traditional systems. The characteristics that define the traditional system include centralized processing, unshared resources and terminal-based access. Traditional systems typically support a large user and processing load on both database and business processes that exist together within the same environment. While these systems may support thousands of users concurrently accessing the same application, sharing processes and resources between applications is uncommon. Moreover, sharing processes and resources to applications outside the system is unheard of; however, simultaneous access to an application across a single platform is a powerful incentive for businesses. The total cost on ownership (TCO) for these systems is relatively low when compared to PCs and workstations. Therefore, rather than becoming extinct, these systems not only continue to sell, but older applications leveraging traditional systems have demonstrated significantly more staying power than originally anticipated. The prior art's answer to the shortcomings of stovepipe applications was to implement Enterprise Application Integration (EAI) between stovepipe applications. In general, applications serve two primary purposes: (1) they perform routine business processes that support a business function; and (2) they access, process, and/or display data. At the highest level of abstraction, applications can be organized by the functions they perform and the data they process. EAI, in its most idealistic form, involves the unrestricted sharing of business processes throughout an enterprise's networked applications or data sources. Software programs in areas such as inventory control, human resources, sales automation and database management which were custom built in the technology of the day were designed to run independently for addressing a specific need and do not share. Many times the applications were implemented as proprietary systems, with no interaction between the systems and thus did not share. EAI's popularity can be attributed, in part, to the need for maintaining the older stovepipe applications, while simultaneously integrating them within a new enterprise application infrastructure. As the enterprises grow and recognize the need for their information and applications to have the ability to be transferred across and shared between systems, companies invest in EAI in order to streamline processes and keep all the elements of the enterprise interconnected. The focus of EAI is primarily directed into four major categories: database linking, application linking, data warehousing and virtual systems approach. Database linking involves implementing EAIs between departmental databases for sharing information with each other and duplicating information as needed based on a set of rules. Application linking involves the enterprise sharing business processes and data between two or more applications. Data warehousing involves data being extracted from a variety of resources (data sources) and compiled in a specific database for analysis. This unified collection of data better supports management decision making by allowing enterprise users to view resource data from a variety of stovepipes from an enterprise perspective. Data warehouses contain a wide variety of data that present a coherent picture of business conditions for the enterprise at a single point in time. The final category of EAI is a common virtual system which involves using EAI in all aspects of enterprise computing, tying applications, resources and data together so that they appear as a unified application to a client. EAI is often referred to as "middleware" because EAI software functions as a conversion or translation layer. It is also a consolidator and integrator. Custom-programmed middleware solutions have been developed for decades to enable one application to communicate with another that either runs on a different platform or comes from a different vendor or both. Middleware is software that translates commands or data between different software programs. EAI exists in two popular architectures, point-to-point and hub and spoke. Typically, point-to-point architectures are referred to as messaging EAIs, while hub and spoke architectures are referred to as middleware EAIs. Both variants allow existing enterprise applications to supply existing business processes and resources to other enterprise applications. With respect to the first type of architecture, point-to-point applications directly access data and resource data from other applications. FIG. 1A depicts a point-to-point architecture where applications 102-116 message one another directly. Each enterprise application must be modified with a messaging agent, a queue and a relationship application table for listing other enterprise applications and the data and resources that they own. Java applications may require further modification with a multi-valued attribute, a "codebase," for storing the location of the object's class definition. An application interacts with the messaging agent whenever the application determines that it needs access to data or resources that it does not own. The messaging agent accesses the relationship table for the location of an application that owns the needed resource. An initial request message is sent to the application that owns the resource for specific resource data. Here, several potential transitions may take place depending on the requestor application (e.g., temporary use of the resource, updating the resource, etc.) However, the resource owner application might be busy at the time the request is received, so the request is queued until the application is free to process the request. Once the response message is sent to the recipient, the recipient application might also be too busy to process the incoming message thread. In that case, the resource data in the response is also queued in anticipation of a processor freeing up and the process thread needing the resource being executed. At some point, the thread is executed in accordance with the application's processes. The messaging agent is responsible for the message and data integrity that it sends and/or receives, so if the transaction is not completed, the messaging agent must repeat the transaction. As can be understood from the foregoing, each application requires significant modifications for point-to-point EAI to be effective. If an enterprise application is upgraded, modified or even migrated to a different physical location, it and any application that it relies on, or that relies on it, must also be modified for subsequent point-to-point messaging transactions to be successful. In addition, each individual enterprise stovepipe application is a potential bottleneck as the individual applications are usually not scalable for messaging responses. Finally, inter-application messages can either be in the form of some proprietary messaging protocol or may, instead, take advantage of existing messaging protocols and messaging specification. If the enterprise utilizes proprietary messaging protocols, the protocol specification must be formalized within the enterprise and maintained and a corresponding message transport devised. If, on the other hand, existing protocols are to be used, then the enterprise's existing message transports that utilize those protocols will be called on for handling the added burden of the point-to-point messages. The second EAI architecture improves on existing point-to-point middleware by utilizing a message broker that manages communications among all enterprise stovepipe applications. The message broker communicates directly with each participating application and thus forms the "hub" of a hub and spoke messaging architecture. Message-broker processing is a mixture of schema and content transformation, rules processing, message splitting and combining, as well as message routing. Once the processing is complete, the information is sent to any target system that needs to receive that information using whatever native format the target application can understand (e.g., EXtensible Markup Language (XML), IDoc, Java Message Service (JMS) message, proprietary, etc.). FIG. 1B depicts a hub and spoke messaging architecture wherein messaging middleware 140 serves as a central point of communication between enterprise applications 122-136 for transferring messages between applications. Hub and spoke architecture has the advantage that the participating applications require somewhat less custom programming because messaging middleware 140 acts as a messaging broker for providing an interface between stovepipe applications, thus allowing them to asynchronously send data back and forth to each other. Data sent by one application is stored in a middleware queue and then forwarded to a receiving application when that application becomes available to process it. In addition to a transport means, the messaging broker provides stovepipe applications with distribution rules for forwarding messages and formatting rules for reformatting data from a sending application's format to a receiving application's format. A rules engine analyzes incoming messages and makes routing decisions, while a formatting engine converts the data into the structure required by the receiving application. The messaging broker provides disparate stovepipe applications with a common message transport and queuing system, thereby relieving applications from the responsibility of ensuring that the data sent is properly received. In practice, a messaging broker can be either a complete messaging system or software that works with existing messaging transports in order to add routing intelligence and data conversion capabilities. While the hub and spoke architecture represents a significant advancement over independent stovepipes and an improvement over point-to-point messaging, the hub-and-spoke EAI solution is resource-constrained because all the processing takes place on a single server. Eventually, the number of connected systems and the information traffic will saturate the available resources of the integration server (memory, processor, and disk) resulting in reduced performance. Bottlenecks can and do occur and scheduling can become problematic for enterprise applications. Moreover, once an application signals its intent to process resource data from the messaging queue in the hub, the messaging broker may be busy and thus unavailable to pass the necessary resource data to the requesting application prior to the receiving application timing out. In that case, the application thread is held up waiting for the resource data to arrive and might in fact timeout prior to the messaging broker responding to the application. If a timeout occurs, the resource data remains queued until the application is again freed up. Overloads on the messaging broker have led to the development of a "federated architecture" wherein the applications connect to a single integration server or hub statically and are able to exchange information with each other. This means that all information produced or consumed from a particular application is available only for processing within a particular hub. Since the hubs are interconnected, each hub appears to the other hubs as connected applications, thus producing and consuming messages. However, messages produced from a single application may process only on a single hub because they are statically bound to that hub. This architecture does not allow hubs to share the message-processing load, or nor does it allow other hubs to process messages from applications that are not directly connected. In general, applications serve two primary purposes: (1) they perform routine business functions that support a business process; and (2) they access, process, and/or display data. At the highest level of abstraction, applications can then be organized by the functions they perform and the data they process. A representative diagram of an application is depicted on FIG. 2 as any of applications 202A-202N. Since an application is the building block of an information system, it can be expressed as a collection of software programs that execute user interface 204A, business rules 206A, and data access operations 208A, all of which are necessary to execute a business process. Typically, application 202A consists of a plurality of services that perform these operations. Services are any predefined, specialized results which are produced from specific software programs designed to perform explicit data processing operations when called upon. Services might be considered as either business logic services or infrastructure services. Business application services are designed and developed to provide specific computational, input/output, or data access operations when called upon at execution time, while infrastructure services provide computer platform operating systems, database management systems, or network platforms for supporting business applications. Returning to FIG. 2, application 202A uses business rules 206A as a logical specification for the business' requirements. Business rules 206A define computational algorithms and operations to perform explicit data processing operations that are necessary to implement a business process. Also shown in FIG. 2 is a logical representation of another prior art mechanism utilizing the aforementioned messaging architecture for handling stovepipe applications. Stovepipe applications 202A-N are the defined logical layers that provide practical boundaries for physically segmenting the application into smaller, more manageable program segments. The interactions between logical layers of an application can be accomplished through messaging and middleware services as described above. The logical layers of an application are defined as a user interface layer, a business logic layer and a data access layer. The user interface layer of an application interacts directly with end-user input/output devices (e.g., Windows workstations or a printer/fax device). The user interface layer is the most visible aspect of the business process supporting the end user. It encompasses a variety of operations, such as window or screen management, keyboard and mouse handling, end-user help functions, general input editing and data type validation, or formatting data for output to a laser printer or plotter device. The business process (logic) layer of an application implements the particular requirements of a business process based on a set of business rules. The business rules may be no more than developer guidelines, but more often are generic algorithms that can be tailored to a business' needs by the user selection of values for parametric constraint variables. Typical operations at this layer consist of controlling the logical flow of interaction between the end user (via the user interface layer), access and manipulation of data or information (via the data access layer), and specific computational algorithms to be performed (via the business logic layer). Finally, the data access of an application includes the operations needed to store, access and maintain data or information necessary to support a business process. The data accessed within this layer can include both structured and unstructured formats, depending upon the application requirements. For the most part, a commercial relational database management (RDBMS),or proprietary file access system, provides the services performed within this layer. The division of applications A-N into logical layers and the inherent physical program design characteristics necessitate services that enable communication between logical and physical layers via messaging services and data access middleware and operate fundamentally as described above. The intent of the logical layer concept is to stratify applications by their analogous functional levels while maintaining the unique character of each application A-N. Application management becomes more of a concern because the natural tendency of programmers is to offload processing tasks to other, more capable applications while focusing their efforts on the core functional aspects of an application. This distributed concept tends to centralize certain services at key applications. Failures and modifications of those key applications can result in disastrous effects across the enterprise. Separating an application into discrete layers permits application services to be scaled and positioned where appropriate and reduces the complexity inherent in single-platform solutions. Specialized application components can be combined to achieve the best results, and similarly, different combinations of clients and servers allow for a computing fix to these specialized application components. However, the layered application approach suffers from all of the above-described shortcomings attributable to the messaging and middleware EAIs. The user interface and business process application levels must be internally modified for messaging interfaces, user interface messaging interface 220, and business process messaging interface 222 for communications between the respective application levels, while data resources are handled by a completely different architecture. Data, while being accessible to any application within the enterprise, is still owned by a single application. Resource access bottlenecks become more prevalent at the enterprise level so data access middleware 224A-224N is regularly configured as federated architectures. In short, while the layered application concept somewhat distributes services in layers across an enterprise, the stovepipe application structure is maintained because each application remains responsible for providing its own necessary services and managing its own resources and data. Another prior art means for sharing services between applications is through the use of distributed object systems such as Common Object Request Broker Architecture (CORBA)-enabled processes. CORBA-enabled processes can be placed and run on the same machine or on any machine in a network enterprise differing from messaging middleware in that they cause processes (components/objects) to be executed in real-time rather than sending data. Examples of these CORBA applications and other similar distributed object systems include System Object Model (SOM) and Distributed System Object Model (DSOM) from IBM Corporation, One New Orchard Road, Armonk, N.Y. 10504; or Component Object Model (COM) and Distributed Component Object Model (DCOM) from Microsoft Corporation, One Microsoft Way, Redmond, Wash. 98052. CORBA provides a way to execute programs (objects) written in different programming languages running on different platforms no matter where they reside in the network using an "object bus" or "software bus," a software-based communications interface through which objects are located and accessed. Objects reside on various machines throughout the distributed environment and are tasked with performing duties defined by their implementation. FIG. 3 is a logical diagram of an enterprise network containing CORBA-enabled processes distributed in both domain 1 and domain 2. CORBA objects are defined by an Interface Definition Language (IDL) that describes the processing (methods) the object performs and the format of the data sent and returned. IDL definitions are stored in an interface repository (not shown) which can be queried by client application 312 to determine what objects are available on the bus. However, unlike such standard servers, objects have the ability to move around if needed. A client communicates with an object through an object reference. This is a pointer to the object that allows requests for operations and data access to be sent from the client to the server via an object request broker (ORB). In the Figure, the ORB is depicted as client ORB 316 and server ORB 322, but could be conceptually represented as an ORB bus between client 310 and server 320 and connected to a plurality of objects (or object implementation). At runtime, CORBA client 310 makes requests to remote CORBA object 328 via an ORB 316. ORB 316 provides a proxy object in the client's address space which creates the illusion that remote object 328 is a local service or process. ORBs 316 and 322 manage the interactions between client 310 and object implementation 328. Client 310 issues a request and invokes methods of object implementations. Client 310 and server 320 communicate by exchanging messages defined by the General Inter-ORB Protocol (GIOP). When client 310 calls a CORBA operation, client ORB 316 sends a GIOP message to server 320. The client-side architecture provides client 310 with interfaces to ORB 316 and object implementations. A dynamic invocation (not shown) allows for the specification of requests at runtime whenever the object interface is not known at runtime and utilizes the interface repository. Each CORBA implementation comes with one or more IDL compilers (not shown) that know the language mapping for the language in which they were designed (i.e., that used by client application 312). It is the IDL compiler's job to turn the IDL into stub and skeleton files 314 and 326, respectively. These files are used in distributed applications to make object communication almost transparent. Stubs and skeletons are all language- and ORB-dependent so the same IDL file is used to generate the stubs and skeletons for each language and ORB implementation. IDL stub 314 is used in client processes to communicate with server 320. Stub files 214 consists of functions generated by the IDL interface definitions and linked into client application 312 for a mapping between client application 312 and ORB 316. Client application 312 uses stub 314 to make calls to the server objects. Functions needed by client 312 are called just as if they were local objects. However, stub object acts only as a proxy that forwards requests to and responses from a CORBA process on a remote server. The implementation-side interface consists of server ORB 322, IDL skeleton files 326 and object adapter 324. Skeleton files 326 are the converse of stub files 312. They are what the server-side applications use to seamlessly receive distributed requests. It is the skeleton's job to receive requests from ORB 322, call the proper implementation, which in this case is object implementation 328, and return the results. ORB 322 calls method skeletons to invoke the methods that were requested from client application 312. Object adapter 324 provides the means by which object implementation 328 accesses most ORB services. Object adapter 324 isolates object implementation 328 from ORB 322. A server may have a variety of object adapter types, each providing specific services. In short, client application 312 connects directly to ORB 316 through its stub 314. Object implementation 328 on server 320 connects directly to object adapter 324 through skeleton files 326. Object adapter 324 then connects to server ORB 322. A request from client application 312 is next sent through client stub 314, across ORBs 316 and 322 to the proper object adapter and through server 320's object adapter 324 and skeleton files 326, eventually reaching implementation 328. The return value of the implementation follows the same route in reverse. Every object on the ORB has an Interoperable Object Reference (IOR) which is a global identifier string that identifies the machine on which its associated object is located and the interface that the object supports. It has encapsulated the IP, PID and other values required by the client to connect. Client 310 can use IOR for an object and standard function calls on ORB 316 to find an object reference. Client ORB 316 uses the IOR to determine what type of object is being referenced and the identity of the server for routing requests. In single machine domains, the client can write its own IOR to a file and get all server objects on the ORB since the ORB stays within the domain of the client machine. The client could then read the IOR from this file and have the ORB resolve it into an object reference. However, when the server object is in a different domain from that of the client machine, the client must receive a reference to the object from an independent service. Usually, this is accomplished by writing server 320's IOR to a Server IOR File and placing it in a well-known location, using http, shared file system or ftp. At start up, client 310 merely accesses the file system for the server's IOR. This method for bootstrapping, although simple to understand and test, has several disadvantages, notably the need for the client and the server to share access to a file system. Another method for locating an object server is for the enterprise to employ naming service 302. Naming service 302 uses a standard CORBA object which contains operations that bind, resolve, and unbind human-readable names with an IOR. When a service object is created, it binds its IOR with a name in naming service 302. By looking up the associated name, any other object on the ORB, or with access to the naming service, can retrieve that object reference from the naming service server. Client application 312, needing a connection to server 320, merely retrieves a reference to naming service 302 and accesses server 320's IOR by the server's name. Then, server 320's IOR is resolved into the identity of the server for routing requests. A stovepipe application is a stand-alone program. It implies an application that does not integrate with or share data or resources with other applications. Many current systems have been built as "stovepipe" applications, meaning that they do not communicate easily with other enterprise systems. Moreover, these stovepipe applications form their own system "islands" with their own hardware platforms, development languages, protocols and resources (e.g., rules, databases, etc.) Corporations are demanding new systems changes at an astounding rate, and unfortunately, these old legacy systems do not adapt well to change. A telecommunications company, for example, might have had separate systems for plain-old telephone service (POTS) customers, inter-exchange carrier (IXC) customers and wireless customers. FIG. 4 is a diagram representing independent systems' stovepipe relationships as might be expected in a telecommunications enterprise according to the prior art. Current day "independent systems'" stovepipes are represented in the Figure as stovepipes A-N. Telecommunications enterprises implement specific telecommunications systems in a effort to provide their customers with profit-generating services. The telecommunications services provided to the enterprise's customers are represented in the Figure as Digital Subscriber Line service (DSL 410A), Asynchronous Transfer Mode network services (ATM 410B1 and 410B2), Synchronous Optical NETwork (SONET) fiber-optic transmission system services (vendor "A" 410C and vendor "B" 410D), and Internet Protocol services (IP). As will be understood from the figure, each of the enterprise's services 410A-410N must be managed by its own specialized management applications, represented in the Figure as management applications 408A to 408N. The combination of the services and management applications define the enterprise's profit centers. While many of the management applications 408A to 408N may own services and/or resources identical to those owned by any of the other management applications in the enterprise, the enterprise's management applications are tightly coupled and therefore do not share services and resources. As discussed above, this happens because a particular management application, for instance management application 408A, is developed for a unique enterprise service, which in this case is DSL 410A, without any thought of sharing the application's resources and services with any other management application within the enterprise. Other enterprise management applications were developed for enterprise systems in a similar ad hoc fashion. Each of management applications 408A-408N performs specific management tasks associated with a corresponding service provided by the enterprise to its customers; however, rarely does a management application provide the services necessary to cost center applications (i.e., tracking and billing customers and accounts for the service usage). Therefore, in addition to developing a management application 408A for specific enterprise services, it was often necessary for an enterprise to stovepipe a business application, represented in the Figure by business application 406A, to the management application for providing cost center services and functionality not provided by the profit center application. The combination of corresponding independent cost center applications and profit center applications form independent systems' stovepipe applications. Events and information are communicated between individual management and business application stovepipe systems using point-to-point messaging architectures as described above. However, each application owns the resources and data necessary to carry out its functionality. Application services are not shared between business and management applications but instead, data and events are merely passed up the stovepipe system. For the most part, information is transferred to and from an administrator working in Operations Center (Ops) 404A on client 402A through either business application 406A or management application 408A. Notice that the stovepipe systems for DSL 410A and IP 410N are fairly analogous and symmetric. However, as discussed above, in certain situations, EAI is possible between the business applications and the management applications. Notice, for instance, that the administrator on client 402B may receive an integrated presentation from each of business applications 406B and 406C. Notice also that rather than business applications 406B and 406C being stovepiped directly to a separate management application, that each of business applications 406B and 406C communicate directly to each of management applications 408B-D. This is possible through the use of enterprise application integration between independent stovepipe systems for similar enterprise services as management application 408B handles a synchronous transfer mode routers through ATMs 410B1 and 410B2, while management application 408C manages a particular vendor's version of synchronous optical networks (SONET) and management application 408E handles a second vendor's SONET 410E. Here, rather than each management application having its own stovepipe business application, the enterprise is able to consolidate business applications from three independent stovepipe business applications to only two, 406B and 406C. Thus, the enterprises achieved processing and storage efficiency by handling only two independent stovepipes for the three management applications. Notice, however, that true resource integration has not been accomplished. In fact, the only point at which resource data is truly integrated is in the integrated presentation 404B to client 402B. Thus, while the enterprise has realized a certain amount of reduction in scale due to reducing the duplicative business application processes and resources, none of management applications 408A to 408E share any services or resources whatsoever. In fact, with regard to the telecommunications enterprise depicted in FIG. 4, it should be apparent that the only true data integration occurs at the presentation level. For instance, by integrated presentation means 404B for client 402B. Thus, rather than applications 406B and 406C sharing resource data, the data is actually fed to integrated presentation means 404B. From the representative stovepipe relationships in FIG. 4, it is apparent that any of management applications 408A to 408N may have duplicative services from any of the other management applications, as none of the management applications communicate with one another, and instead communicate only along their own independent stovepipe lines. Those services would be under-utilized with respect to the enterprise and require that more enterprise resources be devoted for housing those services. The same is true of resources needed for the execution of the services within management applications 408A to 408N. While it is true that the various enterprise services 410A to 410N may require different resources be available to the management applications, it may also be true that various resources may be common among the various management applications. Network elements compound the stovepipe issue by requiring multiple control interfaces at the element. For example, Juniper routers require both Simple Network Management Protocol (SNMP) and xML to perform a full suite of network management functions. Therefore, the enterprise must again house and manage duplicative management resources only because the independent stovepipe systems' own services, resources and data do not share with one another. NewWave Concepts NewWave (NW) network management is a next generation management concept that adapts the most advanced concepts from distributed computing to build a global application infrastructure. NW fuses virtual machine spontaneous networking, mobile code, directories, rules engines, and eXtended transAction (XA) transaction standards to deliver a fine-grained set of services on which management applications are re-engineered. NW leverages leading edge technologies for achieving a cross-domain technology management system which separates applications from technology. The individual stovepipe systems that evolved for network equipment, hosts and servers, and applications can all be integrated into a coherent management regime. FIG. 5 is a diagram of the NW network management concept in accordance with an exemplary embodiment of the present invention. NW might be analogized to a schema for presenting services to a service user, such as client 550. The term "client" will be understood to represent any consumer or user of a service, notably, many clients or other services, but may instead be any application, software module or tool that utilizes the processes of a service. NW network management service platform 500 (NewWave NM) is comprised of Global Information Bus 510 (GIB) is necessary to make services (along with the resources needed by the services) available to client 550. DataBus 520 is a mechanism for decoupling data from the applications that have historically owned the data and make the data available to all authorized users, such as making all data in an enterprise owned by the enterprise and then available to all (authorized) enterprise uses. Finally, Management Operations Center 530 (MOC) utilizes service provided by both GIB 510 and DataBus 520 for monitoring and operating a network. NewWave NM service platform 500 itself consists of a group of NW infrastructure services and procedures necessary to support NW services. GIB 510 is best described as a global ecosystem of interrelated services. The GIB architecture is an infrastructure for deploying and managing individual services on a global scale. GIB 510 provides an infrastructure on which to build services that can run on many platforms. The physical infrastructure is high scalable allowing for new capacity to be easily added, almost invisibly, with a low cost-per-capacity. GIB 510 deployment infrastructure enables software distribution and service configuration and deployment to be accomplished without direct access to the physical servers within the enterprise. Distribution, configuration and deployment are centralized operations, but the effect to consumers is distributed. GIB 510 also utilizes a runtime infrastructure for distributed computing, including discovery of services, distributed transaction management and self-healing and also incorporates a management infrastructure for keeping the state of the ecosystem stable. Finally, GIB 510 includes a distributed communication infrastructure which supports multiple types of interaction between services. These interactions may be totally decoupled, message-based communication in which sender and receiver are unaware of the existence of the other, slightly coupled, wherein message-based communication in which the sender and receiver are aware of each other, but never gain direct access to each other. Also, GIB 510 distributed communication infrastructure supports generic coupling, event-based communication in which the receiver registers interest in certain events with the sender (the sender is physically coupled to the receiver, but does not know anything specific about it) and fully coupled, remote-procedure call communication in which the sender must find the receiver to make the call (GIB 510 also supports methodologies for finding each other). DataBus 520 is a data management architecture for NW service platform 500. It presents an architecture for creating a consistent, enterprise-wide data persistence layer which allows clients to access shared enterprise data. DataBus 520 achieves this enterprise-wide look by decoupling shared enterprise data from specific applications (breaking down the stovepipes) and opening up the data layer to across-the-enterprise access (given proper authorization). DataBus 520 architecture is designed from the ground up for global scalability and accommodation of evolving business data models in a highly-distributed physical deployment. Scaling is realized predominantly through the partitioning, while individual partitions are mapped to logical data domains that are defined along more relevant dimensions than entity-type dimensions (e.g. geography, line of business, etc.), and cut across traditional entity boundaries. MOC 530 is a set of NW-enabled services intended to provide support for addressing problems similar to those handled in a Network Operations Center (NOC), but not limited to only network problems. As such, it is intended to support problem management in many forms, including those typically handled by customer support centers and tactical assistance centers. MOC 530 represents a tool that assumes a fundamental re-engineering of the processes and tools used in these environments. MOC 530 is an example of the NW approach to designing and managing applications. Rather than building monolithic stovepipe application systems, the "application" is a collaboration of many smaller services acting on common objects, possibly without knowledge of each other, but with their actions affecting each other. MOC 530 makes extensive use of rules external to code executed by rules engines. These rules, being uncoupled from specific applications' processes and code, can be presented in a more human-readable form. Additionally novel uses of finite state-machines and logic gates are used to integrate information and provide behavioral responses to a follow of events and/or data. This allows for the changing of the behavior of the system without changing the code. Those behaviors which represent organizational policy are removed into rules and can then be managed by experts in those organizations. Those rules which encode structural information can be managed, augmented and altered separate from the overall systems responses and actions. Fundamental to the concept is a behavioral approach to rules and application logic. Behavioral in this context means that "events generate responses". Instead of elaborately designed processes & procedures, which must of necessity be successively decomposed into more and more refined detail; individual use cases are directly programmed (in isolation) using only their own context scope of applicability and the domain of their effect. This results in a bottom up aggregation of behavior from small to large (instead of from large to small). Change can proceed without overarching knowledge and with lessoned effect on surrounding applications (increased isolation of design and development). This is achieved via re-use of common framework services with different procedural behaviors attached. NewWave NM service platform 500, largely through the use of GIB infrastructure services 510, spawns many small components (services and resources) that act largely independently of each other rather than a single monolithic application. These services may directly interact with shared resources by, for example, registering for notification of updates to shared resources. The small services find each other and communicate by using GIB infrastructure services 510, (specifically registration and lookup services) and may also publish messages using the GIB's publish/subscribe services. In general, without directly modifying existing components, the overall behavior of any NW-supported architecture can be changed by adding new components. Sometimes this will be a whole new framework service, at other times a specialization of a common service with specific behavior and scope. Since all components, services in particular, are NW-enabled services utilizing registration, lookup and enterprise lookup services, new services, such as services 540, can be added to NewWave NM service platform 500 from outside vendors and entrepreneurs. Moreover, because new added services 540 may unknowingly invoke existing enterprise cost center services, such as customer tracking and billing, vendor-supplied services provide a rich source of revenue for an enterprise without adding infrastructure normally associated with traditional stovepipe systems. The NW network management service platform relies on the ability to deploy services on many different platforms that run on many different server types. Java (a trademark of and available from Sun Micro Systems, Inc., Palo Alto, Calif.) is a programming language designed to generate applications that can run on all hardware platforms, small, medium and large, without modification and thus provide a means to develop on one platform, but deploy on many. In practice, the Java 2 platform (JDK 1.2) has been the basis for this multi-platform deployment, but one skilled in the art would readily recognize that other developer kits are available for specific platforms. The Java programming language allows developers of services to be unconcerned with the platform on which the service will be deployed. The NewWave architecture exists separate and apart from the Information Technology used to build the architecture. The architecture and design predate the selection of deployment technology. The reference application uses Java language and Jini distributed applications infrastructure, both Sun technology. There are many reasons why this technology is especially adapted to the NewWave architecture and its reliance on 'plug and play' and code mobility. However, other systems can implement this architecture and several have been used in the Worldcom Lab including Sun JMX, IBM Aglets, IBM WebSphere EJB, and Objectstream Voyager products. Nevertheless there are real and distinct synergies between design and the target implementation technology. Many aspects of NewWave would be much more laborious to achieve on technologies other than Java and Jini. Further, we expect application infrastructures to evolve and in a few years better implementations technologies will arrive. NewWave anticipates these and expects to deploy on each successive wave of distributed computing that achieves product status. The Physical Machine Layer-Ubiquitous Server Machines The NW network management service platform is deployed on large numbers of small, rack-mounted servers of varying platforms. Some exemplary platforms include Solaris for Netra (available from Sun Microsystems, Inc.), IBM AIX (available from International Business Machines Corporation), HP UX all of which are UNIX-based platforms. UNIX is a trademark of the American Telephone And Telegraph Company Corporation of New York, N.Y. NT and Linix systems are also in use. The NW network management service platform could be deployed on larger servers as well. However, the cost of scale may go up with larger servers, as those physical boxes are on an entirely different cost curve. The NW physical environment consists of thousands of these small to medium size servers deployed throughout the physical boundaries of an enterprise. These servers could, in the case of a telecommunications enterprise, be deployed on the edges of the network in Point of Presence connections (POPs) as close to the user as possible and even on user premises in user enterprise domains. Data centers and major network hub intersections are also used in the physical deployment model. A NW-enabled server is configured with one of a small number of standard configurations. Standard configurations include generic servers with no special features, and resident application servers with Commercial Off the Shelf Technology (COTS). Resident servers in use include, but are not limited to: database servers with specific database products installed, directory servers with directory applications installed, security servers with security applications and rules servers with a rules engine installed. Basically, native services are relocatable and can migrate to any generic container. Integration with resident applications (each fixed to a specific server or servers) is achieved by representing the interface to the service a NewWave service. FIG. 6 is a diagram illustrating the NW concept of many, small generic servers in many geographic locations distributed for enterprise use. For example, an exemplary territory is exhibited in the state of Virginia where three sites have been designated for the distribution of physical hardware denoted hereon in the Figure as geographic sites A, B and C. Each geographic site contains racks of physical hardware, racks 1-n, including various servers 604A-C available from a variety of original equipment manufacturers (OEMs). In accordance with the exemplary embodiment of the present invention, servers 604A-C are not larger multi-processor servers, but instead are smaller rack-mounted servers which may support various platforms such as Solaris, IBMAIX, Windows NT, Linux, etc. However, larger servers can be easily configured in accordance with the exemplary embodiments. For instance, at location A, racks 1-n, 602A contain a plurality of servers 604A. Each of servers 604A may be from a single vendor or instead might be from multiple vendors. Associated with one or more of servers 640A are particular resources managed by that particular server. For instance, databases 610A are particular vendor's databases, while database 612A is another vendor's database, each of which are managed by a server in a rack at location A. Another resource, which will be discussed in more detail below, is a rules engine 614A which may also be managed by one or more servers 604A. Notice that racks 602B at geographic location B and 602C at geographic location C are similarly configured as those at geographic location A, thereby having large numbers of small generic servers 604B and 604C, respectively. Similarly, some of servers 604B and 604C may host various vendor's data resources 610B, 610C or 612B, along with the rules engines 614B and 614C. The importance of this concept is that any server in any geographic location can process any service needed by any client in any other geographic area. In its broadest sense, NewWave releases the application and the data from the physical server and also from the bounds of that single location. NewWave produces a global scale computing system where the telecommunications data network replaces the traditional computer backplane and the individual server and the containers on it substitute for each of the chips in a multi-processor enterprise system. Immense scalability is archived at greatly improved efficiency for organizations that require large scope business activities. The Virtual Machine Layer The operating system of each physical server is not used directly in the NW operating environment. Instead, each server must have the capability of running a platform-independent programming language virtual machine (VM) on top of the operating system that converts Java bytecode into machine language and executes it. The Java Virtual Machine (JVM) (a trademark of and available from Sun Microsystems, Inc.) is currently the most popular software that converts the Java intermediate language into machine language, but other vendors supply their own versions. For example, the Microsoft Virtual Machine (available from Microsoft Corporation in Redmond, WA) is also a Java interpreter. A VM is a multi-threaded processing environment that encapsulates all access to the underlying computing platform. As such, a Solaris Netra looks the same as a Windows NT to a process being executed by the VM. A VM is, in fact, a single computing process, but it supports the running of many "mini" processes (threads) within. Thus, the NW operating environment is actually thousands of VMs deployed on small physical server machines throughout the world. Other approaches to abstraction of the application environment from the underlying system were explored, most notably IBM's Aglets. Java and the JV provided the best platform to date. Other platforms used the VM approach in the past, most notable the IBM VM system and the Honeywell Multics systems. In the Future NewWave expects the use other platforms as these reach the market and provide similar dynamics. Containers In the NW environment, services are remote processing entities that are managed remotely, configured remotely, load their code remotely, and found and communicated with remotely. To facilitate these requirements, the NW service platform includes a container technology for providing a runtime operating environment for services. At the heart of the container scheme is the concept of a generic service container-a CPU process into which arbitrary software services may be homed to a host server at runtime. Each VM runs a small set of code which identifies it as a VM container and makes the VM container able to be found and communicated with remotely. VM containers are realized as VM heavy-weight processes which are launched from boot scripts as the server is booted. VM service containers are the multi-threaded servers that provide a place in which multiple-service instances reside, each executing its own thread or threads of execution. A VM container is also a service itself. More correctly, a VM container may be thought of as a "service container service running on a VM." The service provided by a VM container is the launching of other services within itself. It behaves much like the services it contains in the way it can be found remotely and communicated with. Thus, like any other service, a VM 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. The registration and finding of services will be discussed in greater specificity below. The salient point is that, like services, VM containers can be found remotely from anywhere in the world and requests can be programmatically made of them. VM containers report their own statistics and can be asked to shut down. The main difference between a VM container and all other services supported by the NW service platform is in how a VM container, or more properly, the container service, is launched. A VM container is launched from the operating system and not from within another container. It cannot be launched from a remote location programmatically according to the NW conventions. In a similar fashion as other services, containers are not intended to be launched by NW clients. Rather, conceptually it could be considered as an integral part of the operating environment and launched by one of the following means:
Although every VM container is truly generic in nature, a VM container runs a small set of code in which the VM container can designate itself as a particular type of container. Some containers might designate themselves for running essential NW infrastructure services or other enterprise services such as GIB, DataBus or MOC services, or perhaps the container designation may relate to the type of host server running the VM container. Designating a container as being of a particular type might also be based on the server resources available in a logical domain. Depending upon the total quantity of VM containers in a domain, their reliability and domain loading factors, an administrator can designate a pre-defined number of containers as being NW infrastructure-type, GIB infrastructure-type, and so on. The composition of VM container-type designations is based on the priority of the hosting center and intended to assure that VM containers are always available for crucial enterprise objectives, such as re-homing services that are essential to the enterprise. Therefore, key services, while they may run in a generic-type VM container, do not depend on a generic-type VM container being available for self-healing of dead or dying services because other VM containers have been pre-designated for restarting those services. Thus, in the case of an essential infrastructure service, or any service for that matter, a predetermined quantity of VM containers can be pre-designated for running only those essential infrastructure services (self-healing capabilities will be discussed in greater detail below). A key technical aspect is the storage of the configuration of the system and the container off board of the system and the container. In NW systems these occurs in the registry. This is implemented in this generation via Jini Lookup and Directory (LDAP) services. However, any abstract and external service can implement the off board registration. By being separate from the container, all or part of the configuration can be transferred efficiently to another container as needed. Enterprise wide operations can occur on the configuration, without reference to the physical/server location it describes. It should be understood at this point that a logical domain within the enterprise may be of at least two types-management and network-and these domain types are not necessarily synonymous. A management domain is generally defined from servers that are physically located at a physical hosting facility. On the other hand, a logical network domain is based on the transmission topology of a network defined around, for instance, a unicast or multicast routing table and may not be physically located at a single facility. Furthermore, some self-healing services use service lookup services that utilize management domains, while others use service lookup services that utilize network domains. Therefore, if the intent of the VM container is to designate itself as a type compatible with self-healing services, the VM container must ensure that it is listed in the lookup service being used by the particular self-healing service monitoring the services to be run by the VM container. With respect to still another criteria, a VM container can designate itself as a particular type of container based on the resources available from the host server running the container. Services must be run in a container, but some services need additional resources aside from the container, such as a particular type of database, rules engine, etc. A service provider must be apprised of the resources available at a server host before attempting to launch a service on a host that is not equipped to run the provider's service. Finally, a VM service container amounts to a heavyweight CPU process. Allowing service threads belonging to different service suppliers to coexist in the same process space is an open invitation to adverse interactions (e.g., modification of a non-final static variable used by both services). For the sake of isolation, each VM container is uniquely owned by a single service supplier business entity. While APIs might be used by a customer who supplies services to lease a service container, the container may also designate itself as a container type to be used by a particular supplier. In that way, only services supplied by a single-service supplier business entity will be able to run in a particular container. Thus, a VM container can be designated to services supplied by a particular supplier. Note that domain registrar and/or enterprise registry are not the only means for finding a handle to a service container. Another option is to register the service containers within RMI registry. The URL address for connecting to a specific service container (e.g., "rmi://lambic.wcomnet.com/serviceContainer13/") is stored within the inventory database. A service supplier would query the inventory database for the URL address and then perform a conventional RMI lookup against that URL address. FIG. 7 is a diagram illustrating various typical configurations of the small servers running various operating systems in which VM containers are running on host servers in accordance with an exemplary embodiment of the present invention. Here, four servers 702A, B, C and N are shown, each having a unique operating system platform such as operating systems A, B, C and N. Running on each of servers 702A to N are one or more generic VM containers 704. Every CPU host in an enterprise hosting facility will run at least one VM container processes such as servers 702N and 702A). Service deployers may inject the code for their services at any one of the VM containers. As can be seen from the Figure, it is expected that the VM containers 704 are multi-threaded, multi-tasked containers allowing for the concurrent execution of various services 706 on each container 704. Further, each server platform 7021A-N may run multiple VM containers 712. High Level Overview of the NewWave Platform With respect to FIG. 8, a conceptual diagram of NW distributive concepts is illustrated in accordance with an exemplary embodiment of the present invention. General Information Bus (GIB), also called the Global Information Bus (GIB), 802 can be conceptually described as an information bus containing NW-enabled services and mobile applications available for use by clients as needed. Essentially, the GIB is a set of specific, yet extensible, Framework Services, implemented on a scoped (local, regional, global) distributed computing infrastructure. The heart of GIB 802 is the manner in which it allows deployment of services into the operating environment in a very flexible and easy-to-administer manner. GIB 802 is a series of services that may change from one execution to another, finding and collaborating with other services dynamically. This system of collaborating services starts to resemble an ecosystem, and the job of the GIB architecture is to maintain the interconnectedness and stability of this ecosystem as it continually changes. Almost all GIB components are implemented as services, even if they support no externally-available requests because all components must support certain administrative requests mandated by the NW. The administration and management of the ecosystem depends upon this capability. Although the component is acting as a service in the traditional sense of the word, it is deployed as a service. For this reason, even though GIB components come in many different flavors, at one level they all appear as services and follow many of the same conventions. The different flavors include the following and are depicted in the Figure below:
Services All services must conform to certain conventions to be a well-behaved service. These include the following:
To the greatest extent possible, a service must be mobile which is the single most important characteristic of a service. This is to say that there are as few restrictions as possible to the deployment of a service on any machine anywhere as quickly as possible without human intervention. The limitations of this goal are primarily the provisioning of a service by:
Services in the NW environment must overcome these limitations. As such, NW services must be able to be launched on a server without any code specific to the service and without any configuration information being pre-installed on the server. All resources used by the service, if possible, must be able to be remotely accessed remotely and not depend upon the resource being present on the local machine. Databases used by NW services must be able to be created on the fly by the service. So, while a service might depend on the existence of a local database server, it cannot depend on that database having been configured to have certain tables. It must be able to create the tables from a schema which is remotely loadable and to populate the database from remote sources. If the data cannot be remotely loaded, then the database must have a mirror copy which the service can re-home to. Finally, a NW service must be able to be launched on a server without a human logging onto the server to initiate the launch and, in the event of a failure, a service must be able to be re-homed at runtime from one server to another without human intervention. The NW infrastructure provides an operating environment for services which is similar to the public Internet or an intranet. Instead of many client machines, the NW service platform is deployed on large numbers of small, rack-mounted servers. Instead of web browsers running Virtual Machines, there are VM containers, and instead of running applets in the web browser VM, there are services running in container VMs. When an applet is launched from a web page, it has a "codebase" identifying the location of the class files (server) that need to be loaded before the applet can run. In the NW infrastructure, each service has a codebase identifying from where its class files should be loaded from. To create this environment, the NW service platform deploys many HyperText Transport Protocol (HTTP) servers in place to serve up code, that is, Java class files and resources. The class files and resources are installed on the HTTP servers. An HTTP server which is employed to serve up code is called a "code server." When a service is launched in a VM container, the container is provided with certain configuration information, including the service's codebase. The codebase contains the address(es) (usually URL(s), but it could be URI(s)) of the code servers which are able to serve up the service's code. So, when the service is launched, its code is loaded from a remotely-located code server. As services are generally long-running, code located remotely, even if it is a large amount of code, is a reasonable cost. Additionally, caching techniques are used to locally store the class files, checking each time to ensure that they have not been modified on the code server. In this way, installing a new version of a service's classes does not involve any type of software distribution technique involving the servers on which the services will run. Instead, it involves only pushing the new software out to the HTTP servers, which is a much more manageable task. Consumers of services must run software that is consistent with the service. Whenever a service is used, there is a piece of code, the proxy, which is used to access the service. The proxy is referred to herein as a client proxy, proxy object and service object alternatively and will be more fully described below. In some environments, notably the CORBA environment described above, the proxy is the Achilles' heel to software distribution. However, in the NW environment, the proxy is also remotely downloaded. When a proxy is registered with an enterprise registrar, it too is given a codebase from which any client using the proxy should load the code. In this way, the client and the service always use consistent copies of the service and the proxy. In implementation, the Java Jini proxy is used with specific semantics and augmentation for NewWave service inter-working. Regardless, a client must have initially loaded an "interface" for interacting with the proxy. This code also must be consistent with the interface presented by the service. One solution is to launch client applications that use NW services with a similar remote loading approach. Specifically, an "Application Launcher" that launches an application using a specified remote codebase. One such application launching tool is Web Start (available from Sun Microsystems, Inc.). A service must be mobile from the point of view of class and resource files, as well as from the point of view of configuration information. Configuration information, like class and resource files, cannot be tied to a specific machine. To accomplish this, configuration information is made available at the enterprise level, thus NW services can be launched using configuration information that is not local to the service. As will be more fully described below, all configuration information is stored in an enterprise level repository (the enterprise repository) and then replicated to identical repositories throughout the geographic extent of the enterprise. Application launchers access the configuration information in the repository, and then forward the configuration information to the VM container selected for running the service. The information includes both configuration information needed by the container to launch the service and information needed by the service itself. The NW infrastructure provides for remotely-located resources. Reference files and other resources used by a service are remotely loaded at runtime using the same techniques described above used for class l | ||||||