Asynchronous SOAP

[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.

[William Brogden]

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

[JeanLouis Marechaux]

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.. ???

[Howard Kushner]

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,