Abstract:
An adaptive connection system for message transmission from a source application to a destination application, comprising a first gateway to interfacing the sending application with a first protocol, a second gateway to interfacing the receiving application with a second protocol, and a connection server bridging between the first and second gateways over a network for receiving the message from the first gateway and forwarding the same to the second gateway. The connection server further provides tracking information to the source and/destination to check the transmission status.

Description:
[0001]     This application claims the benefit of and incorporates by reference the entirety of U.S. Provisional Patent Applications 60/468,616 filed May 5, 2003 entitled “ADAPTIVE CONNECTION FOR DATA TRANSMISSION” and 60/453,935 filed Mar. 12, 2003 entitled “INTERNET CONNECTION SYSTEM.” 
     
    
     TECHNICAL FIELD OF INVENTION  
       [0002]     The present invention relates to data transmission, in particular, to a novel connection solution adaptive to both a sending application and the receiving application without a need for changing the applications, even when the applications are not of the same protocol, of the same platform, or compatible to each other. Furthermore, the novel adaptive connection leverages internet protocols while still being able to perform secure and reliable data transmission.  
       BACKGROUND OF THE INVENTION  
       [0003]     Information transmission between an enterprise and its suppliers, customers and/or partners is a fundamental business process, which requires a secure and reliable connectivity. Information transmission over a data network, however, is still limited to only a small fraction of endpoints because of its high cost to implement even for a large enterprise. Enterprises need connectivity strong and robust enough to exchange mission critical business data, which requires enterprises to manage a complex, costly and time consuming deployment process. Often, solutions must be custom-built and are limited to specific internal applications. Protocol and platform incompatibilities between enterprises prevent applications from being connected, and for some enterprise solutions, every endpoint must utilize the same messaging infrastructure. Obviously, this is not applicable to a now widely diverse, heterogeneous environment in which the enterprises struggle.  
         [0004]     The Internet offers a ubiquitous backbone with open, flexible protocols, which may substantially slash the cost of connectivity and extend an organization&#39;s connectivity reach. It, however, does not inherently provide the security and reliability that corporations need to exchange important business information, nor does it provide the asynchronous processing paradigms needed for effective application-to-application integration.  
         [0005]     Thus, there exists a need for a technique to leverage internet protocols—both inside the enterprise and across firewalls—to their suppliers, partners, and customers. Moreover, for a reliable transmission of important enterprise data, the users involved are always interested in a capability to track the transmission status.  
       SUMMARY OF THE INVENTION  
       [0006]     To achieve the above objectives, a new connection system is provided for message transmission from a sending application at one computer to a receiving application at a second computer. In particular, the connection system comprises a first gateway to interface the sending application with a first protocol, a second gateway to interface the receiving application with a second protocol, and a connection server bridging between the first and second gateways over a network for receiving the message from the first gateway and forwarding the same to said second gateway. Thus, the sending application and the receiving application do not need to match in protocol to communicate. In a preferred embodiment, the first and/or second protocol uses one of several standard Internet protocols.  
         [0007]     The connection system may generate tracking information for each message transmission, which includes at least the tracking number and the transmission status. The tracking number is provided to the first and/or second computers, and the tracking record may be kept in the connection server or a separate tracking information server, which is preferably accessible by the users over the Internet.  
         [0008]     Each of the gateways may keep a plurality of interfaces, each suitable for a specific protocols. The gateways preferably include ports for various protocols such as HTTP, SMTP, FTP, or others. These ports are termed listeners, each gateway having plural listeners so that it may interface with each protocol. Each gateway communicates with the associated application using the protocol implemented by that application. Thus, the first gateway may communicate over a specified port with an application using HTTP, and the second gateway may communicate with its associated application using a different port number and a different protocol. Each gateway has plural ports with which to listen, and preferably each port will convey data using a predetermined protocol associated with that port.  
         [0009]     Morphing modules may be provided in the gateways to examine and modify the message if necessarily. In particular, a morphing module is provided at the second gateway to change the data to a format suitable to the receiving application. The morphing module may perform further functionality. For example, morphing may validate certain messages, and declare others to be unauthorized by conveyance to the receiving application. The morphing module may require authorization to convey messages, may discard certain messages in part or in their entirety, or may perform any other filtering functions with respect to the communications being conveyed. The morphing module operates as a configurable filter, which may be configured based upon user preferences, the expected traffic types and flow, or other suitable parameters.  
         [0010]     The message or data transmitted is encrypted at the first gateway, enclosed in an “envelope” for transmission, and is decrypted at the second gateway. 
     
    
     BRIEF EXPLANATION OF THE DRAWINGS  
       [0011]     The above and other features and advantages will be clearer after reading the following detailed description of the preferred embodiment of the invention, with reference to the accompanying drawings, in which:  
         [0012]      FIG. 1  illustrates a basic adaptive connection topology of the present invention;  
         [0013]      FIG. 2  illustrates in more detail the elements in the inventive adaptive connection system;  
         [0014]      FIG. 3  is a flow chart showing the message transmission stages in the system of  FIG. 2 ; and  
         [0015]      FIG. 4  illustrates a tracking server incorporated in the connection system. 
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0016]      FIG. 1  shows a basic topology of the data/message transmission from a source  1  to a destination  2 , in which the adaptive connection system  10  of the present invention is incorporated. The inventive adaptive connection system  10  basically comprises a connection server  11 , a source gateway  12  and a destination gateway  13 . As shown in  FIG. 1 , the source gateway  12  is capable of interfacing any one of the applications  3  with corresponding one of several internet protocols, e.g., SMTP, FTP or HTTP. For example, if data is sent from an EDI application using FTP protocol, the source gateway  12 , will receive such data on the port associated with FTP. As shown in  FIG. 2  with more detail, this is done by employing plural listeners  121 , provided in the source gateway  12 . Thus, the source gateway  12  is capable of communicating with any of the applications  3 , no matter what internet protocol is used by the sending application, because the gateway  12  includes various listeners that each operate on different ports.  
         [0017]     A major consequence of the adaptive protocol handler, or the listener  121 , is that applications  3  do not need to contain logic that invokes the API of message queuing systems with which they may communicate. This greatly expands the number of applications that can participate in a business connectivity solution. Another benefit of the adaptive protocol handler  121  is that it makes business connectivity non-intrusive since applications  3  do not need to be changed, regardless of the communications protocol being utilized, and regardless of the application running a computer with which the application is communicating.  
         [0018]     With the appropriate listener, the source gateway  12  receives the data from sending application  3 , which includes the address information of the desired destination  2 . The protocol to be utilized by the desired destination is determined by the connection server. This determination allows the destination gateway  13  to determine which protocol and which port to use in communicating with the receiving application. The data is then sent to the connection server  11  through a data network  14 . The connection server  11  also extracts the destination address information to route the data to the destination gateway  13 , through a data network  15 .  
         [0019]     Upon receipt of the data from the connection server  11 , the destination gateway  13 , is caused to utilize the protocol that matches the protocol used by the destination application  4 , as indicated by the connection server  11 . This is done by a connector  131  provided in the destination gateway  13 . Thus, the data is successfully sent from the destination gateway  13  to a receiving application  4  at the desired destination  2 , which may be using a different protocol from the one used by the sending application, or even running on a different platform. For instance, data can be sent via HTTP and placed on an MQ series queue at the receiving end. Applications using NET&#39;s underlying queuing technology, MSMQ, can exchange data with applications using a different (or no) queuing system. No commitment to a major new infrastructure is required.  
         [0020]     With the connection server  11  standing between the source  1  and the destination  2 , asynchronous data transmission can be realized even when both sending and receiving applications  3  and  4  are synchronous ones.  
         [0021]     A fundamental business connectivity requirement is the ability to transform, or morph, business data from the sender&#39;s application format into the format of the receiver&#39;s application. Recipient companies may use differing applications, so the technology must allow data to morph differently depending on the specific destination application&#39;s needs. To this end, one or more morphing modules  122  and  132  are provided in the source gateway  12  and the destination gateway  13  to examine and modify the data. In particular, the morphine  132  in the destination gateway  13  may alter the received data to a format that is suitable to the receiving application  4 .  
         [0022]      FIG. 3  shows a flow chart depicting the data transmission sent from the source  1 , through the connection system  10  reaching the desired destination  11 , as illustrated in  FIGS. 1 and 2 . The data is generated by an application  3  (e.g., HTTP application, message queue, etc.) at the source  1 , at step  100 . With the proper protocol the data is received by the source gateway  12 , at step  101 . At the source gateway  12 , the data is undergoing morphing (possibly by multiple morphing modules) at step  102 , then is queued onto a message queue  123  to go to the connection server  11 , at step  103 . The data is retrieved by the connection server  11 , at step  104 , and goes through the routing process by a routing module, at step  105 , and then is queued onto a message queue  112  to go to the destination gateway  13 , at step  106 . The data is retrieved by the destination gateway  13  at step  107 . Again, the data undergoes morphing at step  108 , possibly tailored to the format required by the receiving application  4 . Finally the data is sent to its final destination at step  109 , and a response is generated to indicate the successful transmission.  
         [0023]     For the security of data transmission, the data is encrypted at the source gateway  12 , and is decrypted at the destination gateway  13 . Furthermore, it is important to provide traceable and auditable information to the users regarding their data transmissions.  
         [0024]     As shown in  FIG. 4 , a tracking server  20  is provided to keep and maintain a tracking record for each data transmission. Typically, a tracking number is generated for a specific data transmission at the source gateway  12  upon receipt of the data from the sending application. The status of the data transmission at some steps from  101  to  109  are reported from the related servers and/or gateways directly to the tracking server  20 , or forwarded by the connection server  11  to the tracking server  20 . The tracking server  20  can be the same one as the connection server  11 , or a separate one remotely located from the connection server  11 .  
         [0025]     Preferably, the tracking server  20  is accessible by the user over the Internet, e.g., through a browser in a display  21 , with the tracking number that he has received from the source gateway or connection server  11  or the tracking server  20 . This will permit a user to ascertain the status of the data transmission. Additionally, tracking numbers may be assigned by any other source connected to the network. Messages may also be tracked using any other parameter of the message, rather than a tracking number.  
         [0026]     Preferably, auditing information is provided by the source gateway  1 , or by the destination gateway  2 , or by both. Auditing information can be added to the message being conveyed, or can be provided to the connection server  11  or to the tracking server  20  so as to be added to the tracking information.  
         [0027]     The connection server  11  can be remotely located from both gateways  12  and  13 , and the data link  14  and  15  can be the Internet, a LAN, or a WAN. Firewalls may be put between the gateways  12 ,  13  and the connection server  11 . It is also possible to locate the connection server  1 I at the same node with one of the gateways  12 ,  13 .  
         [0028]     We will now describe in further detail the convenience and acknowledgement of a message from one of applications  3  to applications  4 . In operation, a message that is to be acknowledged would traverse the system of  FIG. 3  from left to right. The message leaves one of applications  3  and arrives at gateway  12  via the appropriate one of the plural listeners installed at gateway  12 . The gateway  12  would include listeners for most or all standardized Internet protocols (HTTP, FTP, SMTP) as well as listeners for operating from known queuing systems (e.g. MSMQ, Websphere, etc.) and file systems.  
         [0029]     Messages may optionally then be processed by a filtering and morphing module. As described above, this step may result in some messages being altered, discarded, partially transmitted, etc. The parameters of the filtering and morphing are user configurable and highly flexible.  
         [0030]     After optional filtering and morphing, the message is placed into a queuing system that I responsible for reliable delivery of the message once and only once. In the event of network outages, the system will continue to retry transmission as necessary in order to achieve delivery of the message once and only once.  
         [0031]     At the connection server  11 , the URI of the message is parsed and utilized to forward the message to its destination. The destination information associated with a message comprises preferably both the type of destination (e.g. web server, FTP server, SMTP server, etc) as well as the location of that destination. The destination information may contain the location of a gateway connected to the destination in addition to, or instead of, the destination information itself.  
         [0032]     After the destination information is added, the message is then queued again at the server  11 , and forwarded in a reliable and secure manner to destination gateway  13 . tracking information may be generated and/or maintained at any of the gateways  12  and  13  or connection server  11 . In addition, any of the aforementioned may communicate with one or more other computers to generate and store the tracking, audit, or other parameters related to the transmission of the message.  
         [0033]     Upon arrival at destination gateway  13 , the message may again be put through morphing and filtering modules, which can alter, reject, or allow the message. The implementation of morphing and filtering at gateway  13  need not operate based upon the same parameters as that in gateway  12 . Thus, although gateway  12  may determine that a particular type of message is suitable to transmit to a particular application  4 , and thus permit passage of that message, the destination gateway  13  may nonetheless reject that message.  
         [0034]     After arriving at the destination gateway  13 , the message is passed to the appropriate port (i.e.; listener) to transmit the message to the destination application. That listener could be, for example, FTP, SMTP, or HTTP. Upon receipt, the response message may be conveyed in the opposite direction back to the application  3 , or a response may also be sent to a third destination that stores such response.  
         [0035]     Though the preferred embodiments of the present invention have been described in detail as above, it shall be appreciated that numerous adaptations, variations and changes are possible to a skilled person in the art without departing from the spirit of the invention. Therefore, the scope of the invention is intent to be solely defined in the accompanying claims.