JP2003108370A - Application system construction framework - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an application system construction framework that can flexibly correspond to the modification, addition, deletion or the like of a middleware product, and that is general-purpose and capable of performing functional decomposition. SOLUTION: The application system construction framework 100 is used as a construction platform for the construction of various application systems typified by an enterprise system. A common interface group 101 provides an interface for using each included in a middleware product group 11, and is prepared for every function commonly used in an application system 118. An implementation module group 105, in response to an access through each included in the common interface group 101, executes the function of the corresponding middleware product, and is implemented in correspondence with each included in a middleware product group 111. Besides, the middleware product group 111 provides various functions commonly used in the enterprise system or the like.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an application system construction framework (application system construction platform) configured by combining a plurality of middleware products that provide various functions.
In particular, it relates to a general-purpose and functionally partitionable application system construction framework that can flexibly deal with changes, additions, and deletions of middleware products.

[0002]

2. Description of the Related Art In the development of a large-scale enterprise system called an enterprise system, a method of constructing an application system using a framework for constructing an application system is often adopted.

Such an application system construction framework is generally a combination of commercially available middleware products that provide various functions commonly used in enterprise systems (eg, messaging function, transaction function, security function, etc.). It is composed by. By preparing such a framework in advance, it is not necessary to maintain and develop the base part each time an individual application system is developed, and focus only on the development of the parts unique to each application system. Therefore, the development cost of the entire system can be reduced.

[0004]

However, in the above-mentioned conventional framework for building an application system, the application system built using this framework is a unique API (A
Since it is implemented on the assumption that the pplication programming interface) is directly used, the AP used by the application system along with the change of middleware products (upgrading, replacement with another product, etc.)
There is a problem that I is changed and the application system needs to be modified.

Further, the conventional framework for building an application system as described above has a fixed structure, and middleware products can be installed in accordance with the functions required by the application system built using this framework. Since it cannot be added or deleted, depending on the application system being built,
There is a problem of using a heavy-duty application system construction framework that includes unnecessary functions. Specifically, for example, even when building an application system that does not require a transaction function, it is necessary to use an application system building framework that includes a transaction function.

The present invention has been made in consideration of the above point, and is a general-purpose application system capable of function division, capable of flexibly responding to changes, additions, deletions, etc. of middleware products. It aims to provide a framework for construction.

[0007]

According to the present invention, there are provided a middleware product group that provides various functions, a common interface group that provides an interface for using each of the middleware product groups, and a middleware product group. And an implementation module group that implements the functions of the corresponding middleware product in response to access via each of the common interface groups. To do.

In the present invention, the common interface group includes a plurality of function-specific common interfaces prepared for each function commonly used in the application system. It is preferable that a mounting module corresponding to the middleware product is provided. Further, it is preferable that the common interface for each function is prepared for each programming language used in the application system. Furthermore, it is preferable that the mounting module group includes a mounting module for realizing a migration process between application systems using different mounting technologies.

Further, the present invention is implemented corresponding to each of the middleware product groups that provide various functions, and through each of the common interface groups that provide an interface for using each of the middleware product groups. Provided is a program for building an application system, which is equipped with a mounting module group that executes the function of a corresponding middleware product in accordance with the accessed access.

According to the present invention, a common interface group for providing an interface for using each of the middleware product groups to the application system construction framework for constructing the application system, and the common interface group respectively are provided. Depending on the access made, the mounting module group that executes the functions of the corresponding middleware product is provided, so even if the middleware product needs to be changed, the mounting module can be replaced without changing the common interface. Can only be dealt with. Therefore, the application system is not affected by the change of the middleware product, and the used middleware product can be easily changed.

Further, according to the present invention, a plurality of function-specific common interfaces are provided for each function commonly used in the application system, and further, the implementation corresponding to each middleware product is provided for each function-specific common interface. By providing the module, the framework for building the application system can be easily divided for each function. For this reason, it is possible to easily add and delete functions accompanying the addition and deletion of middleware products, etc., and an application system construction frame with an optimal configuration that selects only the functions required for the application system delivered to the customer. Work can be provided.

Further, according to the present invention, since the common interfaces for each function of the common interface group are prepared for each programming language used in the application system, a general-purpose application system corresponding to a plurality of programming languages is provided. The construction framework 100 can be realized.

Furthermore, according to the present invention, since a migration module for performing migration processing between programs using different mounting technologies is provided as a mounting module, an application system can be used for migration between systems using different mounting technologies. Since the change work of No. is unnecessary, it is possible to reduce the migration work.

[0014]

BEST MODE FOR CARRYING OUT THE INVENTION Embodiments of the present invention will be described below with reference to the drawings.

First Embodiment First, referring to FIGS. 1 and 2, a first embodiment of an application system construction framework according to the present invention will be described.

As shown in FIG. 1, an application system construction framework 100 according to the first embodiment of the present invention is used as a construction base for constructing various application systems represented by an enterprise system. The common interface group 101, the mounting module group 105, and the middleware product group 111 are provided. The middleware product group 111 provides various functions commonly used in enterprise systems and the like (eg, messaging function, transaction function, security function, etc.).

Of these, the common interface group 101
Provides an interface for using each of the middleware product groups 111, and is used when implementing the application system 118. The common interface group 101 is prepared for each function commonly used by the application system 118. Specifically, the messaging function common interface 102, the transaction function common interface 103, the security function common interface 104, and the like are prepared by being classified into several functions.

Here, such function classification is performed so that the application system constructing framework 100 can be easily divided for each function as described later.
The functions provided by the middleware products 113, 115, 117 included in the middleware product group 111 may be matched. In general, as middleware products, many middleware products that provide a messaging function, middleware products that provide a transaction function, and the like are on the market, and it is advisable to match the categories of these commercially available middleware products.

On the other hand, standardization of such functional classification is also in progress, and CORBA (Common Object Request Brochure)
ker Architecture) peripheral technology specifications CORBA
Service, J2EE (Java (registered trademark) 2 Platform,
In Enterprise Edition), various standard interfaces are provided. Therefore, such a standard interface may be adopted as the common interface. Specifically, for example, J2EE classifies functions such as a messaging function, a transaction function, a database access function, and a name management function, and provides respective standard interfaces. Therefore, these standard interfaces are used as common interfaces. Adopt it.

The mounting module group 105 executes the function of the corresponding middleware product in response to the access via each of the common interface group 101, and is mounted corresponding to each of the middleware product group 111. ing. Note that the relationship between the common interface and the mounting module corresponds to the relationship between the interface class and the mounting class in object orientation. Therefore, when the common interface is used from the application system 118, the mounted module actually operates. Such a mechanism is a standard feature of the object-oriented programming language, and as will be described later, the mounting module can be realized by using the functions of the object-oriented programming language as they are.

Next, referring to FIG. 2, a method of implementing a portion related to the messaging function (messaging function common interface 102 and its mounted module group) in the application system construction framework 100 shown in FIG. 1 will be described.

Here, sendMessage (), which is a method for transmitting a message, is used as the messaging function common interface 102, and middleware products A1, A2, A3 are used as middleware products.
The case where (reference numerals 113, 202, 204) are used will be described as an example.

Here, it is assumed that the sendMessage () method of the messaging function common interface 102 has a character string message to be transmitted and an option option for transmission as arguments.

That is, void sendMessage (String message, int option) Is defined as.

On the other hand, middleware products A1 and A
2, a unique API for sending A3 messages,
It is assumed that it is as follows. In the middleware product A3, option setting and message transmission are performed by different methods.

[Middleware product A1] void send (Stri
ng message, int option) [Middleware product A2] void sendMessage (int optio
n, String message) [Middleware product A3] void setOption (int option) void sendMessage (String message) In this case, the implementation of the implementation module (that is, sendMessage () method) for each middleware product A1, A2, A3 is as follows. Can be realized in this way.

