WO2011069782A1 - A method and a system for plug and play support of computer architectures - Google Patents

Abstract

The invention provides a method for managing connections in a plug and play fashion between computing machines in a computer architecture such as a virtual data center. The method comprises: - previously providing at least one connection management structure, said connection management structure including connection entries defining a role based connection between two computing machines, each connection entry defining a socket role assigned to one of said two computing machines, said socket role being associated with socket attributes representing the information that needs to be provided by the computing machine having the socket role to establish connection with the other computing machine, and a plug role assigned to the other computing machine, said plug role being associated with plug attributes representing the configuration actions that need to be executed by said other computing machine to establish connection with the computing machine having the socket role, and - managing the connections among said computing machines in the computer architecture using said at least one connection management structure.

Description

A method and a system for plug and play support of computer architectures

Field of the invention

The present invention generally relates to computer architectures and in particular to managing connections between computing machines in such computer architectures.

Background of the invention

With the growing complexity of modern computer systems, computer system installation, maintenance and support become more and more difficult and expensive. Such modern computer systems often comprise multiple inter-dependent applications so that the computer system as a whole must be managed as a unit. In such computer architectures, there is a need to manage the cooperation between the software applications running on different computing machines, whether physical or virtual, so that they can achieve common computing goals. However, complex workflows are involved for the customization of the interconnected software applications to work properly. Software applications are generally preinstalled within a site, then "imaged", then "unimaged" on a new computing machine, then re-configured for the new computing machine/network so it can run again.

In particular, a virtual computer system comprises a number of virtual appliances representing pre-built software solutions, each consisting of one or more virtual machines (VM) that are packaged, updated, maintained and managed as a unit. Unlike a traditional hardware appliance, these software appliances make it possible for customers to easily acquire, deploy and manage, pre-integrated solution stacks. This speeds up time to value and simplifies software development, distribution, and management. Whereas current virtual appliances often contain a single virtual machine, modern enterprise applications model service oriented architectures (SOA) are provided with multiple tiers, where each tier contains one or more machines. A single virtual machine model is thus not sufficient to distribute a multi-tier service so that a virtual appliance needs to be composed of more virtual machines. As an example, a typical web application can consist of three tiers: A web tier that implements the presentation logic, and application server tier that implements the business logic, and a back-end database tier. An implementation of such web application would divide this into three virtual machines, one for each tier.

In a virtual computer architecture such as a virtual datacenter, the deployment and the dismissal of complex appliances require multiple configuration steps to be executed in order to make the virtual appliance up and running. Conventionally, such a configuration process requires an initial reconfiguration phase to assign operating system specific parameters, like for example network information (IP, hostname, ...), and an additional reconfiguration phase to establish/remove the communication between the different components/product running in different virtual machines, and the communication between different products running in different Virtual Machines.

Today these reconfigurations are performed manually or rely on invocation of predefined scripts with static values in input. This manual configuration is time-consuming and can involve errors as software product topologies become larger and increasingly complex, involving a huge number of workflows for the customization of the interconnected components. In particular, the manual configuration of applications running in different computing machines and managed with different lifecycles often lead to various configuration problems that can affect negatively the end-users. Summary of the invention

In order to address these and other problems, there is provided a method for managing connections between computing machines in a computer system according to the appended independent claim 1, a computer program and a system according to appended claims 14 and 15 respectively. Preferred embodiments are defined in the appended dependent claims.

The invention accordingly provides an efficient and dynamic plug and play support of computing machines running in a computer system. This allows managing the cooperation in a real plug-and-play (PnP) fashion of the software applications running in new computing machines towards software applications already available in computing machines deployed in the target environment, without requiring manual configuration steps. The configuration uses a set of given configuration models and policies that are defined in one or more connection management structures.

The connection management structures define for each cooperation involving two computing machines a socket role assigned to one of the two computing machine and a plug role assigned to the other computing machine.

Each computing machine can retrieve its roles at deployment time (socket or plug). Accordingly, it is not required to statically predefine the computing machine roles.

Once established the configuration method is not static and can be managed and updated based on the events generated by the environment or the actions triggered by the user.

Further advantages of the present invention will become clear to the skilled person upon examination of the drawings and detailed description. It is intended that any additional advantages be incorporated herein.

As they may be cited in the following description, IBM and Rational are trademarks or registered trademarks of International Business Machine Corp., in many jurisdictions worldwide,

Brief description of the drawings Embodiments of the present invention will now be described by way of example with reference to the accompanying drawings in which like references denote similar elements, and in which:

Figure 1 shows a high-level view of a system for plug and play support of computing machines in a computer architecture in accordance with the embodiments of the invention ;

Figure 2 is a block diagram showing the plug and play system in accordance with certain embodiments of the invention;

Figure 3 is a diagram illustrating an exemplary target environment including three computing machines requiring plug and play support ;

Figure 4 illustrates the structure of a connection management structure in accordance with certain embodiments of the invention;

Figure 5 is a block diagram showing the plug and play system in accordance with a particular embodiment of the invention;

Figure 6 is a flowchart for managing connections of computing machines in accordance with the embodiments of the invention;

Figure 7 shows a flowchart for processing socket roles assigned to each computing machine at deployment time;

Figure 8 shows a flowchart for processing plug roles assigned to each computing machine at deployment time;

Figure 9 shows a flowchart for dynamically managing connections of computing machines based on events received in accordance with the embodiments of the invention;

Figure 10 shows a flowchart for re-processing a given socket, in response to the reception of an event related to the connection involving the having the given socket;

Figure 11 shows a flowchart for re-processing a given plug, in response to the reception of an event related to the connection involving the given plug;

Figure 12 shows an exemplary implementation of the plug and play system in accordance with certain embodiments of the invention; and

Figure 13 and 14 show different states of an exemplary user interface for managing connections between computing machines, in accordance with the embodiments of the invention.

It is noted that the drawings of the invention are not necessarily to scale. The drawings are merely schematic representations, not intended to portray specific parameters of the invention. The drawings are intended to depict only typical embodiments of the invention, and therefore should not be considered as limiting the scope of the invention. Additionally, the detailed description is supplemented with Exhibit El containing examples of structures used in accordance with the embodiments of the invention. Exhibit El is placed apart for the purpose of clarifying the detailed description, and of enabling easier reference.

A portion of the disclosure of this patent document contains material which may be subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright and/or author's rights whatsoever.

Detailed description

Figure 1 shows a high level view of a connection management system 100 in accordance with certain embodiments of the invention.

The connection management system 100 is provided to manage connections in a plug and play fashion between computing machines 220, 221, 222, 223 and 224 in a computer architecture 200.

The connection management system 100 will be referred to thereinafter as "plug and play" system. In the present description, the terms "connection" and "cooperation" will be used with a similar meaning to designate the process of assembling or linking two computing machines for achieving a common computing goal and/or for exchanging information in a target environment.

The exemplary computer architecture 200 shown in figure 1 includes a distributed network of computing machines 220-224 such as servers (220, 221, 222) and databases (223) that are connected together by one or more networks such as the Internet and/or local networks. Messages flow between the components of the system.

Each computing machine in the computer architecture 200 comprises a number of preinstalled software applications (standalone applications or application packages such as software products).

This defines a software topology characterized by workflows between the different computing machines 220-224. The plug and play system 100 in accordance with the embodiments of the invention makes it possible for the software applications installed in the different computing machines to connect and cooperate with each other in order to achieve a common computing goal and/or to exchange information (e.g. product service to end-users).

The computing machines 220-224 may be physical or virtual machines, depending on the type of environment on which the computer architecture 200 runs. The environment may be a physical environment, a virtual environment or a heterogeneous environment. A physical machine includes with no limitation any type of computer, information processing system or other programmable electronic device, including a client computer, a server computer, a portable computer, an embedded controller, a personal digital assistant, and so on. Even if the plug and play system 100 is shown as separated from the computer architecture 200, the skilled person will easily understand that the plug and play system 100 may be totally or partially included in the computer architecture 200.

Figure 2 shows a detailed view of the plug and play system 100 according to certain embodiments of invention.

The plug and play system 100 includes one or more connection management structures 21, thereinafter referred to as "stereoCable adapters" defining how to establish a role based cooperation between two computing machines 22 in the computer architecture 200.

In the present description the word "stereocable" will be used to designate the connections between the computing machines that are managed by the plug and play system 100. in accordance with the embodiments of the invention. The plug and play system 100 manages the connections between computing machines so that the computing machines are capable of automatically recognizing each other to establish cooperation in a plug and play fashion, when deployed in the target environment.

The stereocable adapters may comprise a number of connection entries or stereocable entries defining computing machine roles for each connection between two computing machines 22. More specifically, each connection entry in the stereocable adapters 21 defines a plug role assigned to one of the computing machine involved in the connection and a socket role assigned to the other computing machine involved in the connection.

Stereocable entries may be defined from a user interface allowing the selection of stereocable connections from a stereocable catalog, for example when the image is built using a specific user interface such as a modeling tool like Rational Software Architect. Alternatively, the stereocable entries may be predefined before deploying them, for example by adding to an image the stereocable connections from a list of stereocables predefined in a catalog, and then deploying them to the associated engine installed inside the image. Once received the new stereocable connections will be processed. This gives the possibility of starting from a base image and adding all the connections to be supported in plug-and-play way before the deployment.

The stereocable adapters 21 further define socket attributes for the socket role representing the information that needs to be provided by the computing machine having the socket role to establish connection with the other computing machine, and configuration actions for the plug role representing the information that needs to be executed by the computing machine having the plug role to establish connection with the other computing machine having the socket role.

In accordance with the embodiments of the invention, the connections among the computing machines 22 in the computer architecture are managed using the stereocable adapters 21. In this way, the computing machines can be dynamically connected and configured to achieve a common computing goal and/or exchange information, the configuration of each computing machine involved in a role-based cooperation being based on some values exposed or published by the other computing machine involved in the same role-based cooperation.

The invention thereby defines and manages dynamic "stereo" appliances corresponding to a set of computing machines that when deployed in the target environment are capable of automatically recognizing each other to establish cooperation in a plug and play fashion, without requiring any manual configuration phase.

Figure 3 illustrates exemplary computer architecture 200 deployed in a target virtual environment including three virtual machines 225, 226 and 227: a TWS user interface 225 (TWS_UI) represented by a virtual machine VM1 (TWS stands for IBM Tivoli Workload Scheduler), a TWS server 226 (TWS_server) represented by virtual machine VM2 and an ITM server 227 (ITM_server) represented by virtual machine VM3 (ITM stands for IBM Tivoli Monitoring). As shown, three connections have been established by the plug and play system 100 from the stereocable adapters 21 : a first role-based cooperation C 1 between TWS UI 225 and TWS SERVER 226, a second role-based cooperation C2 between TWS SERVER 226 and ITM SERVER 227, and a third role-based cooperation C3 between TWS UI 225 and ITM SERVER 227.

Figure 4 illustrates the structure of a stereocable adapter 21 in accordance with certain embodiments of the invention. As shown, each stereocable entry or "Stereocable" 210 in the StereoCable adapter 21 associated with a given connection between two computing machines 22 in the computer architecture comprises at least one socket section or socket role 2101 assigned to one of the two computing machines 22 and at least one plug section or plug role 2100 assigned to the other computing machine 22.

The socket section or "socket" 2101 describes the information that needs to be provided by the computing machine having the socket role (for example TWS Server 226 in the example of figure 3) running on a given environment to establish cooperation with another computing machine (for example TWS UI 225 in the example of figure 3) running on the same environment. A machine 22 publishes the information required by the socket definition when it is assigned a socket role.

For example, published information may include information about the status of a server (e.g. "guestlnfo.stereocables. socket. TWS SERVER. status = "Enabled"), about the port of a server (e.g. "guestlnfo. stereocables. socket. TWS SERVER. port = " 1234") , about the user (e . g . "guestlnfo.stereocables. socket.TWS_SERVER.user = "pciano") or about the server type (e.g. "guestlnfo. stereocables. socket.TWS_SERVER.type = "distributed"). The plug 2100 describes the actions that need to be executed by a given computing machine running in a given environment to establish cooperation with another computing machine running in the same environment. When a machine is assigned a plug role, it locates a machine playing the corresponding socket role, retrieves the published socket information and executes the action described in the plug definition. In addition to the plug actions, the plug may further contain unplug actions to be executed when the related socket is removed/updated (such as for example, removing the server from a list of possible engines the User Interface can connect to).

In certain embodiments according to the invention, the stereocable adapters 21 may be defined as configuration files loaded in each machine 22 and in particular as XML files. An exemplary XML stereocable file 21 is represented in Exhibit El. As shown in Exhibit El, each stereocable entry in the XML stereocable adapter includes in the plug section " <PlugSection>" one or more plug definitions such as for example"<Pl_UgID>TWS_UI</PlugID>".

Each plug in the plug section 2100 may include a plug ID (e.g. "Plug ID1") identifying the computing machine having the plug role (e.g. TWS UI) and a configuration actions sub-section identified for example by the tag "<ConfigurationActions>" and defining the parameters of the configuration actions that need to be executed for the stereocable connection. Each configuration action in the sub-section <ConfigurationAction> may define a value for a trigger tag "<trigger>" (e.g. a "deployment" value for <trigger> indicates that the configuration has to be invoked only once at deployment time, while other values for <trigger> like for example "VM Start" would indicate that the configuration will be invoked each time a virtual machine "VM" is started). Each configuration action in this sub-section <ConfigurationAction> may further define the action type using a tag such as "<ActionType>" (e.g. action type has a "script" value), the configuration parameters for the action (using for example "<ConfigurationParameter>" tag), and the operations involved in the action identified with a tag such as "<Operation>" (e.g. "/pino/driver4/scripts/TWSUI.sh").

Each socket in the socket section 2101 may include a socket ID identifying the computing machine having the socket role (e.g. "TWS Server"), a published parameter sub-section, identified for example by the tag "<PublishedParameters>" and defining the socket attributes, or configuration parameters identified for example by the tag "<ConfigurationParameter>". Each configuration parameter definition may include a configuration name identified for example by the tag "<ConfigurationName>" (e.g. "host") and a configuration value identified for example by the tag <ConfigurationValue> (e.g. "ncl25050.location.ibm.com").

The socket section 2101 and the plug section 2100 may further include a condition subsection designated for example by the tag "<Condition>" and describing a condition that is to be satisfied to process the plug or socket. This may be a dependency condition between the considered stereocable and another stereocable. The example below illustrates an exemplary condition subsection :

"<Condition>

<Description>This socket requires TSAM-TPM plug information</Description>

<ID>Conditionl</ID>

<ConditionType>PlugActive</ConditionType>

<ConditionValue>TSAM_TPM_END_POINT</ConditionValue>

</Condition>" According to this example, the socket will be processed only if the

TSAM TPM END POINT Plug is active.

Turning back to figure 2, the plug and play system 100 also includes at least one connection management unit 23, thereinafter referred to as "stereocable engine". In certain embodiments according to the invention, each computing machine 22 may be provided with a respective stereocable engine 23. Alternatively, the plug and play system 100 may include a unique stereocable engine 23 running on a separate component or on a unique computing machine capable of managing the other computing machines, as illustrated in figure 5. Figure 5 shows a unique stereocable engine 23 connected to the stereocable adapters 21 and to all the computing machines 22 to manage connections in the computer architecture 200.

The following description will be made with reference to a plug and play system 100 including one stereocable engine 23 associated with each computing machine 22 for illustrative purpose only, as represented in figure 2.

With reference to figure 2, each stereocable engine 23 associated with a corresponding machine 22 is adapted to process the roles assigned to that machine according to the information contained in the stereocable adapter 21 at deployment time. Each stereocable engine 23 is also provided to dynamically manage the computer architecture configuration based on computing machines related events in the computer architecture 200, like for example the deployment of a new virtual machine or the removal of an existing virtual machine in a computer architecture of the type virtual data center, using the stereocable adapters 21.

The stereocable adapters 21 may be stored locally in each computing machine 22, for example in a dedicated directory, or alternatively on external storage means such as a database. In the embodiments where the stereocable adapters are stored in the external storage device, the stereocable engine can be coupled to the storage device to retrieve the stereocable adapters through suitable communication means such as any known public or proprietary local or wide-area network like the Internet.

The plug and play system 100 according to the invention may further include a repository 24 thereinafter called "stereocable registry" to keep track of available sockets and provide them to plugs when requested based on constraints. The repository 24 may include one entry for each computing machine involved in a stereocable connection and, for each entry, a set of attributes comprising :

- a computing machine identifier "SystemID",

- a "stereocable" attribute identifying the stereocable connection (between the computing machine identified by "systemid" and the other computing machine involved in the connection), - a role attribute identifying the role (plug or socket) of the computing machine identified by SystemID for the stereocable connection.

Each entry in the registry 24 may further comprise other attributes such as :

- an environment attribute identifying the environment of the computing machine identified by SystemID,

- a name attribute identifying the name of the computing machine identified by SystemID,

- a " hostname" attribute identifying the hostname of the computing machine associated with the entry,

- a "port" attribute identifying the port of the computing machine associated with the entry, and

- a status attribute identifying the status of the computing machine (active or inactive).

Further, the repository may include a connection status attribute for the computing machines having a plug role to indicate if the stereocable connection is established ("connected" attribute).

The two entries below are exemplary entries stored in the repository 24 for a stereocable connection between a first virtual machine VM1 having a plug role and a second virtual machine VM2 having a socket role in a virtual computer architecture :

SYSTEMID: VM2

StereoCable: (TWS_UI , WS_SERVER)

Role: socket

Environment: TEST

Hostname : gciano . location . ibm . com

Port: 13331

Name: tws distributed

User: tws85mdm Status : active SYSTEMID: VM1

StereoCable: (TWS_UI , WS_SERVER)

Role: plug

Connected : VM2 : WS_SERVER

Status : active

Environment: TEST Alternatively, the computing machines 22 could directly publish the above information from the stereocable adapter and share the published information without requiring storage in a stereocable registry 24.

The plug and play system 100 may also comprise a user interface 25, thereinafter referred to as stereocable User Interface (UI) to dynamically generate a display of the computing machine connections from the plug and socket information maintained in the plug and play system 100. The stereocable user interface 25 can access the plug and socket information from the stereocable registry 24 or directly from the stereocable adapters loaded in the computing machines 22.

The plug and play system 100 may be also provided with a computer architecture manager 26 for managing the data flow exchanges in the computer architecture 200 (for example a virtual data center). In particular, the computer architecture manager 26 may store information related to events in the computer architecture, such as the creation of a new virtual machine, the removal of a virtual machine, or the publication/removal of a socket. The computer architecture manager 26 communicates information related to the events detected in the computer architecture 200 to the stereocable engines 23 through suitable communication means. Thereby the stereocable engines 23 are kept informed of the changes occurring in the computer architecture and may take into account these changes to manage cooperation between computing machines.

Once established at deployment time, the stereocable connections are managed dynamically by the plug and play system 100 throughout the components life-cycle. The stereocable engine 23 processes each new event (such as for example the deployment of a new virtual machine 22 or the removal of an existing virtual machine 22 in a computer architecture of the type virtual data center) in order to activate, remove or reactivate a connection.

The stereocable Engine 23 may also generate events when a socket is published, updated or removed in order to notify the change. Figure 6 shows a flowchart describing the initialization of stereocable connections at deployment time and the stereocable dynamic management during the computing machines life-cycle based on events generated in the computer architecture 200.

During the stereocable initialization phase, computing machines having socket roles for stereocable connections publish the information required by the socket definitions maintained in the stereocable adapters 21. From the published information, plug computing machines then establish cooperation with respective computing machines having the corresponding socket. The stereocable initialization phase also allows each computing machine having a plug role for a given stereocable connection to locate other computing machines playing the required socket role, retrieve the published socket information and execute the actions described in the plug definition.

More specifically, the Stereocable Engine 23 starts up the processing in step 601. The processing may be triggered at deployment time.

In step 602, it connects to the registry 24 to retrieve the information needed for the processing.

Step 602 may be performed using the registry auto-discovery if the protocol used by the Engine allows it, like for example SLP (Service Location Protocol).

In step 603, the stereocable engine retrieves the computing machine roles and the environments to which the computing machine belongs to from registry 24.

The registry 24 stores stereocable entries for the computing machines roles in the computer architecture, each entry for a given computing machine identifying a role (plug or socket), the stereocable connection between the computing machine and the other computing machine involved in the stereocable connection, and the environment to which the machine belongs to.

In step 604, the StereoCable adapter 21 associated with the computing machine is retrieved. In the embodiments where the stereocable adapters 21 are not stored locally in the computing machines, the stereocable engine 21 may retrieve the stereocable adapter 21 from the external storage device through suitable communication means and then store the retrieved stereocable adapter in the computing machine.

In step 605, the stereocable engine 23 processes the socket connections (phase A) associated with the computing machine. The socket connection processing phase is performed to publish the socket attributes of each socket role assigned to the computing machine and activate the corresponding socket.

In step 606, the stereocable engine 23 processes the plug connections (phase B). The plug connection processing phase is performed to process each plug role assigned to the computing machine and for each plug role, identify the other computing machines playing the required socket role, retrieve the published socket information and execute the actions described in the plug definition using the published socket information.

Once the initialization of the socket and plug roles assigned to the computing machine is completed, phase C (607) is performed to dynamically manage the stereocables based on the events generated in the computer architecture during the computing machine life-cycle.

Figure 7 is a flowchart illustrating phase A of processing the socket connections (step 605).

In step 701, the stereocable engine loads the Stereocable adapter 21 associated with the computing machine and disables the overall Stereocable functionality for the computing machine being processed. Disabling the Stereocable overall functionality will prevent other stereocable engines processing their plugs from accessing to incomplete socket information.

The following steps are performed for each socket role contained in the stereocable adapter 21 that is equal to one of the computing machine roles as identified in step 603 (step 702).

In step 703, the stereocable engine 23 checks if the socket section of the stereocable adapter defines a dependency condition between the considered stereocable and another stereocable ( in <condition> sub-section).. A dependency condition for a socket socketlDl could be for example express that the processing of socketlDl is subject to the state of another socket, such as "processing socketlDl only if another socket socketID2 is already active", or "processing socketlDl only if plugID4 is active". If the socket includes a dependency condition, the stereocable then checks if the dependency condition is satisfied. If the dependency condition is not satisfied, the socket is added to a working queue in step 704 for later processing in response to the reception of an event related to the publication of the considered socket. If the dependency condition is satisfied, then the socket attributes for the current socket are retrieved from the stereocable adapter in step 705.

In step 706, the socket attributes are published or expose. The socket attributes may be published in the registry 24 and the way they are published depends on the registry implementation technology. For example, if the registry depends on VMware technology (VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions), the VI (VMware Infratsructure) SDK may be used to publish the socket attributes, and if the registry is an SLP (Service Location Protocol) Directory Agent, publishing may be performed through SLP API (Application Programming Interface).

In step 707, the stereocable engine publishes information indicating that the socket is active

(socket status).

In step 708, an event is generated for the published socket. In the embodiment represented in figure 2, the event related to the published socket is sent to the computer architecture manager 26 that manages events emitted in the computer architecture 200. The computer architecture manager 26 is adapted to identify the stereocable engines 23 that are waiting for the socket publication to process the associated plug and to send the event related to the publication of the socket to these identified stereocable engines 23 so that they can start processing the plug.

In step 709, an entry related to the published socket in the registry 24 with a status attribute having an "active" value (e.g. "Status: active"). This entry may also include the published socket attributes such as the identifier of the computing machine having the socket role (e.g. "SYSTEMID:VM2"), the identifier of the stereocable (e.g. "StereoCable:(TWS_UI,TWS_SERVER)"), the role of the computing machine (e.g. "Role: socket"), the computing machine environment (e.g. "Environment: TEST"), and other attributes such as the computing machine hostname, port, name, and the user identifier.

The previous steps are repeated for each socket role in the stereocable adapter that matches one of the computing machine roles, as identified in step 603, by reiterating step 702 to 709. If all the socket roles have been processed, the processing of sockets is temiinated and the overall Stereocable functionality for the computing machine is enabled in step 710.

Figure 8 is a flowchart illustrating phase B of processing the plug connections (step 606).

For each plug role assigned to the considered computing machine, this processing B allows the computing machine to identify the connections that are to be established with other computing machines playing a socket role, retrieve the socket information published by these computing machines having the required socket role and execute the configuration actions described in the plug definition to establish the connections.

In step 801, the processing of plug connections is started.

In step 802, the stereocable engine accesses to the stereocable adapter 21 associated with the computing machine (loaded in the computing machine in step 604 if not locally stored in the computing machine).

The following steps are performed for each plug role in the stereocable adapter 21 that is equal to one of the computing machine roles as identified in step 603.

In step 804, the stereocable engine 23 checks if the plug comprises a dependency condition subsection defining a condition between the plug and other stereocables. If a dependency condition is included the stereocable engine 23 determines if the condition is satisfied. If the dependency condition is not satisfied, the plug is added to a working queue in step 805 for later processing.

If the dependency condition is satisfied, then the stereocable engine starts retrieving the socket information required by the current plug from the stereocable adapter in step 806. This includes discovering the computing machines to provide the required sockets that belong to the same environment and publishing information for the needed socket. If no computing machine having the required socket role is discovered in step 806, then the plug is added to a working queue in step 807.

The working queues in steps 703, 804 and 807 may form separate working queues or a unique queue stored locally where the stereocable engine runs.

Otherwise, either a unique computing machine or multiple computing machines having the required socket role may have been found in step 806. If multiple computing machines have been discovered in step 806 then in step 808 it is determined based on rules defined in the stereocable adapter 21 which computing machine is to be selected, such as for example "selecting the first found socket" or "selecting the socket based on the value of specific attributes".

In step 809, it is determined if the socket status is active for the identified computing machine having the required socket role using the registry 24. The identified computing machine refers either to the computing machine found in step 806 or to the computing machine selected in step 808 is multiple computing machines were discovered in step 806. If the status is active for the identified computing machine, the corresponding published socket attributes are retrieved from the registry 24 and the configuration actions as defined in the stereocable adapter for the plug role are invoked passing as parameters the published socket attributes. The configuration actions return a value that is checked by the stereocable engine. If the resulting value is successful the configuration has been successfully implemented otherwise it has not been implemented.

The information the plug is now active (plug status) and the plug attributes are then published in step 810.

In step 811, an event is generated for the published plug and sent to the computer architecture manager 26.

In step 812, an entry is added for the plug to the registry 24 with a status attribute set to "active". The entry may include a number of attributes including the identifier of the computing machine having the plug role (e.g. "SYSTEMID:VM1"), the stereocable identifier (e.g. StereoCable:(TWS_UI,TWS_SERVER)"), the computing machine role (e.g. "role:plug"), the computing machine environment (e.g. " Environment: TEST") and information indicating to which socket the plug is connected to (e.g. ." Connected: IMAGE2:TWS_SERVER")

The previous steps are repeated for each plug role in the stereocable that matches one of the computing machine roles, as identified in step 603, by reiterating steps 804 to 812.

If all the plug roles have been processed, the processing of plug connections is terminated

Figure 9 shows a flowchart for dynamically processing stereocables in the dynamic phase C (step 607).

The dynamic processing of stereocables is started in step 900. The dynamic processing of stereocables is performed to take into account events related to a stereocable connection that are generated in the computer architecture 200, such as when a change related to a connection occurs (e.g. removal of a computing machine), a socket becomes active, a computing machine becomes available, etc.

Step 901 starts collecting stereocable events (such as a socket creation, a socket removal, a socket publication/removal or virtual machine deployment/dismissal) and machine related events (such as Virtual Machine deployment, Virtual Machine dismissal, ...) for computing machines having specific roles (plug or socket). This step may be performed through a communication between the stereocable engine 23 and the computer architecture manager 26 in the embodiment represented in figure 2.

Step 902 determines if an event has been received as a result of step 901. If not, steps 901 and 902 are repeated periodically until an event is received in step 902.

If an event is received, the information related to the event is retrieved in step 903. This information may be provided by the computer architecture manager 26.

In step 904, it is determined if the received event is related to a stereocable present in the working queue, based on the event information retrieved in step 903.

If the stereocable is stored in the working queue, then in step 905 the stereocable is retrieved from the working queue.

In step 906, it is determined if the stereocable corresponds to a socket. If it is a socket, then the socket connection is processed in step 907 as described with reference to figure 7 (phase A).

Otherwise, if the stereocable corresponds to a plug, then the plug connection is processed in step 908 as described with reference to figure 8 (phase B).

If the stereocable is not found in the working queue (step 904), then in step 909 it is determined if the event is related to a stereocable for which an entry has been created in the registry 24. If not, the processing returns to step 902 until a new event is received.

Otherwise, if the stereocable registry 24 comprises an entry for the considered stereocable, then in step 910 the stereocable is retrieved from the registry. Step 91 1 then determines if the stereocable corresponds to a socket in step 912. If it represents a socket, then in step 912, a re-publish socket connection processing is performed (phase D). This case may occur for an event related to the discovery of a new computing machine that publishes an active requested socket or for an event related to the removal of a computing machine that publishes an active requested socket.

Otherwise, if the stereocable represents a plug, then in step 913, the plug connection is reprocessed (phase E). This case may occur for an event related to the removal of a computing machine that publishes a socket currently used by a plug having an entry in the Stereocable registry 24. Figure 10 is a flowchart describing the re-publication of a socket connection. (phase D). The republication of a socket connection may be triggered for example because some published information has changed.

In step 1001, the re-publish socket connection process D is started.

In step 1002, the stereocable engine loads the Stereocable adapter 21 associated with the computing machine and disables the overall Stereocable functionality for the computing machine.

In step 1003, the socket attributes of the active socket identified in step 911 for the received event are retrieved from the stereocable adapter.

In step 1004, the socket attributes are published or expose.

In step 1005, the information the socket is active (socket status) is published.

In step 1006, an event is generated for the published socket such as the exemplary event:

"Event_ID = STEREOCABLES_SOCKET_PUBLI SHED | STEREOCABLES_PLUG_PUBLI SHED |

P O VE RE D_0 F F | POVEREDJDN | REMOVED

Event_Info= plugID or socketID

Event Source = computing machine id

Event Date

Event Time"

In the embodiment represented in figure 2, the event related to the published socket is sent to the computer architecture manager 26.

In step 1007, the entry related to the published socket is updated in the registry 24.

In step 1008, the re-publishing socket connection processing is terminated.

Figure 11 is a flowchart describing phase E of re-processing of plug connections (step 913). Phase E may be triggered for example when a computing machine that contains a socket is removed from the environment so that the plugs connected to it need to look for a new socket in the environment to establish the connection.

In step 1101, the re-publish plug connection process D is started.

In step 1102, the Stereocable adapter 21 is loaded.

In step 1103, the configuration actions defined in the stereocable adapter for the active plug are invoked passing as parameters the published socket attributes of the associated socket. The published attributes are retrieved from the registry 24.

The information the plug is now active (plug status) is published in step 1104.

In step 1105, an event is sent for the unplugged plug. If the socket is no longer available the plug is no longer connected to it and then it is un-p lugged. In step 1106, an entry is added for the plug in the working queue. The plug connection is then processed in step 1107 according to phase A (figure 7).

In step 1108, the re-publishing plug connection processing is terminated.

Figure 12 illustrates an exemplary application of the invention to a computer architecture of the type virtual data center. Even if not limited to virtual computer architectures, the invention has particular advantages for such architectures.

As shown, the registry 24 stores a number of virtual machine entries 240 and 241, each entry for a virtual machine 22 identifying a role assigned to that machine for a given stereocable connection. For example, there is one entry 240 related to virtual machine VM2 ("TWS server") for a stereocable connection (TWS UI, TWS server) for which VM2 is assigned a SOCKET role in the environment TEST. The entry also specifies the socket attributes "hostname", "port", "name", "user". Another entry 241 is represented for virtual machine VM1 ("TWS UI) for the same stereocable connection (TWS UI, TWS server) in the environment TEST and indicates that VM1 is assigned a PLUG role for this connection. In accordance with the embodiments of the invention, in the stereocable initialization phase, VM2 will first retrieve its roles from registry 24 and publish or expose the socket attributes for socket TWS SERVER for the environment TEST. VM1 will retrieve its roles from the registry 24. As it is a TWS UI plug in the environment TEST it will retrieve the TWS SERVER socket information for the same environment. It will then execute the plug scripts and activate the cable or connection by performing the configuration actions using the published socket attributes.

Figure 13 and 14 illustrate different states of an exemplary stereocable user interface 25. The stereocable user interface 25 is used to display the Stereocable connections between the machines in the datacenter and to provide the detailed information about the established connections and the related plug and socket. In figure 10, it is shown that there is a stereocable connection SCI between ITM server and TWS master, and another connection SC2 between TWS server and TWS web user interface in the environment TEST. It shows that TWS server is assigned a socket role and that this socket is active, while ITM_UA is assigned a plug role, that plug being active. The stereocable user interface 25 may be dynamically generated from the data contained in the stereocable registry 24 or directly from data received from the machines.

The stereocable user interface 25 may be further provided with enhanced drag-and-drop capabilities in order to customize new stereocables. Figure 14 represents an exemplary stereocable interface 25 having such drag-and-drop capabilities. As shown, this interface allows the user to drag the disconnected virtual machine " ITM 6.2.1" to drop it to to "TWS 85". This action will create a new Stereocable between the two virtual machines. A list of possible stereocables already present in the registry may be shown or alternatively it may be possible to create a new stereocable from scratch. Accordingly, the invention provides an efficient solution for automatically configuring in a real plug-and-play fashion the products/components running in physical environments. Further, the invention also allows for automatically configuring in a real plug-and-play fashion the products/components running in new computing machines towards applications/components available in already deployed computing machines in the target environment.

In particular, the method and the system of configuring computer systems according to the invention allows to dynamically configure products/components according to a set of given configuration models and policies represented by the StereoCables structure. It is not required to predefine the roles assigned to each computing machine in a static way (Socket ID and Plug ID). On the contrary, each machine can retrieve its roles and its assigned StereoCables from the StereoCable engine at deployment time or during all its life cycle if there is a change affecting the stereocable connection.

The configurations described in the StereoCables may be established based on policies, such as for example policies that require supporting automatic configuration or prompting for a manual confirmation through the StereoCable User Interface, or satisfying a set of constraints (e.g. a plug can connect only to a socket with specific properties or a socket cannot support more than 100 plugs connected).

Once established the configuration is not static and can be dynamically managed and updated based on the events generated by the environment or actions triggered by the user from the StereoCable user interface (for example adding a new stereocable to a Virtual Machine).

The configuration actions, described in the StereoCable adapter can be started based on different trigger type, such as for example the following triggering events:

- publication, update or removal of a socket;

-deployment or removal of a virtual Machine;

- starting or stopping of a Virtual Machine, etc.

The configuration values are not statically defined but as described in the StereoCable structures they can be retrieved dynamically in different ways invoking local script, remote script, web service, etc. For example, a socket may publish some configuration information that are discovered and retrieved in real-time from the plugs that need them.

The embodiments of the invention also provide a real dynamic infrastructure, by generating and processing events that are not only generic like events (for example virtual machine startup/shutdown) but also (and specially) more granular events like for example:

- the publication of a new socket S 1 : in such case the machine holding a plug waiting for it will retrieve the exposed information and activates the needed configuration; - the update of a socket S2 : the machine already connected to it will retrieve the exposed information and will start the needed reconfiguration process; or

- the removal/deactivation of a socket S3 : the machine already connected to it will start the needed disconnection process and then restart the configuration process.

With the invention, the software applications may be dynamically connected and configured in a plug and play fashion to achieve common computing goals and/or exchange information. The configuration of the cooperating computing machines is automatically performed based on some values exposed or published by other computing machines. No manual configuration steps are required to allow cooperation between computing machines and achievement of common computing goals. The solution according to the invention ensures connections management not only at deployment time, but also at any time of the computing machine life-cycle, in a transparent way. Any change in the computer architecture that may impact a connection (already established or not yet established) in the computer architecture is taken into account to dynamically manage the cooperation between computing machines.

The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.

Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer- usable or computer readable medium can be any tangible apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer- readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.

A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.

Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers.

Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethemet cards are just a few of the currently available types of network adapters.

The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

Exhibit 1

<StereoCable>

<StereoCableID>StereoCableIDK/StereoCableID>

<Description>TWS UI Automatic Reconfiguration</Description>

<PlugSection>

<Description>T S UI Server</Description>

<PlugID>T S_UK/PlugID>

<ConfigurationActions>

<ConfigurationAction>

<Description>Description</Description>

<ID>ID</ID>

<Trigger>Deployment</Trigger>

<Action>

<ActionType>script</ActionType>

<ActionDetail>

<ConfigurationParameters>

<ConfigurationParamter>

<ConfigurationName>host</ConfigurationName> </ConfigurationParamter>

<ConfigurationParamter>

<ConfigurationName>port</ConfigurationName> </ConfigurationParamter>

<ConfigurationParamter>

<ConfigurationName>name</ConfigurationName> </ConfigurationParamter>

<ConfigurationParamter>

<ConfigurationName>user</ConfigurationName> </ConfigurationParamter>

</ConfigurationParameters>

<Operation>/pino/driver / scripts/ SUI . sh</Operation>

</ActionDetail>

</Action>

</ConfigurationAction>

</ConfigurationActions>

</PlugSection>

<SocketSection>

<Description>T S Master</Description>

<SocketID>TWS_SERVER</SocketID>

<PublishedParameters>

<ConfigurationParameter>

<ConfigurationName>host</ConfigurationName>

<ConfigurationValue>ncI25050. location . ibm. com</ConfigurationValue>

</ConfigurationParameter>

<ConfigurationParameter>

<ConfigurationName>port</ConfigurationName>

<ConfigurationValue>31117</ConfigurationValueX/ConfigurationParameter> <ConfigurationParameter>

<ConfigurationName>name</ConfigurationName>

<ConfigurationValue>tws-istributed</ConfigurationValue> </ConfigurationParameter>

<ConfigurationParameter>

<ConfigurationName>user</ConfigurationName>

<ConfigurationValue>tws 85mdm</ConfigurationValue>

</ConfigurationParameter>

</PublishedParameters>

</SocketSection>

</StereoCable>

Claims

Claims

1. A method for managing connections between computing machines in a computer architecture comprising :

- previously providing at least one connection management structure, said connection management structure including connection entries defining a role based connection between two computing machines, each connection entry defining a socket role assigned to one of said two computing machines, said socket role being associated with socket attributes representing the information that needs to be provided by the computing machine having the socket role to establish connection with the other computing machine, and a plug role assigned to the other computing machine, said plug role being associated with plug attributes representing the configuration actions that need to be executed by said other computing machine to establish connection with the computing machine having the socket role, and

-managing the connections among said computing machines in the computer architecture using said at least one connection management structure.

2. The method of claim 1, wherein said at least one connection management structure comprises configuration files loaded in each computing machine.

3. The method of any preceding claim, wherein said step of managing connections comprises at deployment time, for each computing machine, identifying each socket role assigned to said computing machine from said at least one connection management structure, and processing each identified socket.

4. The method of claim 3, wherein said step of processing each identified socket is subject to the satisfaction of a dependency condition for said socket and comprises queuing said socket, if the socket role assigned to said computing machine does not satisfy said dependency condition.

5. The method of any preceding claim 1 to 3, wherein said step of managing the connections comprises, in response to the reception of an event related to a connection entry of said at least one connection management structure, identifying if said connection entry is associated with a socket role and if so processing said identified socket.

6. The method of any preceding claim 3 to 5, wherein said step of processing an identified socket includes publishing the socket attributes associated with said socket in said at least one connection management structure.

7. The method of any preceding claim 3 to 6, wherein said step of processing an identified socket further includes publishing an active status for said published socket and generating an event for the published socket.

8. The method of any preceding claim, wherein said step of managing connections further comprises at deployment time, for each computing machine, identifying each plug role assigned to said computing machine from said at least one connection management structure, and processing each identified plug role.

9. The method of claim 8, wherein said step of processing each identified plug role is subject to the satisfaction of a dependency condition for said identified plug, and comprises queuing said identified plug, if said identified plug does not satisfy said dependency condition.

10. The method of any preceding claim, wherein said step of managing connections comprises, in response to the reception of an event related to a connection entry in said at least one connection management structure, identifying if said connection entry is associated with a plug role, and if so processing said identified plug.

11. The method of any preceding claim 8 to 10, wherein said step of processing each identified plug comprises identifying computing machines among the computing machines in the computer architecture having the socket role required by said plug from said at least one connection management structure.

12. The method of claim 11, wherein said step of processing each identified plug further comprises retrieving the published socket information associated with one selected computing machine among said identified computing machines having the required socket role and executing the configuration actions described in said plug using said published socket information.

13. The method of claim 12, wherein it further comprises publishing information related to said plug and an active status for said published plug, and generating an event for the published plug.

14. A computer program comprising instructions for carrying out the steps of the method according to any one of claims 1 to 13 when said computer program is executed on a suitable computer device.

15. A system adapted to carry out the steps of the method according to any one of claims 1 to

13.