At the end of Chapter 7, "Creating a Shared Database," you saw an example of how a Data Access Object (DAO) class in Java can send a message to a DAO class in .NET to indicate that an operation on the database has been completed. In the sample, this message notified the .NET application to refresh the display in order to show the new record that had been added.
This type of communication and all the samples shown in Part II of the book, "Interoperability Technologies: Point to Point," depict types of calls between the .NET and Java platforms that are synchronous in nature. This means that the calling application waits for an acceptance or result from the receiving application before continuing and that the receiving application must be available to receive the message as it's being sent.
Although synchronous calling helped illustrate interoperability between the two platforms in the preceding chapters, many situations require an asynchronous approach. An example of this occurs when the receiver isn't available to immediately process the incoming message. This might be due to some planned or unplanned offline operation, or it might be due to the receiver being too saturated to immediately deal with the incoming request.
Another example of asynchronous calling occurs when the request takes a long time to process before an answer is returned to the client. This is known as a long-running process . For example, imagine a loan application process in which credit details for the applicant have to be collected from various sources before an acceptance can be returned. This credit check might take seconds, minutes, hours, or even days to complete. In either case, the calling application probably doesn't need to wait for the result ”and can instead work on submitting more loan applications.
In a system that has a mix of processes running on .NET and J2EE, such situations demand a level of asynchronous interoperability between the two platforms. The term asynchronous tends to be overloaded: many definitions and interpretations of the word exist. In this chapter, we'll look at two types of asynchronous examples: nonblocking asynchronous calls and fire-and-forget asynchronous calls .
In a nonblocking asynchronous call, the asynchronous style of the request is handled by the client. The actual call is synchronous in nature, but the client handles the call in another thread or process (giving the impression that the call is asynchronous).
In a fire-and-forget asynchronous call, the asynchronous nature of the call is handled by the architecture of the system. The client sends a message, and at some point in the future, is able to view the status of the message and/or receive the result.
Let's start by looking at asynchronous-supported calls in XML Web services (which will demonstrate nonblocking calls in action). We'll then continue to explore fire-and-forget asynchronous interoperability by using the Microsoft Message Queuing product, MSMQ.