WO2002023334A2

WO2002023334A2 - Extended asynchronous messaging

Info

Publication number: WO2002023334A2
Application number: PCT/US2001/028847
Authority: WO
Inventors: David Carpenter; Lori Clark; Harold Weir; Derek Jones
Original assignee: Learnframe, Inc.
Priority date: 2000-09-15
Filing date: 2001-09-14
Publication date: 2002-03-21
Also published as: AU2001290971A1; WO2002023334A3

Abstract

The present invention implements communication between objects using asynchronous communications utilizing a messaging service for providing distributive communications. The present invention extends such an implementation to include the ability to facilitate retention of state for implementing a stateless-capable messaging system configuration through the use of a message accessor which provides a data store for retaining persistent data such as state information. The messaging service retains state information by providing a message object that holds the state of the request, data required to fulfill the request, replies to extension requests for the original request and additional data and information as needed. Each time a component is invoked by receiving a message, the message object is employed so that the state can be restored.

Description

EXTENDED ASYNCHRONOUS MESSAGING

CROSS-REFERENCE TO RELATED APPLICATIONS [01] The present application claims priority from and is a continuation-in-part of U.S. Provisional Patent Application No. 60/233,070, entitled EXTENSIBLE DEVELOPMENT PLATFORM, which was filed on September 15, 2000, and is hereby incorporated by reference in its entirety. Additionally, the present application is related to and includes the disclosure of Assignee's co-pending U.S. Patent Application Serial No. entitled EXTENSIBLE SOFTWARE DEVELOPMENT USING ASYNCHRONOUS MESSAGING (Attorney Docket No. 15016.30), which is hereby incorporated by reference in its entirety; and Assignee's co-pending U.S. Patent Application Serial No. , entitled CONSTRUCTION OF VIRTUAL OBJECTS BASED

ON RUN-TIME TYPE INFORMATION (Attorney Docket No. 15016.31), which is hereby incorporated by reference in its entirety.

BACKGROUND OF THE INVENTION 1. The Field of the Invention

[02] This invention generally relates to computing systems, and more particularly to a system and method for improving messaging between objects in software applications. 2. The Relevant Technology

[03] Software applications are developed using a modularity concept wherein an overall software application is partitioned into separate functional blocks, objects, or components which accomplish a specific task and lend themselves to software reuse and parallel programming. While it is desirable for components to be independent, there exists a need for communicating between components to accomplish the overall objective of the software application.

[04] Communication between components has generally taken the form of synchronous communications which means that processing stops while waiting for a reply from the object. In very large scale systems this is a performance and resource problem because resources are in process waiting on a return these waiting resources cannot be reused cr recycled, thereby limiting available resources and causing processes to block or wait. [05] Figure 1 illustrates a traditional synchronous component call between a first component 100 and a second component 104. In the example of Figure 1, a call 102 is directed at component 100 which requests, in a call 106, the services of another component 104 in order to service the call. Component 104 performs the requested functionality while the resources associated with the instantiation of component 100 remain engaged. Upon completion of the functionality within component 104, a return value in the form of a reply 110 is sent back to component 100, which is further returned in a reply 112 to the requestor. During such a dedicated resource scenario, the instantiation of component 100 and all of the associated resources remain inefficiently engaged while awaiting the return value from component 104. [06] Another inter-component communication approach utilizes a messaging configuration wherein a standardized messaging protocol is defined and supported allowing components to issue calls to one another through and intermediary messaging service that handles the more mundane transport and other similar routing functionality. Figure 2 illustrates such a messaging service example wherein a component 200 interacts with a component 202 upon the receipt of a call request 208. Component 200 processes the call 208 and formulates a send message 210 to an intermediary service object such as messaging service 204, illustrated as a Java Messaging Service (JMS) message. Messaging service 204 performs the necessary transport and routing services to locate component 202 and issues a method call 212 to component 202. Component 202 performs the requested service in step 206 and issues a send message 214 to messaging service 214. Messaging service 204 prepares a method call 216 and routes it to component 200 which returns a reply 218 in response to request 208. The inter-component calling of Figure 2 illustrates utilization of a messaging service, however, the operation involves synchronous calls which require component 200 to remain instantiated until delivery of reply 218 occurs.

[07] Figure 3 illustrates yet another example of utilization of a messaging service, however, the present example utilizes an asynchronous mode in the messaging service. As with the synchronous example, this asynchronous example also depicts use of JMS. The asynchronous nature of the present example results in loss of state information as such a mode does not provide state or more complex message handling. By contrast with synchronous messaging, asynchronous messaging approaches simply marshal a message from a requestor to one listener and then lets the requestor know that the listener received the message successfully. This is called an acknowledgement and is the most information that can be retrieved from a typical messaging service such as JMS.

[08] Figure 3 illustrates call 302 coming into component 300 in a first instantiation which sends message 306 to messaging service 308, which in turn, issues a method call 310 to component 312. Meanwhile, instantiation of component 300 is terminated allowing the resource to be reallocatable while component 312 performs functionality 314 and issues a send message 316 when complete. Similarly, messaging service 308 issues a method call 318 to the object which creates a second instantiation of the original component, illustrated as component 320. While asynchronous communications may alleviate some of the resource reallocatable shortcomings of synchronous communications, is still does not address the need to provide state information when returning to another instatiation of the requesting component.

[09] Therefore, there exists a need to provide a messaging service that does not require processing to stop while waiting for a reply from an object. Furthermore, it would be desirable to free-up resources for reuse during processing by an object.

BRIEF SUMMARY OF THE INVENTION [010] The present invention operates as an asynchronous messaging system with persistence capability for state and other information. The present invention provides a message object that holds the state of the request, data required to fulfill the request, replies to extension request for the original request and additional data and information as needed. Each time a component is invoked by receiving a message, the message object as referenced by a handle is provided so that state can be restored. Each message using the present invention contains several parts, namely an interface, required data, an implementation of the definition interface, a set of replies to the message, and a parent message identifier. [Oil] The messaging service provides the ability to handle multiple types of messages. One preferred implementation utilizes an existing messaging service, such as the Java Messaging Service (JMS), for providing distributive communications. The present invention extends such an implementation in order to improve messaging capability between components. The preferred embodiment of the present invention achieves improved performance by extending traditional messaging to include the ability to facilitate retention of state for implementing a state-capable messaging system configuration, which means that a component does not store information about what it was doing from one invocation to the next. Stateless objects or components are normally used to perform actions that require saved information, such as calculating sales tax on an order, while the order contents are normally determined using a stateful object or component. To enhance performance, the present invention implements all components as stateless which dictates that state information must be saved in a place remote from the components.

[012] The messaging service of the present invention retains state information by providing a message object that holds the state of the request, data required to fulfill the request, replies to extension requests for the original request and additional data and information as needed. Each time a component is invoked by receiving a message, the message object is employed so that the state can be restored.

[013] These and other objects and features of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS [014] To further clarify the above and other advantages and features of the present invention, a more particular description of the invention will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of its scope. The invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

[015] Figure 1 illustrates synchronous inter-component interaction, in accordance with the prior art;

[016] Figure 2 illustrates synchronous inter-component interaction utilizing a messaging service, in accordance with the prior art;

[017] Figure 3 illustrates asynchronous inter-component interaction utilizing a messaging service, in accordance with the prior art;

[018] Figure 4 illustrates the flow of control in an inter-component asynchronous extended messaging service, in accordance with a preferred embodiment of the present invention; [019] Figure 5 is a block diagram of the respective functional blocks comprising a preferred embodiment of an extended messaging service, in accordance with the present invention; [020] Figure 6 illustrates and exemplary flow diagram of inter-component messaging wherein a reply is received back at the requesting component, in accordance with a preferred embodiment of the present invention; and [021] Figure 7 illustrates and exemplary flow diagram of inter-component messaging wherein no reply is expected at the requesting component, in accordance with a preferred embodiment of the present invention

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS [022] The present invention implements communication between objects using asynchronous communications. Asynchronous communication means that when a request is made to an object, the requester does not wait for a reply. In such an implementation, the requestor resources may shut down, be recycled, or continue on with other processing, depending upon the implementation or usage. Using an asynchronous messaging system provides the ability to communicate with other objects or components in an efficient manner that makes the best use of resources.

[023] One preferred implementation utilizes an existing messaging service, such as the Java Messaging Service (JMS), for providing distributive communications. The present invention extends such an implementation in order to improve messaging capability between components. The preferred embodiment of the present invention achieves improved performance by extending traditional messaging to include the ability to facilitate retention of state for implementing a stateless-capable messaging system configuration, which means that a component does not store information about what it was doing from one invocation to the next. Stateless objects or components are normally used to perform actions that are require saved information, such as calculating sales tax on an order, while the order contents are normally determined using a stateful object or component. To enhance performance, the present invention implements all components as stateless which dictates that state information must be saved in a place remote from the components.

[024] The messaging service of the present invention retains state information by providing a message object that holds the state of the request, data required to fulfill the request, replies to extension requests for the original request and additional data and information as needed. Each time a component is invoked by receiving a message, the message object is employed so that the state can be restored.

[025] Figures 4 and 5 will be discussed together and references between the related figures will not necessarily be differentiated as Figure 4 illustrates the flow control relative to the functional elements illustrated in Figure 5. Figures 4 and 5 illustrate an extended messaging system 400 comprised of a messaging component 402 and a message accessor 404. [026] Messaging component 402 is preferably comprised of a component 406 and a messaging bean 408. Messaging bean 408 is the base class for any component for interfacing with the extended messaging service of the present invention. Messaging bean 408 further provides the API that enables component 406 to utilized the extended messaging services. In a preferred implementation, messaging bean 408 is implemented in a "lightweight" or pared- down, minimal-processing manner.

[027] Messaging component 402 further includes a messenger 410 which is also implemented as a "lightweight" and efficient element. Additionally, messaging component 402 also includes a message broker 412 which operates as a pass-through class acting as the gateway to the message accessor 404. Message broker 412 assumes responsibility for making all remote method calls to message accessor 404. [028] Remote method invocation 414 facilitates remote method calls to classes which are provided on remote or local services.

[029] Message accessor 404 provides the mechanism for retaining state information relating to specific requests and replies that are physically facilitated through the transport functionality of a messaging service such as JMS. Message accessor 404 is comprised of a message accessor EJB 416 and a table manager 418. Message accessor 416 performs preprocessing for table manager 418. Table manager 418 manages tables 420 that derive from the table class. [030] Tables 420, in a preferred embodiment, are comprised of five tables:

1) a message table 422 provides persistent storage for the message data;

2) a reply table 424 provides persistent storage for the reply data;

3) a component table 426 provides persistent storage for the component configuration;

4) a message type table 428 provides persistent storage for the message configuration details (e.g., receiver list);

5) a timer table 430 provides persistent storage for scheduled events.

[031] Message accessor 404 further includes a database access 432 for persisting the data. Database access 432 includes a backup database 434 for storing to the database while restore database 436 is for retrieving from a data store 438. Database access 432 provides the interface to the physical data store 438.

[032] Figure 6 illustrates a typical message flow wherein a reply is generated back to the requesting component using the extended messaging service, in accordance with a preferred embodiment of the present invention. Figure 6A illustrates sending a message from component 1 to component 2 while Figure 6B illustrates sending a reply from component 2 to component 1.

[033] As illustrated, component 600 receives a call 602 for specific services. In a step 604, component 600 creates a skeleton message and creates a message accessor 404 and issues a create message call in a step 606. In a step 608, message accessor 404 looks up the message type and receiver list, creates skeleton replies, creates expiration time, and stores the updated message data in the persistent message store 438. Message accessor, in a step 610, returns the updated message data to the caller, component 600. Thereafter, component 600, in a step

612, creates a message handle from the message data returned.

[034] Component 600, in a step 614, sends the message handle via a messaging service 500, which according to a receiver or listener list stored therewith, delivers in a step 616 the message to each component, such as component 618, in the receiver list. In a step 620, component 600 returns the message handle to the caller and component 600 can now be removed with the corresponding resources being freed for other uses.

[035] In step 616, component 618 is created and its message handle method called.

Component 618 creates a message accessor 404 in a step 622 and calls a get message handle to the message accessor 404. In a step 624, message accessor 404 looks up the message corresponding to the message handle and in a step 626, returns the message to the caller, component 618 allowing component 618, in a step 628, to process the message and completes the process of sending a message from component 1 to component 2.

[036] Figure 6B illustrates sending a reply from component 2 to component 1. As illustrated, component receives a call and in a step 650, component 618 creates a skeleton reply data message. In a step 652, component 618 creates an instance of message accessor 404 and call a save reply method. In a step 654, message accessor 404 looks up the skeleton reply and saves the reply data in the persistent message/data store 438. In step 656, message accessor 404 returns the updated reply data to the caller and in a step 658, component 618 checks the reply priority and determines whether to send the reply immediately. If immediate is selected, component 618 creates a reply handle from the reply data returned. [037] Utilizing a messaging service 500, component 618 sends the reply handle via the messaging service in a step 660. In a step 662, component 618 returns the reply handle to the caller and the instantiation of component 618 may be removed thereby freeing the resources for future allocation.

[038] In a step 664, component 600 is created and its reply handle method is called. Component 600 in turn creates, in a step 666, a message accessor 404 and calls to get the reply handle. In a step 668, message accessor 404 looks up the reply corresponding to the reply handle and returns the reply to the caller in a step 670. Thereafter, in a step 672, component 600 processes the reply.

[039] Figure 7 illustrates sending a message from component 1 to component 2 according to the extended messaging of the present invention wherein a reply is not dispatched back to the requesting component. A component 700 receives a call whereupon component 700 engages the services of another component 702. To do so, component 700 creates a message accessor 404 and calls a get handle method from message accessor 404 in a step. In a step 706, message accessor 404 looks up the receiver list of the original message corresponding to the handle and in a step 708 returns the list to the caller. In a step 710, component 700 creates an alert message with the receiver list. [040] In a step 712, component 700 sends the alert via a messaging service 500 to each component in the receiver list. In a step 714, control is returned to the caller and component 700 may now be removed, hi a step 716, component 702 is created and the alert method is called followed by the processing of the alert by component 702 in a step 718. [041] The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

CLAIMS What is claimed is:

1. In an object-oriented program, a method of communicating a message as requested by a caller between a first component and a second component using an asynchronous messaging service, comprising the steps of: a. said first component providing persistent data to a message accessor having a data store therein to form message data, said persistent data including state information; b. said message accessor retrieving from said persistent data messaging configuration including a receiver list including at least said second component; c. said first component creating a message handle directed at said message data; d. said first component via said asynchronous messaging service sending said message handle to each receiver on said receiver list including said second component; and e. said second component retrieving said message according to said message handle from said message accessor.

2. The method as recited in claim 1, wherein said providing persistent data step further comprises the steps of: a. said first component creating a framework for said message data; and b. said message accessor populating said framework of said message data with said persistent data to return to said first component.

3. The method as recited in claim 1, wherein said second component retrieving said message step further comprises the steps of: a. said second component creating said message accessor; b. said second component retrieving said message from said message accessor corresponding to said message handle; and c. said message accessor returning said message to said second component.

4. The method as recited in claim 1, further comprising the step of: a. said second component generating a reply including state information to said first component for delivery to said first component over said asynchronous messaging service.

5. The method as recited in claim 4, wherein said generating a reply step further includes the steps of: a. said second component obtaining updated persistent data from said message accessor to form updated reply data including state information; b. said second component creating a reply handle directed at said updated reply data; c. said second component via said asynchronous messaging service sending said reply handle to said first component; and d. said first component retrieving said updated reply data according to said reply handle from said message accessor.

6. The method as recited in claim 5 wherein said obtaining updated persistent data step further comprises the steps of: a. said second component creating a reply framework for said updated reply data; and b. said message accessor populating said reply framework of said updated reply data with said persistent data to return to said second component.

7. The method as recited in claim 5, wherein said first component retrieving said updated reply data step further comprises the steps of: a. said first component creating said message accessor; b. said first component retrieving said reply from said message accessor corresponding to said reply hand; and c. said message accessor returning said reply to said first component.

8. The method as recited in claim 1, wherein said asynchronous messaging service is a Java messaging service.

9. A computer-readable medium having computer-executable instructions for communicating a message as requested by a caller between a first component and a second component using an asynchronous messaging service, said instructions performing the steps of: a. said first component providing persistent data to a message accessor having a data store therein to form message data, said persistent data including state information; b. said message accessor retrieving from said persistent data messaging configuration including a receiver list including at least said second component; c. said first component creating a message handle directed at said message data; d. said first component via said asynchronous messaging service sending said message handle to each receiver on said receiver list including said second component; and e. said second component retrieving said message according to said message handle from said message accessor.

10. The computer-readable medium, as recited in claim 9, wherein the computer-executable instructions for performing the step of providing persistent data step further comprises computer-executable instructions for performing the steps of: a. said first component creating a framework for said message data; and b. said message accessor populating said framework of said message data with said persistent data to return to said first component.

11. The computer-readable medium, as recited in claim 9, wherein the computer-executable instructions for performing the step of said second component retrieving said message further comprises computer-executable instructions for performing the steps of: a. said second component creating said message accessor; b. said second component retrieving said message from said message accessor corresponding to said message handle; and c. said message accessor returning said message to said second component.

12. The computer-readable medium, as recited in claim 9, further comprising computer-executable instructions for performing the steps of: a. said second component generating a reply including state information to said first component for delivery to said first component over said asynchronous messaging service.

13. The computer-readable medium, as recited in claim 12, wherein said computer-executable instructions for performing the step of generating a reply further includes computer-executable instructions for performing the steps of: a. said second component obtaining updated persistent data from said message accessor to form updated reply data including state information; b. said second component creating a reply handle directed at said updated reply data; c. said second component via said asynchronous messaging service sending said reply handle to said first component; and d. said first component retrieving said updated reply data according to said reply handle from said message accessor.

14. The computer-readable medium, as recited in claim 13, wherein said computer-executable instructions for performing the steps of obtaining updated persistent data step further comprises computer-executable instructions for performing the steps of: a. said second component creating a reply framework for said updated reply data; and b. said message accessor populating said reply framework of said updated reply data with said persistent data to return to said second component.

15. The computer-readable medium, as recited in claim 13, wherein said computer-executable instructions for performing the step of said first component retrieving said updated reply data step further comprises computer-executable instructions for performing the steps of: a. said first component creating said message accessor; b. said first component retrieving said reply from said message accessor corresponding to said reply hand; and c. said message accessor returning said reply to said first component.

16. The computer-readable medium, as recited in claim 9, wherein said assyncronous messaging service comprises computer-exeuctable instructions for implementing said asynchronous messaging service in accordance with a Java messaging service.