File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Web Services and the fly likes Different Message Exchange Pattern interfaces Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "Different Message Exchange Pattern interfaces" Watch "Different Message Exchange Pattern interfaces" New topic

Different Message Exchange Pattern interfaces

Anjali S Sharma
Ranch Hand

Joined: Jun 29, 2005
Posts: 279
We have implemented a Java web service. Now we have been asked to do the following

"Provide different message exchange pattern interfaces for each web service (synchronous, asynchronous, long running, fire and forget"

Can someone please let me know, what changes are required to implement different Message Exchange Pattern Interfaces? Does it require only changing the WSDL or something else also.
I just need to understand if this is a minor change or invovles considerable effort.

Thank You
William Brogden
Author and all-around good cowpoke

Joined: Mar 22, 2000
Posts: 13036
That request is kind of mystifying to me. I would expect a given web service to fit one of those patterns but only one. Seems to me a different pattern means a different service, automatically a different interface.

Maybe someone who understand what is typically meant by "Message Exchange Pattern" means can chime in.

Jim Akmer
Ranch Hand

Joined: Jul 06, 2010
Posts: 104

- For synchronous operation this means that the web client will send a request to the web service, and will wait for the response. Once the response arrives the client continues processing. This is a standard Message Exchange Pattern (MEP)
- For asynchronous operation, it means that the client will send a request but will not wait for the response. The client will continue with other processing and will process the response when it is available. This is implemented in the client in 2 ways (in jaxws): using polling (check dispatch.invokeAsync interface) or using asynchronous handlers. In the second case, a thread receives the response and the client handler is called to process it. For this either the wsdl is modified or an external bindings file is used
- Fire and forget is the one way operations defined in wsdl. I.e. the client sends a request and does not care for a response. It is a standard MEP
- For long running, I am not sure what you mean as it can mean different things.

I think that what it is requested from you is to enable the client to choose for an operation if it will block for a response, or receive it asynchronously for higher performance, or even send something and not wait for a result. For the fire and forget and the synchronous operation, there should be the corresponding definitions in the wsdl. For the asynchronous operation, there is no need for a modification in the wsdl, if an external bindings file is used. 2 client methods should be created
For the long running, I am not sure what is meant
Anjali S Sharma
Ranch Hand

Joined: Jun 29, 2005
Posts: 279
>> think that what it is requested from you is to enable the client to choose for an operation if it will block for a response

Will that mean that I'll have to create different services for each of these Message Exchange Patterns?
Ivan Krizsan
Ranch Hand

Joined: Oct 04, 2006
Posts: 2198
To add some minor things to the excellent replies above:

Note that there are two kinds of asynchronicity in connection to web service invocations:
1. Asynchronous client invocation.
The web service is still synchronous, but the operation in the generated stubs in asynchronous and the client will receive a Future object that it can use to retrieve the result of the operation from.
This is accomplished by enabling an option when generating the client artifacts using wsimport.
Thus, this option does not require a special endpoint implementation - you can reuse the regular, synchronous one.
2. Asynchronous web service.
The web service itself is asynchronous. Typically this means that, when receiving a request, it transfers the request to a queue and ends the processing of the request. A special thread or process later processes the request.
There are two ways for the client to obtain a result from such an operation:
- Polling.
A special operation exists in the web service that, given a correlation identifier returned as a result from the original request, returns a result if it is available.
- Callback.
The client provides a service with at least one operation. This operation is used by the original web service to report the result of the asynchronous operation. Compare with the Observer design pattern.
This option require a special endpoint implementation. Perhaps even substantial work on the client side if you choose to use callbacks.

The asynchronous web service alternative may be what they mean by long running. However, my advice is not to trust our speculations here, but to ask your customer directly - they are the ones that know best. At least, if they themselves have told you to do something and later realize it is not what they wanted, it will be easier to bill hours for the time spent on doing what they did not want.

Finally, if you want to implement callbacks but fear you have to write a lot of code, you may want to take a look at Apache Tuscany (or any other SCA implementation) that enables implementation of asynchronous services with callbacks with less effort.
Best wishes!

My free books and tutorials:
Jim Akmer
Ranch Hand

Joined: Jul 06, 2010
Posts: 104
No, you do not have to create different web services for the synchronous and fire and forget. 1 portType (i.e. service) different operations (i.e. methods)
For the asynchronous I think the same. But it also requires changes in the client code. See detailed post of Ivan
I agree. Here's the link:
subject: Different Message Exchange Pattern interfaces
It's not a secret anymore!