Abstract:
An apparatus for and method of predefining a series of messages between a client application and a server application which needed to be transferred and honored in sequence to perform a compound service request. The sequence of messages is predefined through the use of an Action Control List, whereby the event handler defines the messages to the administrative object.

Description:
CROSS REFERENCE TO CO-PENDING APPLICATIONS  
       [0001]     U.S. patent application No. ______, filed ______, and entitled, “Method and Apparatus for Combining Extended Markup Language and Key Value Pairs into the Format of an Interprocess Message Payload”; U.S. patent application No. ______, filed ______, and entitled, “Interface Cool ICE OLEDB Consumer Interface”; U.S. patent application Ser. No. 09/188,629, filed Nov. 9, 1998, and entitled, “Cool ICE data Wizard”, now U.S. Pat. No. 6,295,531; U.S. patent application Ser. No. 09/188,649, filed Nov. 9, 1998, and entitled, “Cool ICE Column Profiling”; U.S. patent application No. ______, filed ______, and entitled, “Stored Procedure”; and U.S. patent application Ser. No. 09/188,725, filed Nov. 9, 1998, and entitled, “Cool ICE State Management”, now U.S. Pat. No. 6,324,639, are commonly assigned co-pending applications. 
     
    
     BACKGROUND OF THE INVENTION  
       [0002]     1. Field of the Invention  
         [0003]     The present invention generally relates to diverse data base management systems and more particularly relates to enhanced message handling techniques which provide sequencing of multiple messages between client and server applications.  
         [0004]     2. Description of the Prior Art  
         [0005]     Data base management systems are well known in the data processing art. Such commercial systems have been in general use for more than 20 years. One of the most successful data base management systems is available from Unisys Corporation and is called the Classic MAPPER® data base management system. The Classic MAPPER system can be reviewed using the Classic MAPPER User&#39;s Guide which may be obtained from Unisys Corporation.  
         [0006]     The Classic MAPPER system, which runs on proprietary hardware also available from Unisys Corporation, provides a way for clients to partition data bases into structures called filing cabinets and drawers, as a way to offer a more tangible format. The MAPPER data base manager utilizes various predefined high-level instructions whereby the data base user may manipulate the data base to generate human-readable data presentations called “reports”. The user is permitted to prepare lists of the various predefined high-level instructions into data base manager programs called “MAPPER Script”. Thus, users of the Classic MAPPER system may create, modify, and add to a given data base and also generate periodic and aperiodic reports using various MAPPER Script.  
         [0007]     However, with the Classic MAPPER system, as well as with similar proprietary data base management systems, the user must interface with the data base using a terminal coupled directly to the proprietary system and must access and manipulate the data using the MAPPER Script command language of Classic MAPPER. Ordinarily, that means that the user must either be co-located with the hardware which hosts the data base management system or must be coupled to that hardware through dedicated telephone, satellite, or other data links. Furthermore, the user usually needs to be schooled in the command language of Classic MAPPER (or other proprietary data base management system) to be capable of generating MAPPER Script.  
         [0008]     This communication tends to be “interactive” over a session which involves a number of separate and individual transactions. That means that a sequence of messages is transferred between client and server applications. This communication requirement is completely inconsistent with the protocol of publically accessible digital data communication networks, such as the Internet, and is particularly problematic when implementing an interface between otherwise incompatible legacy data base management systems. As a result, prior approaches have tended to force users to individually transfer each of the sequential messages required for a given session.  
       SUMMARY OF THE INVENTION  
       [0009]     The present invention overcomes the disadvantages of the prior art by providing a method of and apparatus for simplifying sequential message traffic between client and server applications involving legacy data base management systems. This technique provides for individually transferring the required messages between client and server applications under control of an Action Control List.  
         [0010]     The preferred mode of the present invention provides a generic messaging protocol that can be used by client/server applications. The properties can be transmitted in different data types such as integer, boolean, BSTR, and VARIANT. The message object also provides the capability to transmit XML, as either a document included in the message, or as XML contained in individual properties. An object API (Applications Programming Interface) is provided to set and retrieve message properties and document information.  
         [0011]     The object API also provides the capability for the message to render itself into a byte stream for transmission across a communications protocol, as well as the ability to reconstitute state from a byte stream received.  
         [0012]     The protocol consists of two primary classes used by the consumer application: the CDACSMesage class and the CDACSMsgProplterator class. The CDACSMessage class provides the primary interface to the message processing with the ability to construct, set and get attributes, or read/write out message content. The CDACSMsgPropIterator class provides an iterator object interface to move through a sequence of properties in the message, so that the keys and value of message properties can be accessed. The message body is a set of CComVariant properties, and a CComBSTR buffer. The CDACSMessage class provides methods for the consumer to manage the properties and document buffer.  
         [0013]     A BSTR is a pointer to a buffer of Unicode characters. The length of the buffer is offset four bytes before the characters begin. The entire buffer is null-terminated, but there can also be null characters embedded in the buffer. The length of the BSTR is one less than the number of characters in the buffer (the buffer includes a final null character), not the length to the first null, in reality, a Unicode “character” is type defined as an unsigned short integer, so a BSTR can point to generic binary information as well as text.  
         [0014]     A BSTR can be utilized as though it were a simple pointer to WCHAR, except for finding length or managing the attached buffer to which it points. For memory management, the Windows libraries provide “system” procedures (SysAllocString, SysFreeString, SysStringLen, etc.), which are packaged conveniently into the CComBSTR class methods.  
         [0015]     To the CDACSMessage consumer, the properties and the attached document buffer constitute the message data. A message need not have both properties and document. It can consist entirely of properties with no document, or have no properties and consist solely of the attached document.  
         [0016]     Properties are indexed by unique integer keys. The consumers define meaning of these keys and the associated CComVariant values. As noted above, the contents of the document can be non-textual binary data.  
         [0017]     The preferred embodiment of the present invention provides an Action Control List object that defines message sequencing and encapsulates the message content that can be exchanged between an event handler and an administrative object. The Action Control List provides a lightweight object to process a series of messages, maintaining state relative to the current action.  
         [0018]     To efficiently sequence the series of messages, the communication is decoupled from the event processing using the Action Control List. This allows the event handler to perform communications with the server application that are independent of administrative object event processing. For example, the need for the client and server applications to initialize requires messaging independent of any specific administrative operation.  
         [0019]     Another aspect is that the Action Control List is in effect a message object itself, extended by the concept of a control list. The action control list derives from a message object, and the message contains the request or response information pertaining to the current action in the list. Hence the administrative object can directly access the request/response information pertaining to the current action in the list.  
         [0020]     Using the command class model requires that a series of concrete command subclasses be constructed that are tightly bound to each administrative object that requires communications in response to an event. The advantage of using the Action Control List is that it provides a lightweight class that is not tightly coupled to the administrative object. Administrative objects encapsulate the action processing and message content relative to the specific event. The Action Control List provides a single class to use for message sequencing and exchange. This allows for better maintainability in terms of administrative object event handling, because the model requires fewer classes be built in order to handle events.  
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0021]     Other objects of the present invention and many of the attendant advantages of the present invention will be readily appreciated as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, in which like reference numerals designate like parts throughout the figures thereof and wherein:  
         [0022]      FIG. 1  is a detailed class diagram showing class definitions for the messaging protocol;  
         [0023]      FIG. 2  is a table showing the methods for managing the message body;  
         [0024]      FIG. 3  is a table showing the method of managing the property list in the CDACSMessage class;  
         [0025]      FIG. 4  is a detailed sequence diagram showing use of the objects to build up the message by a message producer;  
         [0026]      FIG. 5  is a detailed sequence diagram showing how a message consumer application utilizes the object model to retrieve information;  
         [0027]      FIG. 6  is a schematic diagram showing command based message processing:  
         [0028]      FIG. 7  is a schematic diagram showing the operation of  FIG. 13  along with the Action Control List;  
         [0029]      FIG. 8  is the Action Control List class diagram; and  
         [0030]      FIG. 9  is a schematic diagram showing Action Control List message processing along with a list of the associated messages.  
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0031]     The present invention is described in accordance with several preferred embodiments which are to be viewed as illustrative without being limiting. These several preferred embodiments are based upon Series 2200 hardware and operating systems, the Classic MAPPER data base management system, and the BIS software components, all available from Unisys Corporation. When used herein, OLEDB refers to a COM-based Application Programming Interface (API) designed to provide access to a wide range of data sources. OLEDB includes SQL functionality but also defines interfaces suitable for gaining access to data other than SQL data. COM facilitates application integration by defining a set of standard interfaces. Each interface contains a set of functions that define a contract between the object implementing the interface and the client using it. A UDL file contains the complete connection string information, including the data source, userid, password, and any other information needed to logon to and fetch data.  
         [0032]      FIG. 1  is a detailed class diagram that describes the class definitions. Using the object model in the class diagram, a consumer application can send a message to a peer application. Element  290  defines the CDACSMessge class. The integer variables are in turn encapsulated by element  286 . CDACSMsgProplterators are defined in element  292 , which like element  290 , uses the message map of element  288 . The error handling object format is shown at element  294 .  
         [0033]      FIG. 2  is a detailed table showing the methods for managing the message body. In the preferred mode of the present invention, the CDACSMessage class provides methods for managing the message document similar to the CComBSTR methods for managing the attached BSTR. Some of the CDACSMessage methods have similar names and actions as CComBSTR counterparts, except that they apply to the m_bstrDocument member rather than m_str.  
         [0034]     In accordance with the table of  FIG. 1 , the leftmost column lists the basic functions. The corresponding entry within the rightmost column defines the operation associated therewith.  
         [0035]     The CDACSMessage class does not provide methods corresponding to the CComBSTR methods ReadFromStream and WriteFromStream, to write the document to an IStream. Instead, it provides the Save and Load methods for converting between the entire object and a simple memory buffer. Furthermore, the CDACSMessage class does not provide methods corresponding to the CComBSTR method LoadString for loading a string from a resource.  
         [0036]      FIG. 3  is a detailed table showing the methods utilized by CDACSMessage class to manage the property list. The leftmost column provides a listing of the defined operations. The rightmost column offers a complete definition corresponding to each of these operations.  
         [0037]      FIG. 4  is a detailed sequence diagram showing use of the objects to build up the CDACSMessage by a message producer in order to convey a message payload to another application. Each of the preliminary messages  1 - 5  is sequentially initiated by Message Producer  290  as shown. Table  300  provides a detailed description corresponding to each of these preliminary messages. The information is integrated at CDACSMessage  298  into the transportable message  5 . 1 , which is more fully defined in table  300 .  
         [0038]      FIG. 5  is a detailed sequence diagram showing how a message consumer application uses the object model to retrieve the enclosed information. Internal messages  1 - 6  are sent from Message Consumer  302  to CDACSMessage  304  as shown. Each of these is defined in detail in table  306 . Internal message  6 . 1  provides the unpacked data to Message Consumer  302 . Internal message  7  actually shows use of the unpacked data by Message Consumer  302  as defined in table  306 .  
         [0039]      FIG. 6  is a schematic diagram showing the command based message processing. In this example, a client application, shown as Client user interface application  308 , interacts with server application  324  to accomplish a particular task. The actual communications occur between communications  318  and communications  326 . Server application  324  performs the requested operations via function of operation execution  328 .  
         [0040]     The operation of client user interface application  308  is provided by event handler  322 . It notifies administrative object  320  as shown. In response thereto, administrative object  320  calls command object subclasses  316 ,  314 ,  312 , and  310  in that sequence. Each of these command object subclasses sequentially requests service from server application  324  via communication  308 . To perform the desired compound function, services must be sequentially requested from server application  324  in the order shown.  
         [0041]      FIG. 7  is a schematic drawing of the same operations of  FIG. 6  performed under control of the Action Control List of the preferred mode of the present invention. Communication between client user interface application  330  and server application  332  is provided by communications  332  and  334 . The requested services are performed by server application  332  in operation execution  342 .  
         [0042]     However, in this preferred embodiment, event handler  336  and administrative object  340  are linked by Action Control List  338 . All of the required messages are defined by Action Control List  338  in the needed sequence. As a result, Action Control List  338  only needs to be initialized for a given compound service and thereafter, each of the required messages is defined in order.  
         [0043]      FIG. 8  is a detailed class diagram showing operation of the embodiment of  FIG. 7  employing the Action Control List. CDACSActionControl  352  initializes CDACSDelegationBase  352 . CDACSComponent  346  places a call to CDACSComponentData  346  to talk with the server. CDACSMessage  348  represents the request message and response.  
         [0044]      FIG. 9  is a schematic diagram of the message flow, along with a table defining the specific message types. As previously explained, these messages are sequenced by the Action Control List  338  (see also  FIG. 7 ).  
         [0045]     Having thus described the preferred embodiments of the present invention, those of skill in the art will be readily able to adapt the teachings found herein to yet other embodiments within the scope of the claims hereto attached.