Hi Ricky and Suresh,
[Ricky]
| Of course HTTP transport is the only one that gives you
|inter-operability. But if the reliability of callback is not important,
|then I would prefer callback over UDP multicast which is more scalable
|(when you have a lot of subscribers).
Uhm ..., I think UDP is not enough to notify the callback events
to the client on the grounds of the following weakness;
1)Reliability: The UDP packets might be lost depending on the network
conditions, as you may know.
2)Security : The multicast pakets have a risk to wiretap by unconcerned
people (i.e. many other clients).
3)Traffic : The multicasting is the couse of high-traffic network.
4)Scope : The scope of the multicasting will be inside the private
network such as 'the same segment' or 'intranet'.
[Suresh]
| A SOAP client registers with a SOAP server: <send me a message when
|event XYZ occurs>
|
| When XYZ occurs, how should the server callback? Is there anything
|provided as part of the Axis framework?
Have you heard about the asynchronous API on axis ? One of the
proposal is comprised in the 'xml-axis/proposals/async' directory
of the axis package.
And some additional 'evolutionary' codes are stored in the package
'xml-axis/java/src/org/apache/axis/ime'. AXIS has a plan to enhance
this task after they release 1.1 final. I got this info on axis-dev.
By the way, what's the important thing you want to do ?
Do you just want to receive a message after a specified event on
the server? Or, do you have to kick a process on the client side?
The former will be solved by using e-mail (SMTP), the latter will
be able to be cleared with two approaches;
# [C]-->'Client task' : [S]-->'Server task'
a)Blocking the response on the server side:
[C]: Invoke a Web Service and wait a response ...
[S]: Start the Web Service, and do processing ...
(do not send the response at the time)
[S]: Done the process, and sends back a response
[C]: Receive the message
b)Deploying a Web Service to receive the response on the client side:
- Phase 1 - (Request)
[C]: Invoke a Web Service and wait a response ...
[S]: Start the Web Service (and sends back a response)
([C]: Receive the response)
- Phase 2 - (Response)
[S]: Done the process, and invoke a Web Service on the client
[C]: Start the 'client-side' Web Service (and sends back a response)
([S]: Receive the response)
The case of 'b)', there're several hurdles to cross over. So I think
the 'a)' is the easiest way at this time, if it's acceptable to you.
I don't know about your background in this Q&A ...
Best Regards,
Toshi (Toshiyuki Kimura) <[EMAIL PROTECTED]>
R&D Headquarters
NTT DATA Corporation
-----Original Message-----
From: Ricky Ho [mailto:[EMAIL PROTECTED]
Sent: Monday, March 17, 2003 1:26 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Callbacks in SOAP application
>
>A SOAP client registers with a SOAP server: <send me a message when event
>XYZ occurs>
The client should register: <send me a message AT THIS LOCATION when the
event XYZ occurs>
>When XYZ occurs, how should the server callback? Is there anything
>provided as part of the Axis framework?
The server callback to the location that the client specify at his
registration. The response of this callback can optionally piggyback an
un-registration request of the client.
>1. Should this be done out of Axis framework; for example, client may have
>an HTTP server listening at a registered port and SOAP server does an HTTP
>POST when the event occurs?
Your description is same as mine and is do-able outside AXIS framework.
>2. Is this task easier if the transport is asynchronous, like JMS?
I don't think so. Because soap is transportation agnostic. In both cases,
the server need to know where to send back the response. In JMS case, this
mean the client specify the return location at the "reply-to" message
property.
>3. Any other solution which you could suggest (preferably having HTTP
>transport).
Of course HTTP transport is the only one that gives you
inter-operability. But if the reliability of callback is not important,
then I would prefer callback over UDP multicast which is more scalable
(when you have a lot of subscribers).
Rgds, Ricky
>Thanks,
>Suresh
