US20050038911A1 - Cooperative system and method therefor - Google Patents

Abstract

A cooperative system includes a plurality of information systems and a hub system connected to the plurality of systems. The hub system receives a message from a first information system, determines necessity of message conversion and a kind of conversion, converts the message to a form suitable for a second information system which is destination, only when message conversion is necessary, and transmits the message to a second information system. The hub system may determine whether flow control determining a flow and destination of a message received from the first information system based on a class of the message should be conducted, and conduct flow control only when it has been determined that flow control should be conducted.

Description

CROSS-REFERENCE TO RELATED APPLICATION
• This application relates to U.S. patent application Ser. No. 09/443102 filed on Nov. 18, 1999 and assigned to the present assignee, and U.S. patent application Ser. No. ______ being filed on ______ based on Japanese Application Serial No. 11-070623 filed on Mar. 16, 1999 and assigned to the present assignee. The contents of those applications are incorporated herein by reference.
BACKGROUND OF THE INVENTION
• The present invention relates to an inter-system cooperative system for implementing functional cooperation among a plurality of information systems, and a method therefor.
• Heretofore, information systems corresponding to various kinds of business have been developed and put to practical use. In recent years, attempts for implementing a wide variety of services by making those existing information systems cooperate have been made.
• FIG. 10 shows an example of conventional cooperation among information systems. Ateller system1001 is a system to be used when conducting various kinds of teller business in a teller shop. Anaccounting system1002 is a system to be used in a bank when giving services concerning giving and taking of money. Aninvestment trust system1003 is a system to be used in a securities company when giving services concerning investment trust. For example, it is now assumed that giving and taking of money has occurred in theteller system1001. In order to transmit its information from theteller system1001 to theaccounting system1002 and automatically conduct the giving and taking of money between predetermined accounts, it is necessary to connect theteller system1001 to theaccounting system1002 and make them operate in cooperation. Furthermore, in order to introduce anInternet banking system1004, connect each customer at aclient1005 to theInternet banking system1004 via Internet1006, and provide each customer with various kinds of bank service, it is necessary to connect theInternet banking system1004 to the accounting system of a bank and make them operate in cooperation.
• When connecting information systems and making them cooperative as heretofore described, individual coping has heretofore been conducted. In other words, information systems to be made cooperative are individually subjected to alteration (such as function addition) to become cooperative. However, there are a great variety of kinds of information systems, and the number of their connection combinations is also very large. In such a scheme that systems to be made cooperative are individually altered, the development is troublesome and rapid inexpensive diversification is difficult. Furthermore, if a system cooperating with a plurality of other systems, such as theaccounting system1002 ofFIG. 10 is altered, then other systems are largely affected and it is also considered that coordination cannot be effected among systems.
• In recent years, therefore, there has been proposed such a scheme that various information systems are connected to a system having functions of route control and message conversion and serving as a core and systems are made cooperative via the system serving as the core. Such a scheme is called hub and spoke, and the core portion is called hub. The configuration of the hub and spoke is disclosed in U.S. Pat. No. 5,193,056, Boes as well.
• FIG. 11 shows a connection example in the hub and spoke. Ateller system1102, anInternet banking system1103, acall center system1104, aninvestment trust system1105, a CRM (customer relationship management)system1106, anaccounting system1107, and so on are connected to ahub1101. Theteller system1102, theInternet banking system1103, theinvestment trust system1105, and theaccounting system1107 are similar to thesystems1001 to1004 described with reference toFIG. 10. Thecall center system1104 is a system of a so-called call center in which, for example, a toll-free telephone call originated by a customer is received by an operator and the operator operates the terminal to conduct various kinds of business in response to a request from the customer. TheCRM system1106 is a system for managing relations with customers. For example, commodities purchased by each customer in the past are stored in a DB (data base), and an optimum commodity is proposed according to the purchase situations. In this way, theCRM system1106 is a management system for building one-to-one proper relations with each customer.
• By connecting thesystems1102 to1107 to thehub1101, they can cooperate with each other without being conscious of other systems. For example, a message used by theteller system1102 to request another system to do business is first input to thehub1101. Thehub1101 passes a judgment on the opposite party system to which the message should be sent. Thehub1101 converts the message into a message having a protocol and a message form conforming to the opposite party system, and sends a resultant message to the opposite party. Since a difference between systems is thus absorbed by thehub1101, cooperation becomes easy by connecting systems to thehub1101. When constructing a new service, cooperation of systems can be easily implemented by defining a processing procedure for making the systems cooperative in the hub, without conducting alterations on the systems (or with conducting slight alterations concerning the user interface on the systems).
• For example, when an individual buys the investment trust commodity, typically there is needed such an operation that the individual withdraws money from the individual's saving account (withdraws money in the accounting system) and deposits the money in the investment trust system (sends the money to the investment trust system and buys the investment trust commodity). However, such processing extending over a plurality of systems can be defined in the hub easily. As a result, composite service through a teller shop and the Internet can be implemented. Also when the configuration of the system and the pattern of the cooperation are to be altered, it can be coped with by altering the definition stored in the hub. Alteration of one system exerts little influence upon other systems.
• Whatever message may be input to the above described conventional hub, the conventional hub determines a route, conducts protocol conversion and message conversion, and transfers a result to the opposite party system. This results in a problem that the duration of the message communication and the response time taken until an answer message is obtained are prolonged.
SUMMARY OF THE INVENTION
• An object of the present invention is to shorten the duration of the message communication through the hub and the response time taken until an answer message is obtained, in a “hub and spoke” system for implementing function cooperation among a plurality of information systems.
• In order to achieve this object, a cooperative system includes a plurality of information systems and a hub system connected to the plurality of systems. The hub system receives a message from a first information system, determines necessity of message conversion and a kind of conversion, converts the message to a form suitable for a second information system which is destination, only when it has been determined that message conversion is necessary, and transmits the message to a second information system. The hub system may determine whether flow control determining a flow and destination of a message received from the first information system based on a class of the message should be conducted, and conduct flow control only when it has been determined that flow control should be conducted.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 is a schematic diagram of a “hub and spoke” system of an embodiment of the present invention;
• FIG. 2 is a schematic diagram of an execution environment of the “hub and spoke” system;
• FIG. 3 is a diagram showing a system configuration example of a hub;
• FIG. 4 is a diagram showing an internal configuration of an adapter;
• FIGS. 5A, 5B and5C are diagrams showing three paths;
• FIG. 6 is a processing flow diagram of a client side adapter;
• FIG. 7 is a processing flow diagram of a server side adapter which receives a message via a specific protocol direct connection path;
• FIG. 8 is a processing flow diagram of a server side adapter which receives a message via an adapter direct connection path or a normal path;
• FIG. 9 is a diagram showing an example of a message given and received in the present embodiment;
• FIG. 10 is a diagram showing an example of conventional cooperation among information systems;
• FIG. 11 is a diagram showing a connection example in a conventional “hub and spoke”;
• FIG. 12 is a processing flow diagram for determining a path on the basis of a business code and a protocol;
• FIG. 13 is a processing flow diagram for determining a path on the basis of an amount of money of deposit;
• FIG. 14 is a diagram showing an example of association of connection systems with paths to be used;
• FIG. 15 is a processing flow diagram in the case where a path is determined on the basis of a connected system;
• FIG. 16 is a diagram showing an example of association of user classes with paths to be used; and
• FIG. 17 is a processing flow diagram in the case where a path is determined on the basis of a user class.
DESCRIPTION OF THE EMBODIMENTS
• (1) System Summary
• Hereafter, an embodiment of the present invention will be described by referring to drawing.
• FIG. 1 schematically shows a “hub and spoke” system. As information systems of client side, ateller system111, anInternet banking system112, and acall center system113 are connected to ahub100. As information systems of server side, anaccounting system121, aCRM system122, and aninvestment trust system123 are connected to thehub100. Thesesystems111 to113 and121 to123 are information systems for performing various kinds of business similar to those described in “BACKGROUND OF THE INVENTION.” Each of the systems is connected to the hub via a network such as a WAN or the Internet. Thehub100 includes one or more computers. The function of the hub is implemented by software executed by the computer(s).
• Thehub100 includesclient side adapters101, aservice finder102, a flow controller (or flow controllers)103, andserver side adapters104. These components basically exchange messages with each other via acommunication controller105 which is formed according to CORBA (Common Object Request Broker Architecture) specifications, which provides a distributed object environment. The CORBA is the name of a distributed processing environment architecture advocated by Object Management Group. As a protocol according to the CORBA specifications used in the hub, IIOP (Internet inter-ORB protocol) is well known.
• Theclient side adapters101 are provided so as to be associated with respective client side systems. Each of theclient side adapters101 has functions of channel I/F (interface) control between the client side adapter and the client side system, protocol conversion between a protocol of the client side system and a protocol of CORBA specifications in the hub, and message conversion between a message form of the client side system and a message form of a server side system which is the destination of the message.
• Theadapter101 may be provided for each protocol. Otherwise, one adapter may be associated with all systems.
• Theserver side adapters104 may be provided so as to be associated with respective server side systems. Each of theserver side adapters104 has functions of server I/F control between the server side adapter and the server side system, connection to a legacy system utilizing a wrapper, protocol conversion between a protocol of the server side system and a protocol of CORBA specifications in the hub, and message conversion between a message form in the hub and a message form of the server side system.
• Theadapter104 may be provided for each protocol. Otherwise one adapter may be associated with all systems.
• Theservice finder102 manages message routing information. For example, when acquiring the destination of a message received by theclient side adapter101 or theflow controller103, theservice finder102 is inquired of about the destination. Theflow controller103 provides composite service utilizing work management. In other words, when conducting cooperative processing in a plurality of servers in response to a message received by aclient side adapter101, theflow controller103 controls the flow of messages, i.e., controls whichserver side adapter104 the message should be transmitted to in which order. Such control may be accomplished by a plurality of flow controllers, each controller controlling a flow for one cooperative service.
• (2) Route of Message
• FIG. 2 schematically shows an execution environment of the “hub and spoke” system. Out of the system summary ofFIG. 1,FIG. 2 shows the software configuration of thehub100 and data flow in more detail. InFIG. 2, theteller system111 and ateller terminal204 are connected to thehub100 as client side systems. As server side systems, theaccounting system121 and theinvestment trust system123 are connected to thehub100. Theteller terminal204 is a so-called window terminal. Theteller terminal204 is a terminal for an operator to input various kinds of information at a teller window or a call center in response to a customer's request.Hubs201 and202 having different footholds are connected to thehub100. Amanager210 conducts operation management, system configuration management, and log acquisition specification control on various components in thehub100.
• A message transmitted from theclient side system111 or204 is transmitted to theserver side system121 or123 via thehub100. As message routes (paths), three paths are prepared in thehub100. The three paths are a normal path, an adapter direct connection path, and a specific protocol direct connection path.
• The path to be used is determined by each adapter on the basis of the received message. A method for determining the path will be described later.
• (2-A) Normal Path
• The normal path will now be described. Anadapter101bis an adapter associated with theteller terminal204. A message transmitted from theteller terminal204 is received by theadapter101b.Theadapter101bconverts the protocol of the message to a protocol in the hub by using aprotocol conversion function231. Theadapter101bthen inquires of theservice finder102 the destination of the message by utilizing a destination acquisition (destination inquiry)function232. Theservice finder102 manages configuration information ofadapters101a,101b,104a,and104b,and theflow controller103, and management information of a message destination system. In the case of the normal path, theservice finder102 orders transmission of the message to theflow controller103. Upon receiving the message, theadapter101bconducts message conversion by using amessage conversion function233 as occasion demands, and transmits the message to theflow controller103 by using a intra-hub message transmission andreception function234. In the case where theadapter101bconducts message conversion, theadapter101butilizes amessage conversion engine241 and acode conversion engine242 of acommon service240. As for processing conducted in thehub100, the processing history is recorded as a log by using alog acquisition function243.
• Methods of the message conversion and the protocol conversion are described in U.S. Pat. No. 5,187,787, Skeen et al., U.S. Pat. No. 5,257,369, Skeen et al., and U.S. Pat. No. 5,557,798, Skeen et al.
• According to the received message, theflow controller103 accesses some server side systems one after another in accordance with a determined flow, and conducts processing according to the message. Theflow controller103 determines a server side system to be accessed by inquiring of theservice finder102 and utilizing its management information. Theflow controller103 first accesses theaccounting system121 and conducts predetermined processing (261), and then accesses theinvestment trust system123 and conducts predetermined processing (262). In the access (261) to theaccounting system121, theflow controller103 sends a predetermined message to theadapter104aassociated with theaccounting system121, and obtains an answer message therefor. Thereafter, in the access (262) to theinvestment trust system123, theflow controller103 sends a predetermined message to theadapter104bassociated with theinvestment trust system123, and obtains an answer message therefor. Theflow controller103 processes the obtained answer message as occasion demands, and returns a resultant message to theoriginal adapter101b.Theadapter101bconducts necessary processing such as protocol conversion and message conversion, and returns an answer message to the associatedteller terminal204.
• The message transmitted from theflow controller103 by the access processing (261) to theaccounting system121 is received by an intra-hub message transmission andreception function274 of theadapter104aassociated with theaccounting system121. Theadapter104aconverts the protocol of the message from the protocol in the hub to a protocol of the accounting system205. As occasion demands, theadapter104athen conducts message conversion by using amessage conversion function273. Theadapter104athen transmits the message to theaccounting system121. According to the received message, theaccounting system121 conducts predetermined business processing. Theaccounting system121 then generates an answer message, and returns it to theadapter104a.Theadapter104areceives the answer message, converts the protocol of the answer message to the protocol in the hub by using theprotocol conversion function271, and inquires of theservice finder102 the destination of the answer message by using adestination acquisition function272. (Theadapter104amay store the massage source information in the memory when receiving the message, and use the information as the answer message destination.) Here, the destination is theflow controller103. As occasion demands, theadapter104aconducts message conversion by using themessage conversion function273. By using the message transmission andreception function274, theadapter104asends the answer message to theflow controller103 which is the request issuing source.
• A message transmitted by the processing of accessing the investment trust system123 (262) is received by theadapter104bassociated with theinvestment trust system123. Processing conducted in theadapter104 is similar to that conducted in theadapter104a,and consequently its description will be omitted.
• As heretofore described, in the normal path, a message issued by a client side system is subjected in a client side adapter to required conversion such as protocol conversion, and delivered to the flow controller. In a predetermined flow, the flow controller accesses a server side system via a server side adapter, and advances business processing. Between the client side and server side adapters and the flow controller, message transmission and reception are conducted by using the protocol in the hub (according to the CORBA specifications).
• The flow of control from the client to the server heretofore described is shown inFIG. 5A.
• (2-B) Adapter Direct Connection Path
• The adapter direct connection path will now be described by referring toFIG. 2. In the above described normal path, the flow controller can conduct processing with a plurality of servers made cooperative. In the case where the flow control is not required, however, a message can be sent from a client side adapter directly to a server side adapter by using the adapter direct connection path, without intervention of the flow controller. By taking the case where a message is to be sent from theteller system111 to theaccounting system121 as an example, the adapter direct connection path will be described hereafter. It is now assumed that a protocol used in theteller system111 is different from a protocol used in theaccounting system121.
• Theadapter101ais an adapter associated with theteller system111. A message transmitted from theteller system111 is received by theadapter101a.Theadapter101aconverts a protocol of the message to the protocol in the hub by using aprotocol conversion function221, and inquires of theservice finder102 the destination of the message by using a destination acquisition (destination inquiry)function222. In the case of the adapter direct connection path, theservice finder102 returns indication of an adapter of a server side system to which the message should be directly sent, as the destination of the message. Here, theadapter104aof theaccounting system121 is indicated as the destination. Upon receiving this, theadapter101aconducts message conversion by using amessage conversion function223 as occasion demands, and sends the message to theadapter104aassociated with theaccounting system121 by using an intra-hub message transmission andreception function224. Processing conducted in theadapter104ais the same as that described with reference to the normal path. However, an answer message is returned from theadapter104adirectly to theadapter101a.Arrows291 and292 ofFIG. 2 show message flows on the adapter direct connection path.
• As heretofore described, on the adapter direct connection path, a message issued by a client side adapter is transmitted directly to a server side adapter, and the message is not passed through theflow controller103. As compared with the normal path, therefore, the communication speed is fast and the response is also fast. On the above described adapter direct connection path, theclient side adapter101aconverts the protocol of theclient side system111 to the protocol in the hub (according to the CORBA specifications), and theserver side104aconverts the protocol in the hub to the protocol of theserver side system121. Instead of conducting such protocol conversion, theclient side adapter104amay convert the protocol of theclient side system111 to the protocol of theserver side system121, and send the message directly without intervention of the protocol in the hub. Since intervention of the protocol in the hub is thus obviated, communication can be conducted faster by that amount.
• The flow of control from the client to the server heretofore described is shown inFIG. 5B.
• (2-C) Specific Protocol Direct Connection Path
• The specific protocol direct connection path will now be described by referring toFIG. 2. On the above described adapter direct connection path, protocol conversion is indispensable because the protocol of the client side is different from that of the server side. In the case where the protocol of the client side is the same as the protocol of the server side, however, a message can be sent from a client side adapter directly to a server side adapter via the specific protocol direct connection path, without conducting protocol conversion. Hereafter, by taking the case where a message is sent from theteller system111 to theaccounting system121 as an example, the specific protocol direct connection path will be described. It is now assumed that a protocol used in theteller system111 is the same as a protocol used in theaccounting system121.
• A message transmitted from theteller system111 is received by theadapter101a.Theadapter101atransmits the message directly to theadapter104a.Theadapter104areceives the message. Theadapter104atransmits the received message toaccounting system121. An answer message is also returned via the specific protocol direct connection path in the same way.
• As heretofore described, on the specific protocol direct connection path, a message issued by a client side adapter is transmitted directly to a server side adapter, and protocol conversion is not required. In other words, communication is not conducted by using intra-hub message transmission and reception functions224 and274 for exchanging messages according to the CORBA, but communication is conducted directly with the protocol used in theteller system111 and theaccounting system121. As compared with the adapter direct connection path, therefore, the communication speed is further faster and the response is also fast. By the way, message conversion may be conducted in either aclient side adapter101aor101b,or aserver side adapter104aor104b,as occasion demands.
• The flow of control from the client to the server heretofore described is shown inFIG. 5C.
• (3) Determination of Path
• In (2), three paths have been described. A method for determining the path will now be described.
• FIG. 4 shows an example of adapter software. The client side adapters have the same configuration as the server side adapters. Each adapter is a function (program) mounted on an arbitrary computer included in the hub. Each adapter includes aprogram404 and a table407.
• Theprogram404 is divided into aprotocol dependence section405 and aprotocol non-dependence section406. Theprotocol dependence section405 includes amessage acceptance section451, apath decision section452, and aprotocol conversion section453. Theprotocol non-dependence section406 includes a destination inquiry (destination acquisition)section461, amessage conversion section462, and an intra-hub message transmission andreception section463.
• Themessage acceptance section451 of theprotocol dependence section405 conducts acceptance processing of a message issued by the protocol of a client side or server side system associated with this adapter. According to the accepted message, thepath decision section452 determines which of the normal path, the adapter direct connection path, and the specific protocol direct connection path should be utilized, on the basis of apath decision rule471. The protocol conversion section453 (corresponding to221,231,271, and281 ofFIG. 2) conducts conversion between the protocol of the client side or server side system and the protocol of the CORBA specifications in the hub. The above describedsections451 to453 are sections which need processing depending on the protocol of a client side or server side system associated with this adapter.
• The destination inquiry section461 (corresponding to222,232,272, and282 ofFIG. 2) of theprotocol non-dependence section406 conducts processing of inquiring of the service finder the destination of a message. On the basis of amessage conversion rule472, themessage conversion section462 conducts conversion of the message form between a message form of a client side system and a message form of a client side system. Since the message conversion can be conducted in an arbitrary position between the client and the server, it is sufficient that themessage conversion section462 is provided in either the client side adapters or the server side adapters. In some cases, the term “protocol” refers to not only the communication procedure in a physical layer but also conversion of the message form between systems, as a whole. However, it is now assumed that the term “protocol” does not include conversion of the message form. The intra-hub message transmission andreception section463 conducts message transmission and reception according to the protocol of the CORBA specifications in the hub. Thesections461 to463 heretofore described are sections for conducting processing which does not depend upon the protocol of the client side or server side system associated with the adapter. Thesections461 to463 are sections which operate on the CORBA.
• The sections heretofore described correspond to the functions ofFIGS. 5A to5C.
• FIG. 9 shows an example of a message given and received in the present embodiment. The message includescontrol information901, abusiness code902, and businessspecific information903. Thecontrol information901 is control information representing the source and destination of the message, message class, or data length and form. Thebusiness code902 is code information representing what kind of business the message requests. The businessspecific information903 is information specific to the requested business.
• Thecontrol information901 may include a path decision result conducted by the adapter and a flag indicating whether message conversion has already been conducted. (These kinds of information may be transmitted between programs in the hub by an internal protocol of the hub.)
• FIG. 6 shows the processing flow of a client side adapter. Upon accepting a message from a client side system atstep601, the client side adapter acquires the class of the message atstep602. Atstep603, the client side adapter conducts a path decision and may write a result into a control information field of the message. At this time, the client side adapter may refer to thepath decision rule471 ofFIG. 4. Subsequently, atstep604, the client side adapter determines whether the message is a message for specific protocol direct connection path. When the message is not a message for specific protocol direct connection path, the client side adapter converts its protocol to the protocol of the CORBA specifications which is being used in the hub atstep605, and inquires of the service finder the destination atstep606. Upon acquiring the destination from the service finder, the client side adapter transmits the message to its destination, i.e., to the flow controller or server side adapter atstep607, and finishes the processing. No matter whether the destination is a server side adapter of the adapter direct connection path or the flow controller of the normal path, processing except the destination remains unchanged in the client side adapter. The client side adapter conducts only processing of transmitting the message to the destination acquired from the service finder. When it is determined that the message is a message for the specific protocol direct connection path at thestep604, the client side adapter transmits the message via the specific protocol direct connection path atstep608 and finishes the processing.
• The path decision will now be described in detail by citing a plurality of examples.
• In the processing flow of the client side adapter ofFIG. 6, the path decision of thestep603 is conducted on the basis of thecontrol information901 and thebusiness code902 ofFIG. 9.FIG. 12 shows an example of a processing flow of the path decision. Atstep1201, thecontrol information901 and thebusiness code902 are read out from the message. Atstep1202, it is determined whether thebusiness code902 is “investment trust application.” If so, the normal path is selected as a decision result atstep1208. Otherwise, it is determined atstep1203 whether thebusiness code902 is “saving account deposit” or “saving account withdrawal.” If neither of them is the case, then it is judged atstep1207 that the associated path has not been found. If thebusiness code902 is either “saving account deposit” or “saving account withdrawal,” then it is determined atstep1204 whether the source and the destination have the same protocol. In the case of the same protocol, the specific protocol direct connection path is selected atstep1205. If the source and the destination do not have the same protocol, the adapter direct connection path is selected atstep1206.
• Relations between business codes and paths may be defined in a table form as thepath decision rule471. Further, information representing protocols used by respective systems (source and destination) is also stored in the path decision rule.
• As a variation ofFIG. 12, an example in which a path is determined according to the source and content of a message will now be described. In other words, the specific protocol direct connection path or the adapter direct connection path is provided as a specific path for special cases. All other cases are processed with the normal path. Although it depends on a message and a system configuration handled by the system, there is a possibility that the load converges on a part of the system in the case of the specific protocol direct connection path and the adapter direct connection path. Therefore, the use of the specific protocol direct connection path and the adapter direct connection path can be limited to the special cases.
• For example, when the business code is “saving account deposit,” the amount of money of deposit is set as business specific information. Therefore, it is possible to conduct a path decision depending on its amount of money. For example, the specific protocol direct connection path is used when the amount of money is at least a predetermined value, whereas the normal path is used when the amount of money is less than the predetermined value.
• FIG. 13 shows a path decision flow depending on the amount of deposit money of a saving account. Atstep1301, thecontrol information901 and thebusiness code902 are read out from the message. Atstep1302, it is determined whether thebusiness code902 is “investment trust application”. If so, the normal path is selected as a decision result atstep1312. Otherwise, it is determined atstep1303 whether thebusiness code902 is “saving account deposit”. If so, then an amount of deposit money in the message is read out atstep1304, and the amount of money is compared with a predetermined value atstep1305. If the amount of money is less than the predetermined value, then the normal path is selected atstep1306. If the amount of money is at least the predetermined value, then the processing proceeds to step1308. If the business code is not “saving account deposit” atstep1303, then it is determined atstep1307 whether the business code is “saving account withdrawal”. If the business code is not “saving account withdrawal”, then it is judged atstep1311 that the associated path has not been found. If thebusiness code902 is “saving account withdrawal”, then it is determined atstep1308 whether the source and the destination have the same protocol. In the case of the same protocol, the specific protocol direct connection path is selected atstep1309. If the source and the destination do not have the same protocol, the adapter direct connection path is selected atstep1310.
• At thestep1305, the following additional service may be provided. If the amount of money is less than a predetermined value at thestep1305, then on the contrary the specific protocol direct connection is used to conduct a simple service. If the amount of money is at least the predetermined value, then the normal path is used to put an advertisement on the client side and/or access such a system as to activate a customer analysis system.
• Furthermore, it is also possible to change the path to be used, according to the kind of a channel which accesses an adapter. This method is effective to the case where it is desirable to conduct especially processing from a specific channel at high speed, such as a teller terminal. For example, it is possible to pass only processing from a specific channel through the specific protocol direct connection path, and pass the same request from other channels through the normal path. By doing so, the load of the specific protocol direct connection path can be lowered. As a result, processing on the specific protocol direct connection path can be executed at higher speed.
• FIG. 14 shows an example of a table indicating paths of respective channels. A field of asystem1401 connected by the adapter indicates a channel which accesses the adapter. A field of apath1402 indicates the path used to process a request from a channel indicated by thefield1401. For example, it is indicated that a request from an adapter for automated teller machine is processed via the specific protocol direct connection path. This table is stored as a part of the path decision rule.
• FIG. 15 shows the processing flow in the case where the path to be used is changed according to the channel. Atstep1501, the adapter reads out a path associated with a requested channel from the table shown inFIG. 14. For example, upon receiving a request from an automated teller machine, the adapter acquires a record corresponding to the automated teller machine from thefield1401 of the table ofFIG. 14, and reads out a value of thepath field1402. Atstep1502, it is determined whether the value of thepath1402 indicates the specific protocol direct connection path. If so, the specific protocol direct connection path is selected atstep1508. If the path is not the specific protocol direct connection path, then it is determined atstep1503 whether the path is the adapter direct connection path. If so, the adapter direct connection path is selected atstep1507. If the path is not the adapter direct connection path, it is determined atstep1504 whether the path is the normal path. If so, the normal path is selected atstep1506. Otherwise, it is judged atstep1505 that the associated path has not been found.
• Furthermore, by using user information in the path decision rule, processing from a specific customer can be processed at high speed. For example, only requests from excellent customers can be processed by using the specific protocol direct connection path.FIG. 16 shows an example of a table indicating association of user information with paths. A field ofuser information1601 indicates user classes. For example, theuser information field1601 indicates a class such as an own bank user, another bank user, or a large income earner. Thepath field1602 indicates a path to be used for each user class. For example, the own bank user can be set so as to use the specific protocol direct connection path.FIG. 17 shows a processing flow in the case where the path to be used is changed according to the user information. Atstep1701, user information is read out from a message, and the user class is judged. Atstep1702, a path associated with the user class is read out from the table ofFIG. 16. For example, if the user is an own bank user, then a record corresponding to the own bank user is acquired from theuser information field1601, and a value of thepath field1602 is read out. Atstep1703, it is determined whether the value of thepath field1602 indicates the specific protocol direct connection path. If so, the specific protocol direct connection path is selected atstep1709. If the value of thepath field1602 does not indicate the specific protocol direct connection path, then it is determined atstep1704 whether the path is the adapter direct connection path. If so, the adapter direct connection path is selected atstep1708. If the path is not the adapter direct connection path, it is determined atstep1705 whether the path is the normal path. If so, the normal path is selected atstep1707. Otherwise, it is judged atstep1706 that the associated path has not been found.
• The rule of such a path decision is set in thepath decision rule471 ofFIG. 4 beforehand.
• Processing of a server side adapter will now be described. By, for example, checking thecontrol information901 of a received message, the adapter can know the path via which the message has been transmitted.
• FIG. 7 shows a processing flow of a server side adapter which receives a message via the specific protocol direct connection path. Atstep701, a message is received. Namely, the message is received by the dependence section (405 ofFIG. 4) which conducts processing depending upon a specific protocol which is a protocol specific to a client or a server. Atstep702, the dependence section transmits the message to a server side system by using the specific protocol. If an answer message representing a result of business processing is returned from the server side system, the answer message is received atstep703. Atstep704, the dependence section returns the answer message to a client side adapter of the calling source. The processing is thus finished.FIG. 7 shows the case where message conversion is not conducted. When message conversion is required, however, the message conversion may be conducted in the processing ofFIG. 7.
• FIG. 8 shows a processing flow of a server side adapter which receives a message via the adapter direct connection path or the normal path. Atstep801, a message is received. This is processing of receiving a message by using the protocol of the CORBA specifications which is being used in the hub. This is reception of a message conducted by the intra-hub message transmission andreception section463 of thenon-dependence section406 shown inFIG. 4. Subsequently, atstep802, it is determined on the basis of the message class and the flag in the message whether message conversion is necessary. If necessary, the message conversion is conducted atstep803. Subsequently, atstep804, the message is delivered from the non-dependence section to the dependence section (405 ofFIG. 4). Atstep805, the dependence section converts the protocol to a protocol specific to the server, and transmits the message to the server side system. If an answer message representing a result of business processing is returned from the server side system, the answer message is received atstep806. Atstep807, the dependence section converts the answer message to a message having the protocol of the CORBA specifications in the hub. Atstep808, the non-dependence section returns the answer message to a client side adapter of the calling source. The processing is thus finished. As for the answer message as well, the message conversion may be conducted as occasion demands.
• (3) Form of System
• FIG. 3 shows a system configuration example of the hub in the present embodiment described with reference toFIGS. 1 and 2. Here, the hub is formed of three computers (hub servers)301 to303. Furthermore, servers and clients share the computers. (A server or client has a part of the hub function.)
• On thehub servers301 to303, OSs (operating systems)311,321 and331 and CORBAs312,322 and332 are mounted. In thehub server301, there are operating aclient program313, a clientside adapter program314, a serverside adapter program315, and aserver program316. In thehub server302, there are operating afinder program323, aflow control program324, a serverside adapter program325, and aserver program326. In thehub server303, there are operating acommon service program333, a clientside adapter program334, aclient program335, and aserver program336.
• Theclient programs313 and335 are programs for implementing the client side systems described with reference toFIGS. 1 and 2. The clientside adapter programs314 and334 are programs for implementing the client side adapters described with reference toFIGS. 1 and 2. The serverside adapter programs315 and325 are programs for implementing the server side adapters described with reference toFIGS. 1 and 2. Theserver programs316,326, and336 are programs for implementing the server side systems described with reference toFIGS. 1 and 2. Thefinder program323 is a program for implementing the finder described with reference toFIGS. 1 and 2. Theflow control program324 is a program for implementing the flow controller described with reference toFIGS. 1 and 2. Thecommon service program333 is a program for implementing the common service described with reference toFIG. 2.
• These programs operate on an appropriate number of computers connected by a LAN (local area network). In the case where the hub is formed of a plurality of computers, arbitrary programs can be made to operate on each computer. Furthermore, each program can be distributed in function to a plurality of computers on CORBA. Theclient programs313 and335 and theserver programs316,326, and336 are programs for conducting individual business processing, and they are not included in the hub. However, the clients and servers may be mounted on computers forming the hub. Therefore, such an example is shown inFIG. 3. Each of the clients and servers may have a specific terminal using special hardware.
• As another example, the hub may be implemented by using one or more independent computers as shown inFIG. 1.
• In any case, it is desirable to distribute the function of the hub so as not to concentrate the load on a part of computers and network lines.

Claims (18)

1. An inter-system cooperative system, connected to a plurality of information systems, including a plurality of paths, for cooperatively operating the information systems using the paths to perform a plurality of businesses, comprising:

storage means for storing a path decision rule defining a path for performing each of the businesses,

message acceptation means for receiving a message relating to one of the plurality of businesses from a first information system in the information systems, the message including a business code identifying the one business and a control information indicative of a destination of the message;

path selection means for selecting one of the paths for performing the one business identified by the business code using the path decision rule;

system specifying means for specifying at least one second information system in the information systems as a message destination using the control information; and

message sending means for sending the message to the second information system via the selected path,

wherein the respective paths provide different functions relating to the message and one of the paths provides no function relating to the message.

2. The inter-system cooperative system according toclaim 1, wherein the paths include a direct path and a normal path, the path selection means selects the normal path when the system specifying means specifies at least two information systems as the second information systems, and selects the direct path when the system specifying means specifies one information system as the second information system.

3. The inter-system cooperative system according toclaim 2, further including flow control means for controlling a flow of the received message to provide a composite service as the business using a flow management, the flow control means being provided on the normal path as one of the functions.

4. The inter-system cooperative system according toclaim 3, wherein the flow control means controls an order of a delivery of the message to the second information systems in response to the reception of the message.

5. The inter-system cooperative system according toclaim 2, wherein the direct path includes an adapter direct connection path and a specific protocol direct connection path, protocol conversion means for converting a protocol of the message being provided on the adapter direct connection path as one of the functions, and the path selection means selecting the adapter direct connection path to convert the message when determining that protocol conversion is necessary for communicating between the first information system and the second information system by referring to the control information.

6. The inter-system cooperative system according toclaim 2, wherein the business is a financial transaction, the path selection means selecting the direct path when the second information system is an accounting system and the business code is deposit or withdrawal of a savings account, and the path selection means selecting the normal path when the second information systems are an accounting system and an investment trust system and the business code is an application of a investment trust.

7. A method for cooperatively operating information systems using paths to perform a plurality of businesses, comprising:

storing a path decision rule defining a path for performing each of the businesses;

receiving a message relating to one of the plurality of businesses from a first information system in the information systems, the message including a business code identifying the one business and a control information indicative of a destination of the message;

selecting one of the paths for performing the one business identified by the business code using the path decision rule;

specifying at least one second information system in the information systems as a message destination using the control information; and

sending the message to the second information system via the selected path,

wherein the respective paths provide different functions relating to the message and one of the paths provides no function relating to the message.

8. The method according toclaim 7, wherein the paths include a direct path and a normal path, the normal path being selected when at least two information systems are specified as the second information systems, and the direct path being selected when the one information system is specified as the second information system.

9. The method according toclaim 8, further including controlling a flow of the received message to provide a composite service as the business using a flow management, the flow control being provided on the normal path as one of the functions.

10. The method according toclaim 9, further comprising controlling an order of a delivery of the message to the second information systems in response to the reception of the message.

11. The method according toclaim 8, wherein the direct path includes an adapter direct connection path and a specific protocol direct connection path, protocol conversion for converting a protocol of the message being provided on the adapter direct connection path as one of the functions, and selecting the adapter direct connection path to convert the message when determining that protocol conversion is necessary for communicating between the first information system and the second information system by referring to the control information.

12. The method according toclaim 8, wherein the business is a financial transaction, and further comprising selecting the direct path when the second information system is an accounting system and the business code is deposit or withdrawal of a savings account, and selecting the normal path when the second information systems are an accounting system and an investment trust system and the business code is an application of a investment trust.

13. An apparatus comprising a storage medium with instructions stored therein for cooperatively operating information systems using paths to perform a plurality of businesses, the instructions when executed causing a processing device to perform:

storing a path decision rule defining a path for performing each of the businesses;

receiving a message relating to one of the plurality of businesses from a first information system in the information systems, the message including a business code identifying the one business and a control information indicative of a destination of the message;

selecting one of the paths for performing the one business identified by the business code using the path decision rule;

specifying at least one second information system in the information systems as a message destination using the control information; and

sending the message to the second information system via the selected path,

wherein the respective paths provide different functions relating to the message and one of the paths provides no function relating to the message.

14. The apparatus according toclaim 13, wherein the paths include a direct path and a normal path, the normal path being selected when at least two information systems are specified as the second information systems, and the direct path being selected when the one information system is specified as the second information system.

15. The apparatus according toclaim 14, further performing controlling a flow of the received message to provide a composite service as the business using a flow management, the flow control being provided on the normal path as one of the functions.

16. The apparatus according toclaim 15, further performing controlling an order of a delivery of the message to the second information systems in response to the reception of the message.

17. The apparatus according toclaim 14, wherein the direct path includes an adapter direct connection path and a specific protocol direct connection path, protocol conversion for converting a protocol of the message being provided on the adapter direct connection path as one of the functions, and selecting the adapter direct connection path to convert the message when determining that protocol conversion is necessary for communicating between the first information system and the second information system by referring to the control information.

18. The apparatus according toclaim 14, wherein the business is a financial transaction, and further performing selecting the direct path when the second information system is an accounting system and the business code is deposit or withdrawal of a savings account, and selecting the normal path when the second information systems are an accounting system and an investment trust system and the business code is an application of a investment trust.

Images