Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Asynchronous SOAP

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am starting a new project which involves subscribing to a service at our clients server.
The access is gained through SOAP over HTTP/S. In their documentation they say we can subscribe to a particular service and they will send asynchronous responses.
The way they achieve this is for us to give them an address and port number in the subscription, then listen on a socket at our side for the asynchronous responses.
I am new to SOAP and my question is, is this an odd way to implement a service in SOAP, in fact downright wrong? SOAP strikes me as the wrong technology for what they want to do.
To add to my reservations I am behind a firewall, from what I read makes SOAP ideal as it is over HTTP, although not the way they are implementing it.
My point is, this could be a common way of achieving asynchronous comms using SOAP, but everything I read suggests otherwise.
Any views would be much appreciated.
Thanks.
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
SOAP messages can be passed any way you can move a chunk of XML text around. Dedicating a socket to it sounds unusual, but it should work. Seems to me that using SOAP instead of some other XML format just means you can find the tools to work with the message more easily. You will have to open a port in your firewall of course.
If I was doing the service I think I would use email to send the SOAP messages.
Bill
 
Ranch Hand
Posts: 906
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The scenario explained by Davie sounds like the "Basic Callback messaging".
It's not really unusual. You send a request with info(server+port+service) for the response. You first receive an acknowledgement (synchronously).
Then later, you will receive the real response to your request. The correlation identifier pattern will allow you to link this asynchrous response with the request.

But maybe I've misunderstood what your partner want you to do.. ???
 
author
Posts: 361
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Davie Lang:
I am starting a new project which involves subscribing to a service at our clients server.
The access is gained through SOAP over HTTP/S. In their documentation they say we can subscribe to a particular service and they will send asynchronous responses.
The way they achieve this is for us to give them an address and port number in the subscription, then listen on a socket at our side for the asynchronous responses.
I am new to SOAP and my question is, is this an odd way to implement a service in SOAP, in fact downright wrong? SOAP strikes me as the wrong technology for what they want to do.
To add to my reservations I am behind a firewall, from what I read makes SOAP ideal as it is over HTTP, although not the way they are implementing it.
My point is, this could be a common way of achieving asynchronous comms using SOAP, but everything I read suggests otherwise.
Any views would be much appreciated.
Thanks.


Hello Davie,
It is certainly possible to use JMS as a transport for SOAP messages. The obvious advantage of JMS over HTTP is that it allows asynchronous communication, which effective decouples the service requester from the service provider. This places a Message Driver Bean (MDB) in the role of controller in a J2EE 1.3 enterprise application. The MDB forwards the message to a Session Bean to handle the business logic. Hope this helps.
Regards,
 
You got style baby! More than this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic