Related Patterns

There are a few patterns to consider when designing asynchronous communication across Java EE and .NET.

Java EE Web Service Broker and .NET Service Interface Patterns

Problem Domain

It is often desired to separate business logic from the initial request processing. With SOA it is essential to define a Web service in a way that hides the complexity of the business processing and details of the request processing call chain. Instead, it is necessary to expose a coarse-grained, high-level interface to Web service consumers.

Solution

Both Java EE and .NET implement this idea through a pattern that differs in name depending on the technology referred to. The Java EE Core Pattern catalog lists this pattern under the Web services Broker, while under .NET this pattern is called the Service Interface. In both cases this component introduces a layer of abstraction between the Web service consumer and the service implementation details. In the Replenish Stock use case, this layer is realized with ManufacturerFaçade ASP.NET. The actual implementation class corresponds to the POValidator, while the Warehouse class acts as the WS consumer.

Asynchronous Request Assembler

Problem Domain

Initiating an asynchronous call to the remote Java EE or .NET system may require aggregating various properties as part of the request preparation routine. The Assembler is responsible for preparing the request in the corresponding format. There is also a need to look up a remote service and pass the request to the remote Java EE or .NET system. Finally, depending on business requirements, there may be a need to log an acknowledgement based on making an asynchronous call.

Solution

The Asynchronous Request Assembler ensures correct mapping from a schema or auto-generated stub classes into the corresponding domain object. It also provides a means of sending this request to the remote system and logging an acknowledgment or a fault.

There are related patterns from the Core Java EE Pattern catalog that are similar to this one or can be used in conjunction with the Asynchronous Request Assembler. A Service Locator can be used, for example, to look up the remote .NET or Java EE Web service. A Business Delegate can be used to submit the actual request.

Asynchronous Request Handler

Problem Domain

To ensure reliability of asynchronous calls across distributed applications, there should be a component on each system that is responsible for tracking incoming calls.

Solution

While Java EE does not yet support the WS-Reliable Messaging, and .NET will be supporting it as part of the Indigo release, having custom components that trace incoming requests across distributed systems can be thought of as an option. In some cases architects may choose messaging as a communication mechanism rather than the asynchronous Web services to leverage full support of reliable messaging.

Compensating Asynchronous Request Handler

Problem Domain

Should reliability be enabled, it would be necessary to ensure that there is corresponding logic for rolling back any changes that have been submitted in case there is a failure.

Solution

The Asynchronous Request Handler is responsible for monitoring asynchronous calls for errors. If a call times out or if a problem occurs during the asynchronous request processing, this component has to issue a compensating transaction to rollback all changes that already have been submitted.

Orchestrate Asynchronous Calls

Problem Domain

Should multiple asynchronous calls span across multiple systems, it is worth considering an orchestration engine.

Solution

An orchestration engine component would coordinate Web services calls across different systems, such as Java EE and .NET. There is already an industry specification, WS Orchestration, and a set of products that can be used to avoid building this orchestration engine from scratch.