Abstract initiator

[0002] The present invention relates generally to a system and method for transferring documents and files, and more particularly to a system and method for decoupling a transfer protocol from a central file transfer system.

[0003] In a corporate environment, a network system enables users throughout the corporation to share files, such as business documents or mail messages. This sharing may be enabled through a system using, for example, an electronic data interchange (EDI). Such a system can also be referred to as a message broker or integration broker. The message broker may be implemented on a server in the network system of the corporate environment. To protect the network system from undesired external access, a firewall may be implemented as a gateway to and from the network system.

[0004] In addition to sharing files within the network system of the corporate environment, the message broker allows the files to be shared with entities external to the network system. This sharing is particularly useful in a business-to-business relationship. For example, it may be useful to share sales information or invoicing between a supplier business and a manufacturing business.

[0005] To share files with external entities, the message broker utilizes a transfer protocol. Known transfer protocols include, for example, the file transfer protocol (FTP), the simple mail transfer protocol (SMTP) and the hypertext transfer protocol (HTTP). As their names suggest, FTP is typically used for transferring files, and SMTP is typically used for transferring mail messages. HTTP is typically used for transferring data for web pages.

[0006] FIG. 1 is a block diagram of a conventional file transfer system 10. As shown in FIG. 1, the file transfer system 10 includes a network 20. Within the network 20 is a server 30, which is connected to a plurality of client terminals 50 and another server 45, to which is also connected a plurality of client terminals 50. A message broker 40 is implemented on the server 30.

[0007] A firewall 60 is coupled to the server 30 of the network 20. Trading partners 80, which correspond to entities external to the network 20, are coupled to the firewall 60. The message broker 40 can transfer data, such as a file using FTP, using a more direct connection for the trading partners 80 that are coupled directly to the firewall 60. Such a direct connection may be useful for high volume strategic trading partners. The firewall may also be coupled to a value added network (VAN) 70. The VAN 70 allows the message broker to transfer data to more remote trading partners 80.

[0008] Before establishing a connection with a trading partner 80, the message broker 40 is typically programmed to create a profile indicating the transfer protocol to be used with the trading partner 80. To establish the connection, the message broker 40, which includes routines integrated within the message broker 40 to transfer the data according to the various transfer protocols, refers to the profile to identify the appropriate transfer protocol. For example, if the message broker 40 is implemented in a network 20 for a supplier, the message broker 40 may be programmed to transfer files, such as invoices or purchase orders, to a trading partner 80 using FTP.

[0009] A problem with the conventional file transfer system 10 using a message broker 40 arises when the message broker 40 attempts to transfer data using a transfer protocol that the message broker 40 does not support. In other words, the message broker 40 does not include the integrated routine for transferring data with the transfer protocol identified in the profile. To overcome this problem, it is necessary create a new version of the message broker 40 by reprogramming the application underlying the message broker 40 to integrate the routines necessary for supporting the identified transfer protocol into the message broker 40.

[0010] In one aspect consistent with the present invention, a method for transferring data from a first computer in an internal network to a second computer outside of the internal network identifies a transfer protocol for transferring the data from the first computer and creates an instance of an initiator which supports the identified transfer protocol. A connection request is transferred to the instance of the initiator, which establishes a data connection from the first computer to the second computer in response to the connection request. The data is transferred across the data connection according to the identified transfer protocol.

[0011] In another aspect consistent with the present invention, a system for transferring data from a first computer in an internal network to a second computer outside of the internal network comprises a message broker, located in the internal network, which identifies a transfer protocol for transferring the data from the first computer to the second computer. The system further comprises one or more initiators, each initiator supporting a different transfer protocol, and an interface passing information between the message broker and the initiators. The message broker creates an instance of the initiator supporting the identified transfer protocol and transmits a connection request to the instance of the initiator via the interface. The instance of the initiator establishes a data connection from the first computer to the second computer in response to the connection request and transfers the data across the data connection according to the identified transfer protocol.