[Mounting module 106 for middleware product A1] void sendMessage (String message, int option) {send (message, option); // Calls the unique API of A1} [Mounting module 107 for middleware product A2] void sendMessage (String message, int option) {sendMessage (option, message); // Calls the unique API of A2} [implementation module 108 for middleware product A3] void sendMessage (String message, int option) {setOption (option); // Call the A3 unique API sendMessage (message); // Call the A3 unique API} That is, (1) the mounting module 106 for the middleware product A1
Then, the values (message and option) received as arguments are passed as they are, and the send () method, which is the unique API of the middleware product A1, is executed.

(2) In the mounting module 107 for the middleware product A2, the value (message
And option) are passed in the reverse order, and the sendMessage method, which is a unique API of the middleware product A2, is executed.

(3) In the mounting module 108 for the middleware product A3, the value (message
And option) are passed to the setOption () method and the sendMessage () method, which are the unique API of the middleware product A3, and executed.

Here, the argument option is numerical data, but the meaning may differ depending on the middleware product even if the value is the same. In such a case, it is advisable to provide each mounted module with a conversion table so that the value is converted and passed when the specific API is executed.

The mounting module is created as a mounting class for the common interface.

Here, assuming that the Java language is used, the messaging function common interface 10 is used.
The definition of 2 is as follows, for example.

Public interface MessagingCommonInterface {void sendMessage (String message, int option); // Other methods are omitted here} In this case, the mounting module 1 for the middleware product A1
06 can be an implementation class of the above-mentioned common interface (MessagingCommonInterface) by defining as follows.

Public class MessagingForA1 implements MessagingCommonInterface {void sendMessage (String message, int option) {send (message, option);} // Omit the other methods here}} Implement the implementation module created in this way In the case of Java language, the constituent class files are generally JA
It is provided collectively as an R file format archive file. Here, the archive of the mounting module 106 for the middleware product A1 is set to Al. jar
Al. By putting the jar in the given directory,
Al. The class group included in jar can be used as an implementation class for the messaging function common interface 102. That is, by accessing the messaging function common interface 102 from the application system 118, the Al. The method of the implementation class group included in jar is activated, whereby the middleware product A1 is used.

On the other hand, the archive of the mounting module 107 for the middleware product A2 is A2. jar. A
2. Since the classes included in jar are also created as implementation classes for the messaging function common interface 102, A1. A2. jar
By placing A2. jar
The class group included in is available as an implementation class for the messaging function common interface 102. That is, by accessing the messaging function common interface 102 from the application system 118, A2. The method of the implementation class group included in jar is activated, and thereby the middleware product A2 is used.

Therefore, A1. jar to A2. Only by replacing the middleware product with the jar, the middleware product actually used can be switched from A1 to A2 without changing the application system 118.

As described above, according to the first embodiment of the present invention, the application system construction framework 10 for constructing the application system 118.
0, a common interface group 101 that provides an interface for using each of the middleware product groups 111, and an implementation module group that executes the function of the corresponding middleware product according to access through each of the common interface groups 101. Since 105 is provided, even if you need to change middleware products,
It can be dealt with only by exchanging (replacement) the mounted module without changing the common interface. Therefore, the change of the middleware product does not affect the application system 118,
The middleware product used can be easily changed.

Further, according to the first embodiment of the present invention, a plurality of function-specific common interfaces are provided for each function commonly used in the application system 118, and further, each function-specific common interface is provided. Since the mounting module corresponding to each middleware product is provided, the application system construction framework 100 can be easily divided for each function. Therefore, it is possible to provide the application system construction framework 100 having an optimal configuration in which only the functions required for the application system 118 delivered to the customer are selected, and it is necessary to equip more than necessary for the construction of a small-scale system. It is possible to solve the problem that the price of the entire system increases due to the use of the application system construction framework 100. Specifically, for example, when building an application system 118 that does not require a transaction function, the middleware product B1 mounting module 109 and the middleware product B2 mounting module 110 shown in FIG. And the middleware product B1 and the middleware product B2 can be prevented from being attached to the application system construction framework 100. Therefore, the application system 118 constructed by using the application system construction framework 100 in which the transaction function is deleted is the entire system price (the price of the application system 118 and the application system 118 because the middleware products B1 and B2 are unnecessary). The price of the system construction framework 100 can be reduced. Also, since only one general-purpose application system construction framework 100 is prepared and only the necessary parts can be cut out and used according to the application system 118 to be constructed, The development cost and the development period can be reduced as compared with the case where the optimum application system construction framework 100 is developed for each application system 118.

Further, according to the first embodiment of the present invention, the application system construction framework 1
Since the configuration of 00 is independent for each function, it is easy to add necessary functions later according to the function expansion of the application system 118. Specifically, for example, consider an application system 118 that was constructed by using the application system construction framework 100 in which the transaction function is deleted because the transaction function is not required. It is assumed that a transaction function is required to expand the function of the application system 118. in this case,
A transaction function can be provided by adding an implementation module corresponding to the transaction function common interface 103 to the currently used application system construction framework 100 and further adding a middleware product that provides the transaction function. become. In this case, since it is not necessary to replace the entire application system construction framework 100 currently used, the cost associated with the migration of the base part becomes very small.

Furthermore, according to the first embodiment of the present invention, the configuration of the application system construction framework 100 is independent for each function, so that when a new technology or middleware product appears in the future, etc. It becomes easy to add a new function to the application system construction framework 100. That is, a new interface is added to the currently used application system construction framework 100 by newly defining a common interface for using the new function and further creating an implementation module corresponding to the common interface. Will be possible. In this case, since there is no need to change the conventional common interface and mounted module in the application system construction framework 100, the existing application system 118 constructed using the application system construction framework 100 does not need to be changed. , The effect of the change has no effect.

Second Embodiment Next, a second embodiment of the application system construction framework according to the present invention will be described with reference to FIG. Note that the second embodiment of the present invention is similar to FIG. 1 and FIG. 1 except that a common interface for each function of the common interface group is prepared for each programming language used in the application system. It is almost the same as the first embodiment shown in FIG. In the second embodiment shown in FIG. 3, the first embodiment shown in FIGS. 1 and 2 is used.
The same parts as those in the embodiment will be designated by the same reference numerals and detailed description thereof will be omitted.

In the above-described first embodiment, the programming language used in the application system 118 is not mentioned, but in order to make the application system construction framework 100 general-purpose, the application It should be able to support the various programming languages utilized by system 118. However, due to differences in each programming language (for example, differences in available data types)
It is difficult to define the common interface group 101 so that it can be used with the same usage (interface) in any programming language.

Therefore, in the second embodiment of the present invention, as shown in FIG. 3, a common interface (here, the messaging function common interface 102 will be described as an example) is an interface for each programming language. It will be configured as a set of. Then, the mounting module is prepared not only for each middleware product but also for each programming language. That is, the mounting module 303 for using the middleware product A1 in Java language, and the mounting module 3 for using the middleware product A1 in C ++ language.
06, ..., Mounting module 304 for using middleware product A2 in Java language, middleware product A
Implementation module 30 for using 2 in C ++ language
7 ..., and so on.

A mounting module for the same programming language, for example, middleware product A1 is Java.
The method of creating and registering the mounting module 303 for using the language and the mounting module 306 for using the middleware product A2 in the Java language are as described in the first embodiment. This can be done the same way in different programming languages.

On the other hand, the mounting module for each programming language is used by the application system 118 even if a plurality of mounting modules are mixed in the system due to the difference in the form of the execution file and the directory to be deployed so that the module can be executed. There is no mutual interference when doing. For example, an implementation module for using the middleware product A1 in Java language, and a middleware product A
The implementation module for using 1 in the C ++ language has a form defined in each language, that is, in the Java language, a class file or a J file that summarizes the class file.
It may be provided in a predetermined directory in the form of an AR archive file or a dynamic link library file in the C ++ language. This is also as described in the above-described first embodiment.

As described above, according to the second embodiment of the present invention, the function-specific common interfaces of the common interface group 101 are prepared for each programming language used in the application system 118, and therefore, the above description has been made. In addition to the operational effects of the first embodiment,
It is possible to realize a general-purpose application system construction framework 100 compatible with a plurality of programming languages.

In addition, according to the second embodiment of the present invention, a plurality of language-specific common interfaces are provided for each programming language used in the application system 118, and further, each language-specific common interface is provided with each interface. Since the mounting module corresponding to the middleware product is provided, the application system construction framework 100 can be easily divided for each programming language. Therefore, it is possible to separately provide an implementation module for a programming language that is not used by the application system 118 to be constructed, and the application system constructing framework 100 having an optimal configuration according to the application system 118 delivered to the customer. Can be provided.

Further, according to the second embodiment of the present invention, the framework 1 for application system construction is provided.
Since the configuration of 00 is independent for each programming language, when expanding the application system 118, if a programming language other than the currently used programming language is required, it was provided separately at the time of first delivery. It is possible to meet such a demand by adding an implementation module for a programming language.

Furthermore, according to the second embodiment of the present invention, since the configuration of the application system construction framework 100 is independent for each programming language, even if a new programming language appears in the future, It becomes possible to expand the application system construction framework 100 by adding mounting modules.

Third Embodiment Next, a third embodiment of the application system construction framework according to the present invention will be described with reference to FIG. Note that the third embodiment of the present invention is different in that the mounting module group includes a mounting module for realizing a migration process between application systems using different mounting technologies (distributed computing technology). Others are substantially the same as those of the second embodiment shown in FIG. In the third embodiment shown in FIG. 4, the same parts as those in the second embodiment shown in FIG. 3 are designated by the same reference numerals, and detailed description thereof will be omitted.

The application system represented by the enterprise system on which the present invention is based is often constructed as a heterogeneous distributed system. As a technology for constructing such a heterogeneous distributed system,
Java included in CORBA and Java language specifications
va RMI (Remote Method Invocation).
In general, these technologies are applied to different objects, and CORBA is often applied to a relatively large-scale system, and Java RMI is often applied to a relatively small-scale system. Therefore, the following migration work may occur.

(1) A prototype is created using Java RMI, and this is ported to a CORBA base to create a final system.

(2) When a large-scale system is constructed by integrating several subsystems created by using Java RMI, each subsystem is ported to a CORBA base and a large-scale CORBA-based system is constructed. To create.

(3) When a large-scale CORBA-based system consisting of several subsystems is built, some of these subsystems are made independent and another customer is provided as a small-scale system. May be provided to In this case, since it is a small system, CORB
It may be desirable to port and provide to Java RMI base instead of A base.

Thus, there is a high need for mutual migration between CORBA-based systems and Java RMI-based systems. In this case, the source code of the application system 118 may be modified and ported each time, but by preparing a migration module between common interfaces, the source code of the part that uses the common interface is left unchanged. It becomes possible to make a transition, and the transition cost can be reduced.

When using CORBA, first, C
ORBA IDL (Interface Definition Language)
Interface is defined using the language. next,
Generate the interface for the implementation language from this definition,
The procedure is to create a program using the implementation language. As the implementation language, Java, C ++, Smal
ltalk or the like can be used. Therefore, COR
BA IDL is an interface definition language that does not depend on the implementation language.

Here, description will be made assuming that the Java language is used as the implementation language. CORBA IDL
Is designed to be independent of the implementation language, so J
Data types and functions specific to the Java language that can be used in the Java language may not be available in CORBA IDL. The main ones are as follows.

(1) Java language and C, such as array
Data types that are used differently from ORBA IDL (2) Utility classes prepared in Java language such as Enumeration and Vector (3) Exception type with methods inside (Exception) (4) Overflow of methods Loading In the above-described second embodiment, a common interface different for each implementation language is defined, but when the Java language is used as the implementation language, CORBA is used as the distributed computing technology (implementation technology).
Or Java RMI,
Different common interfaces need to be defined. Therefore, as mentioned above, CORBA-based systems and Ja
In the case where mutual migration processing is performed with a va RMI-based system, it is necessary to perform conversion work for a portion that uses a common interface.

Therefore, in the third embodiment of the present invention, in order to reduce the trouble of such conversion work, FIG.
As shown in, a transition module between common interfaces is provided as a mounting module. That is, CORBA
If mutual migration is required between the base system and the Java RMI-based system, the CORBA-Java migration module 405 and the Java-CORBA migration module 406 are prepared. The CORBA-Java migration module 405 is a common interface 4 for CORBA.
It is realized as one of the 01 mounting modules. Similarly, the Java-CORBA migration module 406
It is realized as one of the mounting modules of the common interface 301 for the ava language. Also, Java RMI
Is included in the Java language specification, so Java
It is not necessary to prepare a common interface for va RMI, and a common interface for Java language 30
1 will be used.

Next, an example of a method of implementing the above-mentioned migration module will be described by taking the Java-CORBA migration module 406 as an example.

Java-CORBA migration module 40
In 6, the process of converting the data or the like sent through the Java language common interface 301 into a form suitable for the CORBA common interface 401 and passing it to the CORBA common interface 401 is performed. The conversion process performed here is the above-mentioned CO
This means conversion of data types and functions peculiar to Java language that cannot be used in RBA IDL.

First, as a first point, the handling of arrays will be described.

In CORBA IDL, arrays can only be defined as fixed length. However, in the Java language, if an interface such as void sendByteMessage (byte [] message, int option) is defined, the array message
The size of can be determined at run time. That is,
This interface can send both size 10 and size 100 messages. But CO
With the RBA IDL array, only an array of the size defined when the IDL was defined can be sent. To do this, CORBA IDL uses a variable-length array type called sequence. Therefore, in the migration module, the data passed in the form of array is sequen
The process of transferring to ce and passing it to the interface of CORBA is performed.

As a second point, the handling of utility classes prepared in Java language will be described.

In Java language, Enumeration and Vector
Utility classes such as are prepared and are often used in interfaces that return multiple data. However, CORBA IDL does not provide such a class, so an array or
It is necessary to define the interface so that it will be returned in the form of sequence. Therefore, in the migration module, the array or
Transfer the data returned from the CORBA interface in the form of sequence to Enumeration (or Vector) and use Enumeration in the client application.
Allow data to be referenced as (or Vector).

As a third point, handling of an exception type (Exception) will be described.

The Java language Exception can be internally defined with a method, like a normal class. However, CORBA IDL Exceptio
In n, you cannot define a method, but only retain data. Therefore, the migration module takes out the data set in the Exception passed from the CORBA interface, creates an object as necessary, and sets the value.

As a fourth point, handling of method overloading will be described.

In the Java language, it is possible to overload methods, that is, to define methods having the same name but different arguments in the same class. However, CORBA IDL does not support overloading. Therefore, when overloading is used in the Java language common interface, in CORBA IDL, the name of each method is changed or one method with the largest number of arguments is defined and processing is branched inside the method. I will take the method to let. For example, it is assumed that the following two methods are defined in the common interface for Java language.

Void sendMessage (String message); void sendMessage (String message, int option); On the other hand, in CORBA IDL, it is assumed that one method is called void sendMessage (String message, int option). In this method, when the value of the argument option is -1, the specification is such that the message is transmitted with the default option setting. In this case, in the migration module, if the sendMessage () method with two arguments
The RBA IDL method is called, but in the case of the sendMessage () method having only one argument, the CORBA IDL method is called with the second argument being -1.

By preparing a migration module for performing the above processing for each common interface such as a messaging function, a transaction function and a security function and adding them as respective mounting modules, migration work can be reduced. .

For example, when migrating the application system 408 using Java RMI to operate on the CORBA base, the migration process is performed in the following flow.

(1) The application system 408 using Java RMI calls the Java language common interface 301.

(2) The mounting module prepared as the mounting class of the Java language common interface 301 is executed. In this case, the implemented module to be executed is the Java-CORBA migration module 406.

(3) Data type conversion is performed in the Java-CORBA migration module 406, and the CORBA common interface 401 is called.

(4) CORBA common interface 4
The mounting module prepared as the mounting class of 01 is executed. In this case, the mounting module to be executed is the mounting module corresponding to the middleware product to be used, that is, the mounting module 403 for middleware product A2.

(5) The function of the middleware product A2 is called from the mounting module 403 for middleware product A2, and the processing requested by the application system 408 using Java RMI is executed.

In the above, Java RMI is used.
The migration module for migrating from CORBA to CORBA has been described, but the migration from CORBA to Java RMI can also be realized by performing the processing reverse to that described above. In addition, CORBA and Java RM
Migration technologies can be similarly created for technologies other than I.

According to the third embodiment of the present invention, a migration module for performing migration processing between programs using different distributed computing technologies (mounting technologies) is provided as a mounting module. Like systems and CORBA-based systems,
When migrating between systems using different distributed computing technologies (implementation technologies), the work of changing the application system (the work of converting the source code of the part that uses the common interface) is unnecessary, and the migration work can be reduced. For this reason, the prototype system created using Java RMI is finally
When it is provided as an RBA-based system,
Several Java RMI-based subsystems,
In the case of finally integrating into a large-scale CORBA-based system, etc., mutual migration between different distributed computing technologies can be performed by the system development method as described above.

The application system construction framework 100 according to the above-described first to third embodiments is used by being mounted on a computer system 10 as shown in FIG. 5, for example. The application system construction framework 100 is recorded on a computer-readable recording medium such as the flexible disk 21 or the CD-ROM 22, and is mounted on the computer system 10 via the flexible disk 21 or the CD-ROM 22. Is possible.

The computer system 10 includes a computer main body 11 housed in a casing such as a mini tower,
To read information from a display device 12 such as a CRT (Cathode Ray Tube), a printer 13 as a recording output device, a keyboard 14 and a mouse 15 as input devices, and a floppy (registered trademark) disk 21 as a recording medium. The floppy disk drive device 16 and the CD-ROM drive device 17 for reading information from the CD-ROM 12 as a recording medium.

The recording medium is not limited to a flexible disk or a CD-ROM, but a magnetic disk, an internal memory, a hard disk, an optical disk (CD-R, DV).
As long as the recording medium can record the framework and can be read by the computer, such as a D (Digital Versatile Disk)), a magneto-optical disk (MO (Magneto Optical)), a semiconductor memory, etc., the recording format is Either format may be used. The recording medium also includes a carrier wave when transmitted on a network and an information transmission medium.

Further, the recording medium is not limited to a medium independent of the computer, but includes a recording medium in which the framework transmitted by the LAN, the Internet or the like is downloaded and stored or temporarily stored.

Furthermore, the number of recording media is not limited to one, and when frameworks are recorded on a plurality of media,
The medium structure may be any as long as it is included in the recording medium here.

[0085]

As described above, according to the present invention, it is possible to easily change the middleware product to be used, without the influence of the change of the middleware product affecting the application system. In addition, the framework for building an application system can be easily divided for each function, and therefore, it is possible to easily add or delete functions accompanying addition or deletion of middleware products.

[Brief description of drawings]

FIG. 1 is a block diagram for explaining a first embodiment of a framework for building an application system according to the present invention.

FIG. 2 is a detailed block diagram of a portion related to a messaging function of the application system construction framework shown in FIG.

FIG. 3 is a block diagram for explaining a second embodiment of a framework for building an application system according to the present invention.

FIG. 4 is a block diagram for explaining a third embodiment of an application system construction framework according to the present invention.

FIG. 5 is a diagram showing an example of a computer system in which a framework for building an application system is installed.

[Explanation of symbols]

100 application system construction framework 101 common interface group 102-104, 301, 302, 401 common interface 105 mounting module group 106-111, 303-308, 402-404 mounting module 406, 407 migration module (mounting module) 112, 114, 116, 201, 203 Unique API of middleware product 113, 115, 117, 202, 204 Middleware product 118, 407, 408 Application system

Claims (5)

[Claims] 1. A middleware product group that provides various functions, a common interface group that provides an interface for using each of the middleware product groups, and a common interface group that is implemented corresponding to each of the middleware product groups. A framework for building an application system, comprising: an implementation module group that executes a function of a corresponding middleware product according to access via each of the common interface groups. 2. The common interface group includes a plurality of function-specific common interfaces prepared for each function commonly used in an application system, and each function-specific common interface corresponds to each middleware product. The application system construction framework according to claim 1, characterized in that a mounting module is provided. 3. The framework for building an application system according to claim 2, wherein the common interface for each function is prepared for each programming language used in the application system. 4. The mounting module group includes a mounting module for realizing a migration process between application systems using different mounting technologies.
The framework for building an application system according to claim 1. 5. According to access through each of common interface groups that are implemented corresponding to each of the middleware product groups that provide various functions and that provide an interface for using each of the middleware product groups. A program for building an application system, which is equipped with a group of mounting modules that execute the functions of the corresponding middleware products.