Communicating between a process and a destination6978464Abstract In a communication system with a first computer and a second computer, the first computer with a first process communicates with a destination on the second computer. The first computer receives destination information indicative of the destination from the first process. The first computer then determines a transport protocol for a message object based on the destination information. The first computer then generates the message object based on the destination information. The first computer receives message information indicative of a message to be transmitted from the first process to the destination. Finally, the first computer transmits the message information from the first process to the destination using the message object and the determined transport protocol. One advantage of determining the transport protocol at run-time is the transport protocol may be determined by an environment variable. This allows the system administrator to alter the transport without recompiling or modifying code. Claims 1. A method of communicating between a first process on a first computer and a destination on a second computer, the method comprising: Description FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT
In step 402, the first computer 310 receives destination information indicative of the second process 322 from the first process 312. In this embodiment, the destination information is the name of the server to communicate with and the name of the service to call. In step 404, the first computer 310 determines the transport protocol for the message object 314 based on the destination information. In this embodiment, the determined transport protocol is process to process. In step 406, the first computer 310 generates a message object 314 based on the Message constructor by specifying the name of the server to communicate with, the name of the service to call, and the maximum reply length tolerated. In step 408, the first computer 310 receives message information indicative of a message to be transmitted from the first process 312 to the second process 322. In this embodiment, the message information is a pointer to the message and a length of the message. The first computer 310 may transmit messages to the second computer 320 by a waited message or a nowait message. When sending a waited message, all processing is halted until the reply to the message is received. Waited messages may also be known as synchronous or blocking messages. With nowait messages, the first computer 310 performs other tasks such as SQL work or other messaging while waiting for the reply from the second computer 320. In step 410, the first computer 310 transmits the message information for a waited message from the first process 312 to the second process 322 using the message object 314. The first computer 310 calls a "post" method of the message object 314. The "post" method accepts two parameters: the pointer to the waited message and the length of the message. An example of the "post" method is shown as:
For error checking, the first computer 310 checks for a Message error returned by the "post" method. The errors returned by the "post" method are system errors. One example is of error checking for the "post" method is shown as:
For advanced error handling, the first computer 310 uses an additional parameter in the Message constructor called the error service. This error service is an instance of a user defined service class which is called if a posted message should encounter an error. The first computer 310 generates a unique identifier, a tag, for every message posted. The "getTag" method of the Message class returns this value. The tag is useful in associating the message posted with the message replied. One example of using the "getTag" method is shown as:
These tags are used to locate messages. Inbound messages are stored in a vector named "inbound" which is a static public data member of the Message class. All outbound messages are stored in a vector named "outbound". These two vectors provide freedom to maintain complicated nowait messaging schemes. In step 412, the first computer 310 then receives a reply from the second process 322. The first computer 310 receives the reply using two methods: getBuffer and getBufferlength. The getBuffer method returns a pointer within the message object 314. The getBufferlength method returns the length of the reply. FIG. 4 ends in step 414. For nowait messages, the first computer 310 uses the constructor below: Message (string server, string request, int size, Service*reply). The constructor is similar to the constructor for the waited messages except for the last parameter, reply service. The reply service is a service to be called when the reply to the message "post" is returned. FIG. 5 depicts a flow chart for the communication system 300 for process to process communication for receiving a message in an example of the invention. FIG. 5 begins in step 500. FIG. 5 uses two different classes: a Service class and an Application class. Both the Service class and the Application class are generic base classes from which other more complicated and useful classes can be derived. The Application class provides a framework from which an entire application is built. The Application class provides for listening of incoming messages and determines which services to execute. The Service class provides a framework from which individual services are built. Both the Service class and the Application class are discussed below in FIG. 9. In step 502, the first computer 310 registers a service to enable calling from another process. In the Service class, the registerService method registers a unique name. In this embodiment, the name of the service is 27 characters or less. One example of the registerService method is shown as:
If a request for a registered service comes in an unrecognizable format, a default request service can be specified. In this embodiment, a service with no name is registered for a default request service. One example of a default request service is shown as:
In step 504, the first computer 310 performs an "execute" method from the Service class. The "execute" method accepts the message object as a parameter for extraction, manipulation or replying back to the message object. The "execute" method performs no operations. However, the "execute" method is intended to be overridden by a developer. The developer can create a new class from the Service class and override the "execute" method. One example of the "execute" method is shown as:
In step 506, the first computer 310 performs a "reply" method from the Message class. The "reply" method, which is similar to the "post" method, receives a message by accepting two parameters: a pointer to the message and the length of the message. One example of the "reply" method is shown as:
For error checking, the first computer 310 checks for a Message error returned by the "reply" method. One example of error checking for the "reply" method is shown as:
In step 508, the first computer 310 performs a "listen" method from the Application class. The "listen" method provides a dispatch loop for a process. One example of the "listen" method is:
For error checking, the first computer 310 checks for a Message error returned by the "listen" method. As long as there are either timers, registered services, or nowait replies expected, the "listen" method will continue to run until there is nothing left to do, or some sort of critical error is encountered that prevents it from operating. One example is of error checking for the "listen" method is shown as:
Another Message class is MessageTIMER. MessageTIMER behaves similar to a regular message except that the message never actually goes anywhere. The reply service is called after a specified length of time. The constructor for a MessageTIMER accepts a reply service and a length of time measured in centiseconds. In this embodiment, macros convert DAYS, HOURS, MINUTES into centiseconds. One example of the MessageTIMER is shown as:
Process to Pathway FIG. 6 shows an example of process to pathway communication in an example of the invention. FIG. 6 depicts a block diagram of a communication system 600 in process to pathway communication in an example of the invention. The communication system 600 comprises a first computer 610 and a second computer 620. The first computer 610 comprises a first process 612 and a message object 614. The message object 614 is logically connected to the first process 312 and a pathway 622. The pathway 622 is also connected to the second computer 620. The operation of the process to pathway communication is similar to the operation of the process to process communication discussed above. One difference is that in the Message constructor, a SHELL style pathway name is specified. The pathway name comprises a pathmon and the server. In this embodiment, the pathmon name begins with the "#" symbol followed by a "^" symbol and then the server name. Process to Socket FIG. 7 shows an example of process to socket communication in an example of the invention. FIG. 7 depicts a block diagram of a communication system 700 in process to socket communication in an example of the invention. The communication system 700 comprises a first computer 710 and a second computer 720. The first computer 710 comprises a first process 712 and a message object 714. The second computer 720 comprises a socket 722. The message object 714 is logically connected to the first process 712 and the socket 722. The operation of the process to pathway communication is similar to the operation of the process to process communication discussed above. One difference is in the Message constructor an Internet Protocol address and a port number of the socket are specified. One example is shown as: 144.223.107.23:1066 Also, the "listen" method described above can listen on TCP/IP socket ports. The port number is specified in the "listenOn" method of the Application class. One example of the "listenOn" method is shown as
FIG. 8 depicts a block diagram of the Message class in an example of the invention. A Message class 810 is connected to a Message constructor 812, a post method 814, a reply method 816, an abort method 818, a create method 820, a commit method 822, a status method 824, a getBuffer method 826, a getBufferLength method 828, a getHeader method 830, a getheaderlength method 832, a getTag method 834, a getSystemTag method 836, a getError method 838, a getServemame method 840, a getServiceName 842, a getReplyService method 844, a getErrorService method 846, a getTimelimit method 848, a <<operator 850, a>> operator 852, a parent method 854, and a children method 856. The Message class 810 provides a method for formatting messages to be sent to a destination. Besides the Message base class, several other derived classes are included to handle various message formats. The Message constructor 812 is shown as:
The post method 814 is shown as:
The reply method 816 is shown as:
The abort method 818 rolls back TMF and sends reply data back to the porting server's error service. The abort method 818 is shown as:
The create method 820 manually creates a TMF bracket to be associated with the Message object. The create method 820 is shown as:
The commit method 822 manually commits the TMF bracket associated with the Message Object. Since committing a TMF bracket is a nowait operation, a callback service must be provided if notification is required. The commit method 822 is shown as:
The status method 824 returns the current TMF status of the Message. The status method 824 is shown as:
The status code includes internal error (-1), nil state (0), active (1), prepared (2), committed (3), aborting (4), aborted (5), and hung (6). The getBuffer method 826 returns a pointer to the message buffer. The getBuffer method 826 is shown as:
The getBufferlength method 828 returns the number of bytes contained within a message buffer. The getBufferlength method 828 is shown as:
The getHeader method 830 returns a pointer to the message header. The getHeader method 830 is shown as:
The getHeaderLength method 832 returns the number of bytes contained within a message header. The getHeaderLength method 832 is shown as:
The getTag method 834 identifies a unique tag number of a message object after a "post" method. The unique tag number is helpful in identifying a particular message. The getTag method 834 is shown as:
The getError method 838 returns the error number of the last operation performed. The getError method 838 is shown as:
The getServerName method 840 returns the "server" parameter supplied in the message constructor. The getServerName method 840 is shown as:
The getServiceName method 842 returns the "service" parameter supplied in the message constructor. The getServiceName method 842 is shown as:
The getReplyService method 844 returns the "reply" parameter supplied in the message constructor. The getReplyService method 844 is shown as:
The getErrorService method 846 returns the "error" parameter supplied in the message constructor. The getErrorService method 846 is shown as:
The getTimelimit method 848 returns the "timelimit" parameter supplied in the message constructor. The getTimelimit method 848 is shown as:
The <<operator 850 copies the recognized object into the message buffer and calls either the "post" method or the "reply" method. Calling the <<operator 850 on an RWCollectable object calls the "saveGuts" method. The <<operator 850 is shown as:
Although there is no "<<" equivalent to the abort method, the following shows the possibility of aborting a message and replying back at the same time:
The >>operator 852 copies the buffer data into the recognized object. Calling the >>operator 852 on a RWCollectable object calls the "restoreGuts" method. Calling the >>operator 854 on a char*calls the "strcpy" function. The >>operator 852 is shown as:
The parent 854 points to the inbound message for any outbound message object posted from within a request service. Using parent 854 helps to associate an outbound message with the inbound message that triggered its creation. If an inbound message has no associated outbound messages, the parent 854 points to "NULL". An example of the parent 854 is shown as:
The child 856 contains a list of all associated outbound messages if an inbound message object is a parent 854. Once an outbound message has been replied to, the outbound message is removed from the list of children 856. The child 856 is shown as:
FIG. 9 depicts a block diagram of a Service class 910 and an Application class 920 in an example of the invention. The Service class 910 is connected to an execute method 912 and a registerService method 914. The Application class 920 is connected to a listen method 922, a listenOn method 924, a exitListen method 926, and an awaitiox method 928. The Service class 910 is a generic base class meant to be used to derive more powerful services. The execute method 912 is intended to be overridden by the user. The user places application logic within the execute method 912. The execute method 912 is shown as:
The "msg" parameter is a reference to either an inbound or outbound message object depending upon the situation. Registered services reference inbound messages. Reply or error services reference outbound messages. The registerService method 914 allows a registered service to be called by external processes. Reply or error services are not registered. The registerService method 914 is shown as:
The "name" parameter matches the "service" parameter of the Message constructor exactly. In this embodiment, the name parameter is limited to 27 characters. If the service is registered with no name, a default request service is created. All unformatted messages are directed to this default request service. Services with multiple names may be registered, but multiple services may not be registered with the same name. One example of the value parameter is shown as:
The Application class 920 performs all of the message routing tasks. The Application class 920 performs initialization. The listen method 922 is a loop that listens for inbound messages and replies to outbound messages and directs the messages to the proper service. The listen method 922 returns successfully if there are no registered services and there are no pending outbound messages. The listen method 922 returns with an error code on any recoverable error. Because the listen method 922 is a loop, the listen method 922 should not be placed within another loop. Calling the listen method 922 again after the listen method 922 has terminated does not yield any new results. The listen method 922 is shown as:
The listenOn method 924 allows users to listen on any supported transport. The listenOn method 924 is shown as:
The server parameter is a character string representing the protocol used to listen for incoming messages. Listening on "$receive" happens automatically upon instantiating an Application object. The exitListen method 926 allows the user to terminate the listen method. The exitListen method 926 is shown as:
The awaitiox method 928 is intended to be overridden by the user. If the listen loop encounters an unknown signal, the awaitiox method 928 is called to be handled by the user. All of the parameters found within the awaitiox method 928 correspond to the Guardian procedure called "awaitiox". The awaitiox method 928 is shown as:
The cc—error parameter is the value returned by the awaitiox function from within the listen loop. The filenum parameter represents the file number of the I/O event. The buffer parameter is a pointer to memory containing data written during the I/O event. The tag parameter is the same tag value used by the function that initiated the I/O event. The segment—id parameter represents the memory segment reference by the I/O event. FIG. 10 depicts a block diagram of a Transport class 1010 in an example of the invention. The Transport class 1010 is connected a registered data member 1012, a clone method 1014, a close method 1016, an open method 1018, a post method 1020, a reply method 1022, a listen method 1024, a cancel method 1026, an inspect method 1028, an accept method 1030, a registerTransport method 1032, and an assignTransport method 1034. The Transport class 1010 provides methods for sending and receiving messages from other processes. Process to process, process to pathway, process to socket transport protocols are supplied, but other transport protocols may be added. Registering a tranport makes it available to be used by the Message class. The registered data member 1012 is a list that contains an instance of each derived Transport class available for use. The clone method 1013 calls the copy constructor. The close method 1016 closes the derived transport mechanism. The open method 1018 opens the derived transport mechanism. The post method 1020 sends data through the derived transport mechanism. The reply method 1022 sends data back through the derived transport mechanism. The listen method 1024 reads data from the derived transport mechanism. The cancel method 1026 provides a way of cancelling an outstanding message. The inspect method 1028 completes the call to listen. The inspect method 1028 performs any clean up activities required after reading data from the derived transport mechanism. The accept method 1030 returns true if the server name of the message object matches the derived transport's naming convention. The registerTransport method 1032 places a transport object onto the registered linked list. The assignTransport method 1034 accepts a server name and searches the registered list for a transport object that will accept. If a match is found, the clone method 1014 is called and a copy of that object is returned. The assignTransport method 1034 allows message objects to obtain a fresh transport dynamically without knowing the actual transport mechanism to be used. The Transport class 1010 also comprises the TransportProcess class, the TransportPathmon class, and the TransportSocket class in FIG. 11. FIG. 11 depicts a block diagram of a TransportProcess class 1110, a TransportPathmon class 1130, and a TransportSocket class 1140 in an example of the invention. The Transport class 1110 is connected to an open method 1112, a close method 1114, a post method 1116, a reply method 1118, a listen method 1120, a cancel method 1124, and an accept method 1126. The TransportPathmon class 1130 is connected to a post method 1132 and an accept method 1134. The TransportSocket class 1140 is connected to an open method 1142, a close method 1144, a post method 1146, a reply method 1148, an inspect method 1150, and an accept method 1152. The TransportProcess class 1010 provides the read/write functionality for process to process communication. The open method 1112 calls FILE—OPEN—. The close method 1114 calls FILE—CLOSE—. The post method 1116 calls WRITEREADX. The reply method 1118 calls REPLYX. The listen method 1120 calls READUPDATEX. The cancel method 1122 call CANCELREQ. The inspect method 1124 determines the system message tag. The accept method 1126 returns true if the server name fits the Guardian process name syntax. The TransportPathmon class 1130 provides write functionality for Pathway communication. The post method 1132 call SERVERCLASS—SEND—. The accept method 1134 returns true if a server name contains a "#" symbol followed by a pathmon name, followed by a "^" symbol, followed by a server-class name. The TransportSocket class 1140 provides read/write functionality for TCP/IP sockets. The open method 1142 calls connect—nw for postable messages. The open method 1142 call bind—nw, listen, for readable messages. The close method 1144 call FILE—CLOSE—. The post method 1146 calls send—nw followed by recv—nw. The reply method 1148 calls send—nw. The inspect method 1150 sets the message service name to either TCP/IP spawn if the server is to spawn a new process, or "CompleteSocketConnection" if it is not. The accept method 1152 returns true if the server name is an IP address followed by a ":" and a port number. By dynamically determining the transport protocol at run-time, the transport protocol may be determined by an environment variable. This allows the system administrator to alter the transport without recompiling or modifying code. The developer can also add transport protocols or message objects. Another advantage is multiple messages formats in a standardized way with the actual data format hidden from the user. The developer writes a single piece of code capable of interacting with multiple server using different message formats and transport protocols. Another advantage is the handling of both waited and nowait messages. With the option of wait or nowait messages, the developer then can write more powerful and efficient applications. Error services is another advantage which allows developers to distinguish error conditions and separate error handling logic from normal business logic. The ability to invoke error services is considered as exception handling across processes. Error notification allows the developer to either retry the offending logic or propagate the error further upstream. Automatically associating each incoming TMF bracket with all outgoing messages within a logical thread allows developers to rollback database work in the event of an error within a process or across processes. Another advantage of this embodiment is the code is written in C++, a high level programming language. This provides a standard communications interface for software development on the Tandem computers. Those skilled in the art understand the benefits of object oriented programming languages such as maintenance and the ease of using objects to build applications. The code is also Native Mode compatible. The DINGUS framework reduces the complexity required to write multi-threaded applications in a Tandem environment. The ease of use of the DINGUS framework and the object oriented programming reduces the time to build applications. The DINGUS framework also abstracts the platform specific messaging of the Tandem machine, so non-Tandem programmers can build applications in the Tandem environment. The above-described elements can be comprised of instructions that are stored on storage media. The instructions can be retrieved and executed by a processor. Some examples of instructions are software, program code, and firmware. Some examples of storage media are memory devices, tape, disks, integrated circuits, and servers. The instructions are operational when executed by the processor to direct the processor to operate in accord with the invention. Those skilled in the art are familiar with instructions, processor, and storage media. Those skilled in the art will appreciate variations of the above-described embodiments that fall within the scope of the invention. As a result, the invention is not limited to the specific examples and illustrations discussed above, but only by the following claims and their equivalents.
|
Same subclass Same class Consider this |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||