[0012] FIG. 1 is a block diagram of a conventional file transfer system.

[0013] FIG. 2 is a block diagram of a message of a file transfer system consistent with the present invention.

[0014] FIG. 3 is a flow diagram of a file transfer process consistent with the present invention.

[0015] FIG. 4 is a flow diagram of another file transfer process consistent with the present invention.

[0016] FIG. 2 shows a block diagram of a file transfer system 100 consistent with the present invention. As shown in FIG. 2, the file transfer system 100 includes an internal network 110 and an external network 150. Internal network 110 includes a message broker 120, an application programming interface (API) 130 and an initiator 140. Although shown as a single element, initiator 140 can, in fact, be representative of multiple initiators.

[0017] The API 130 and the initiator 140 are used in conjunction with the message broker 120 to transfer data from the internal network 110 to the external network 150. Each transfer protocol that may be used to transfer data from the internal network 110 to the external network 150 is supported by a respective initiator 140. The initiator 140 is preferably programmed in an object-oriented language, such as Java or C++, although other programming languages are possible. The initiator 140 is preferably implemented as a plug-in application that communicates with the message broker 120 via the API 130.

[0018] The API 130 is preferably programmed in the same language as the initiator 140. The API 130 provides information from the message broker 120 to the initiator 140, which enables the initiator 140 to establish communication with the external network 150. The information provided to the initiator 140 via the API 130 includes any information that may be needed by a particular transfer protocol to establish a data connection with the external network 150. This information includes, for example, the IP address of the target location and the port number, as well as other values.

[0019] The information transferred from the message broker 120 via the API 130 may include information that is not needed by the particular transfer protocol supported by the initiator 140. Any information provided to the initiator 140 that is not needed to establish the data connection according to the particular transfer protocol is merely ignored. For example, information corresponding to the message type may not be needed for the FTP transfer protocol.

[0020] After establishing the connection, the initiator 140 passes data between the message broker 120 and the external network 150. The data from the initiator 140 to the external network 150 is passed according to the transfer protocol supported by the initiator 140. The data from the initiator 140 to the message broker. 120 is passed according to a generic protocol supported by the API 130, which is discussed below in more detail.

[0021] By using a generic protocol to provide communication between the initiator 140 and the message broker 120, each initiator 140 can be programmed to support a particular transfer protocol and communicate with the message broker according to the generic protocol supported by the API 130. In addition, the message broker 120 does not need to know the particularities of the transfer protocol supported by the initiator 140. Rather, the message broker 120 only needs to be programmed to communicate with the initiator 140 using the generic protocol provided by the API 130. The message broker 120 can provide the same information to each initiator 140, regardless of the transfer protocol supported by that initiator. Accordingly, the communication between the initiator 140 and the external network 140 is protocol dependent, whereas the communication between the initiator 140 and the message broker 120 is protocol independent.

[0022] The data passed between the message broker 120 and the initiator 140 via the API 130 may be passed as arguments in specific method calls defined by the API 130. These method calls include, for example, connect, deliver message and message delivery status. The specific method or function call for the generic exchange may have language specific arguments. For example, a deliver message method call implemented in C++might use a char array, which is a primitive data type, for communicating the data content and attributes of the message to be delivered. If the deliver message method call is implemented in Java, however, the same piece of information passed in a char array may be passed as a string.

[0023] Features of object oriented programming languages, such as Java and C++, are useful for implementing the message broker 120, the API 130 and the initiator 140. The decision by the message broker 120 at runtime to create an instance of an initiator 140 of a specific type based upon the transfer protocol associated with a particular destination, followed by the use of that initiator 140 via a generic set of calls without regard to the kind of initiator 140, is served well by the inheritance and polymorphism features of object oriented languages. Each kind of initiator 140 can be implemented as a subclass, which inherits from a common superclass after the creation of an initiator object. The method calls defined by the superclass are actually performed by implementations of those methods by the particular subclass.

[0024] Non-object oriented programming languages may also be used. Many non-object oriented programming languages provide capabilities for achieving the same effect in an indirect manner. For example, in the C language, an abstract API 130 can be defined as a set of function calls but invoked indirectly through function pointers to runtime-selected implementations of those functions. Therefore, a message broker 120 using C could select a particular type of initiator 140 and logically create an instance of that initiator 140 by initializing a set of function pointers. The message broker 120 could then call those functions and remain fully independent of the transfer protocol handled by the C functions that embody the initiator 140.

[0025] FIG. 3 is a flow diagram of a data transfer process consistent with the present invention. The process shown in FIG. 3 should be understood as being applicable to any transfer protocol. As shown in FIG. 3, first the message broker 120 determines the transfer protocol with which the data is to be transferred (step 305). The data may be, for example, an electronic mail message, a document, or a file. The transfer protocol may be determined by referring to a profile stored in the message broker 120, which indicates the transfer protocol to be used with the particular external network 150. Once the transfer protocol is determined, the message broker 120 identifies the initiator 140 which supports the determined transfer protocol and creates an instance of that initiator 140 (step 310). If the initiator 140 is written in an object oriented language, such as Java or C++, the instance of the initiator 140 is called an initiator object. If there is data going to different destinations, then multiple instances of the initiator 140 would be created, one for each destination. For purposes of the following explanation, it will be assumed that step 310 creates an initiator object 140, although the present invention is not limited to the use of objects.

[0026] After the initiator object 140 is created, the message broker 120 invokes a connect call via the API 130 (step 315). The connect call can also be referred to as an API method or API function. The invocation of the initiator object 140 allows the initiator object 140 to make the data connection according to the transfer protocol supported by the initiator 140. To make the data connection, the connect call function includes the information needed by the initiator object 140 to establish the data connection. This information may be passed as generic arguments with the connect call function, such as with a generic data structure. Alternatively, this information may be gathered from the runtime environment. The information provided is preferably identical for each connect call function, regardless of the transfer protocol. As a result, the message broker 120 does not require a different connect call function for each type of transfer protocol. In other words, the message broker 120 can treat each transfer protocol in the same way.

[0027] The initiator object 140 then makes the data connection with the external network 150 (step 320). To make the connection, the initiator object 140 uses the generic arguments passed from the message broker 120. The particular arguments used may vary according to the transfer protocol. In general, most transfer protocols may require the IP address of the external network 150 and the port number. The initiator object 140 also determines if the connection was made successfully.

[0028] Based upon the connection made, the initiator object 140 passes a connection status message to the message broker 120 via the API 130 (step 325). The information passed to the message broker 120 with the connection status message includes, for example, if the initiator object 140 is ready to pass a message, if the connection has been disconnected, or if the connection is ready to be disconnected. This information passed to the message broker 120 is protocol independent. If the initiator object 140 is unable to establish the data connection, the initiator object 140 passes error information in the connection status message in step 325. The error information may be protocol dependent and may be stored in an error log or transferred to an error notification system in message broker 120 or elsewhere in the internal network 110.

[0029] Assuming the connection has been made to the external network 150 and there is a message to be transferred, the message broker 120 transmits a deliver message method (step 330). The deliver message method includes message attributes and a message body. The message attributes includes, for example, the address of the sender and receiver, the message type, and the time and date of creation of the message. As discussed above, the attributes sent are not dependent upon the type of transfer protocol being used. The attributes sent preferably include each attribute that may be needed by any transfer protocol. If the attribute is not needed for the transfer protocol, the attribute is ignored. For example, the SMTP protocol uses a subject field, but the FTP protocol does not. The message body corresponds to the data content being transferred.

[0030] After receiving the deliver message method, the initiator object 140 transmits the message to the external system 150 (step 335). The initiator object 140 uses the message attributes needed by the transfer protocol to transfer the message body, as well as message attributes, if relevant or necessary. The initiator object 140 recognizes whether the message body has been transferred.

[0031] The initiator object 140 then transmits a message delivery status to the message broker 120 via the API 130 (step 340). The message delivery status has a variety of information including, for example, whether the message transfer was successful, whether there has been an acknowledgment, the transfer commit status, and an indication of the connection status. As discussed above, the initiator object 140 recognizes whether the message has been transferred successfully. The content of the acknowledgment in the message delivery status may be, for example, that the data has been received, that it is expected, or that it is not expected. Since only some transfer protocols and some external networks provide acknowledgments, the content of the acknowledgment may be dependent upon the transfer protocol or external network. If the initiator object 140 expects to receive an acknowledgment not yet received, the initiator object 140 may update the message deliver status when the acknowledgment is received.

[0032] The commit status advises the message broker 120 whether the transfer of the message should be considered as final. If the commit status is “yes,” the message broker 120 can depend upon the transfer indication provided by the initiator object 140. If the commit status is “no,” the message broker 120 cannot take as final the status provided by the initiator object 140. The inclusion of the connection status in the message delivery status informs the message broker 120 whether the initiator object 140 can do further message deliveries.

[0033] After delivering the message, the message broker 120 can send a disconnect request to the initiator object 140 via the API 130 (step 345). In response to the disconnect request, the initiator object 140 terminates the data connection to the external network 150 (step 350). The initiator object 140 then sends a connection status to the message broker 120 via the API 130 indicating that the data connection has been disconnected (step 355). This connection status message in step 355 may also include a commit status indicating that the message broker should consider as final that the message has been successfully or unsuccessfully transmitted.

[0034] FIG. 4 is a flow diagram of another data transfer process consistent with the present invention. More particularly, the flow diagram of FIG. 4 shows a process similar to that of FIG. 3, except that multiple messages are delivered using the identified transfer protocol and the data connection is interrupted before all the messages are completed. As shown in FIG. 4, steps 405 through 440 correspond to steps 305 through 340. Instead of sending a disconnect message after completion of the transfer of the first message, another deliver message method is transmitted from the message broker 120 to the initiator object 140 via the API 130 (step 445). The initiator object 140 then transmits the message body to the external network 150 (step 450) and sends the message delivery status to the message broker 120 via the API 130 (step 455).

[0035] The message broker 120 sends another deliver message method to the initiator object 140 via the API 130 (step 460), which the initiator object 140 attempts to transmit to the external network 150 (step 465). During the transmission, however, the data connection is lost. The initiator object 140 then sends the message delivery status (step 470). Since the connection is lost during the transfer, the message delivery status passed to the message broker 120 via the API 130 includes an indication that the message deliver was unsuccessful.

[0036] The following is an example of a definition of the API 130 implemented in Java code. This definition serves as a parent class, also referred to as a superclass, for each type of initiator 140 that may be developed. package initiator; import java.util.Properties; /** * This abstract initiator class defines the API that all initiators * support. While various subclasses of initiator may vary greatly * due to the different protocols they implement, the message broker * drives them all using this uniform interface. * */

[0037] The following is an example of code for defining the structure and content of the message delivery status returned by a deliver message method. This code is representative of a supporting class. package initiator; * The following defines the information returned by an initiator * to the message broker expressing the result of a * MessageDelivery attempt. * */

[0038] The following is an example of an actual initiator 140. This example simply writes lines to an audit file. However, it also illustrates with its structure and comments how a developer may build an initiator 140 and fill in details within each of the methods specific to the protocol supported by the initiator 140 package initiator; import java.util.Properties; * This example of an initiator illustrates a specific * transfer protocol implemented as an initiator subclass. * In this example, the actual “transfer” entails merely writing * a summary line to a standard output stream. * */

[0039] The foregoing description of a preferred embodiment of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. The embodiment was chosen and described in order to explain the principles of the invention and its practical application to enable one skilled in the art to utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims appended hereto, and their equivalents.