• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Different Message Exchange Pattern interfaces

 
Ranch Hand
Posts: 279
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Bill
 
Ranch Hand
Posts: 104
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

- 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
Posts: 279
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
>> 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?
 
Ranch Hand
Posts: 2198
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi!
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!
 
Jim Akmer
Ranch Hand
Posts: 104
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic