Tool for integrating applications for a data processing platform6064813Abstract The present invention relates to an application integration tool for integrating applications into a data processing platform which includes structure for hosting applications, making it possible for applications editors and customers having at least one application to integrate, to configure the services of the platform so that the application will be supported by the platform as soon as it is installed. The integration tool allows any application to be integrated to benefit automatically from the services offered by the platform as soon as it is installed, and facilitates the launching of applications at a plurality of sites. Claims We claim: Description BACKGROUND OF THE INVENTION
______________________________________
Domain Properties
______________________________________
Platform Distribution of the application to the
machines of PL
Management of the versions
Management of the size of the log files
associated with the application
Graphical Integration into the control panel
Incorporation of the commands into lines of
the application
Operations Scheduler of the program launching device
and administration of the automation
Management of print operations
Management of backups
Administration
Integration of event management
Integration of the analysis of log files for
sending events or executing commands
Integration of applications management
Transaction management
Data base management
Performance management
Accounting management and cost breakdown
High Management of the takeover of resources
Availability
with high-availability techniques
File restoration management
Security Access control management
Integration with firewalls (known security
devices)
______________________________________
In order to integrate APC into PL, the tool INTO executes a certain number of integration operations INTOPE. In FIG. 2, this integration is symbolized by showing APC, represented by an elliptical geometric shape, surrounded by the six domains D1 through D6 listed above. Once integrated, it includes added values belonging to all or some of the six domains, it being understood that it is not necessary to integrate it into all of them. Refer to FIG. 3a. The integration tool INTO comprises: means MSIG for entering information for integrating APC which allows it to be supported by all or some of the services SERV, means MCONV for converting the integration information into a set of commands SCRi for integrating the application into the services SERV. The means MSIG comprise: means MACQ for acquiring information on the properties of the application to be integrated, a graphical interface IGC for gathering this information and transmitting it to the conversion means. The conversion means MCONV comprise: software PROG which produces, from the properties information provided by the graphical interface, scripts SCR1, SCR2, SCR3, SCRi, SCRp specific to each service, which make it possible to integrate APC into the services SERV automatically. In order to better understand how the integration tool INTO is structured and how it operates, it is useful to recall the information indicated in the following paragraph. In order for a service application belonging to the set SERV to be configured with a command language, this application must be able to understand this language. This is even true in the case where most of the new applications have only one public interface that is graphical. These applications generally have either files (non public) which are configured through the graphical interface, or an internal command language known only to the developer, which is located downstream from the graphical interface. On the other hand, the tool according to the invention INTO requires that the configuration files and the command languages of the service applications be public. The description of these files and/or command languages is contained in a guide PG (abbreviation for Programming Guide) to be sent to the applications integrators in order to guarantee the stability of the operation of the application once it is integrated. In keeping with what has been summarized in the last two paragraphs, the information acquisition means MACQ are constituted by a set of forms, each of which corresponds to a predetermined service and is supplied to the software editor or to the human operator wishing to integrate the application APC. These forms can be, for example, placed on the INTERNET network or recorded on a data recording medium such as a magnetic disk, diskette, magnetic tape, CD-ROM, etc. Each form includes questions, to be filled in by the editor, concerning the properties of APC. Once the form has been filled in, it is introduced by means of the graphical interface IGC into the software PROG, which then generates a "script" SCRi. The execution of this script SCRi makes it possible to integrate this application APC into the service of SERV which is associated with the filled-in form. It can only take place after the installation of APC by the customer into the platform PL. It must be noted that the forms can be supplied by the manufacturer to its customers through an HTTP (Hyper Text Transfer Protocol) server belonging to the INTERNET network, by means of specific forms called "FORM" in the standardized language HTML (Hyper Text Mark-up Language) widely used in this network, and that the program PROG which generates the scripts can be a standardized CGI (Common Gateway Interface) program. Consequently, for each application APC to be integrated into PL, the software PROG generates a set of scripts SCRi (one script per service). These scripts are executed at the end of the installation procedure specific to PL, and they allow the installed application APC to be recognized by the services SERV (control panel, archives, event administration, security, etc.). Thus, the invention allows the customer to reduce the time required to integrate APC from several days to several minutes. The exact integration times, of course, depend on the level of integration, that is, the number and the complexity of the services into which it needs to be integrated. It must be noted that it is not always possible for the software PROG to generate an integration script SCRi for each service application. In this case, it is necessary to provide the editors with documentation which will allow them to develop the scripts themselves. II) DESCRIPTION OF A PARTICULAR EXEMPLARY EMBODIMENT For a better understanding of the invention, it is appropriate to illustrate it more precisely, choosing as the application APC an application based on the standard transaction monitoring program known by the name "TUXEDO", and choosing as the service "TROUBLESHOOTING", which is a service of PL that allows the administrators of "TUXEDO" applications to monitor them in real time, via a graphical interface and a control panel. "TUXEDO TROUBLESHOOTING", which is customarily designated by its abbreviated name TTH, makes it possible to supervise a plurality of TUXEDO applications from a central point, no matter what their physical locations in the network. It makes it possible, with a simple look at the control panel associated with the graphical interface, to view the operation of several TUXEDO applications, by displaying the status of the resources of each application (on or off). This service also detects serious events, analyzes the context of these events and proposes corrective action. It is assumed that in this particular exemplary embodiment, the application APC to be integrated into TTH is given the name "APPLI3" and that its integration must result in its automatically appearing in the control panel of TTH after its installation into PL. FIG. 4 illustrates the control panel of TTH before and after the integration of "APPLI3", with FIG. 4a showing the state of this control panel before the integration and FIG. 4b showing its state after the integration. As seen in FIG. 4a, before integration, TTH comprises two applications named "APPLI1" and APPLI2", and the control panel displays the status of their resources (ON or OFF) in boxes, of which there are 5 for the first application and 3 for the second. Thus it is possible to see that, for the first application, all of the resources, called Tuxedo, Machine, Servers, etc., are in operation (ON), whereas for the second one, the resources Machine and Network are in operation (ON) while the resource Tuxedo is out of operation (OFF). Likewise, it may be seen in FIG. 4b that after integration, TTH now includes "APPLI3" in addition to the two preceding applications "APPLI1" and "APPLI2", and that it displays the status of 5 resources, namely Tuxedo, Machine, Servers, Network and Queue, the first four of which are on while the last one is off. Appendix 1 shows the complete embodiment of the acquisition means MACQ (form) specific to TTH made available to the "TUXEDO" editor in order to be completed so as to start the operations INTOPE for integrating "APPLI3". This form includes 10 lines L1 through L10, each of which indicates the nature of the information to be provided (left column), the coded name of the latter (center column) which will be supplied to the software PROG and comments related to each of these pieces of information (right column). From the data on the form, which will be supplied by means of the graphical interface IGC of the tool INTO, the software PROG generates the script shown in Appendix 2. This script also includes 10 lines L1 through L10, which strictly correspond to the 10 lines of Appendix 1. In the case of a TUXEDO application, the script SCRi generated after the form is filled in will request the name of the connection to the platform PL of the administrator of the application APPLI3 as well as that of its master machine in the TUXEDO environment (within the framework of this standard, each application has a master machine). SCRi then creates a file called APPLI3 (see Appendix 2), which it will then place in a specific directory called "/var/madison/tuxedo/tga" known to the service TTH. TTH will then automatically use the file APPLI3.tux to support the new application APPLI3.
Appendix 1
__________________________________________________________________________
L1: APPLI3 The name of application to
Name be managed
L2: Administrator Connection name of the
administrator of the
application; If this field
cannot be filled in, the
question will be asked by the
integration script.
L3: Master Name of the Master machine
obtained by the command
"uname-n". If this field
cannot be filled in, the
question will be asked by the
integration script.
L4: Directory of
/usr/tuxedo usually "/usr/tuxedo"
the Tuxedo software
L5: Directory of
/flowbus/home/demofb1/bin
In this directory are: the
the Application executable files of the
application servers; the ASCI
configuration file (the file
UBBCONFIG or UBB) and the
binary configuration file
(TUXCONFIG).
L6: Absolute access
/flowbus/home/demofb1/data
for example:
path of the binary <directory.sub.-- of.sub.-- application>/
configuration file tuxconfig
L7: Configuration
/flowbus/home/demofb1/ubbc
If the access path is not
file of the specified, this file is
Application, entered into the directory of
in ASCII the application (APPDIR).
L8; Local language
C If the messages from the
Tuxedo catalog have not been
translated and adapted
(Localized), set this field at
"C" (capital C).
L9: Access path to
/flowbus/install/lib:/usr/
usually /usr/tuxedo/lib.
the library You can indicate several
separate access paths using
(colon).
L10: Environment
/flowbus/home/demofb1/envf
The access path of the file
file which contains the variables
to be added to the environment
for all the servers of the
machine (for example,
information on data
compression, load distribution
in the network, etc.).
Script Generation
__________________________________________________________________________
While the preferred forms and embodiments of the invention have been illustrated and described, it will be apparent to those of ordinary skill in the art that various changes and modifications may be without deviating from the inventive concept and spirit of the invention as set forth above, and it is intended by the appended claims to define all such concepts which come within the full scope and true spirit of the invention.
|
Same subclass Same class Consider this |
||||||||||