Hi Rodrigo,
Thank you very much for taking your time and sharing your thoughts with
me.
I forgot to mention that I already used WS-Addressing. Sorry for that.
Actually, after Anne's reply, I looked at the spec and noticed that I
needed to spend more time on WS-Addressing :-)
If you don't mind I need to ask some questions regarding your reply.
> 2) The solution you are considering is basically correct, but
> putting and EndPointReference to the service will be better
> than a simple service name. Shortly, it will safe you some
> programming at the client side if you get a ready-to-use EPR ;-)
Do you mean that I should use something like this:
<wsa:EndpointReference>
<wsa:Address>xs:anyURI</wsa:Address>
<wsa:ReferenceProperties>... </wsa:ReferenceProperties>
<wsa:ReferenceParameters>... </wsa:ReferenceParameters>
<wsa:PortType>xs:QName</wsa:PortType>
<wsa:ServiceName PortName="xs:NCName">xs:QName</wsa:ServiceName>
<wsp:Policy> ... </wsp:Policy>
</wsa:EndpointReference>
If yes, where should I put this in WSDL? And how do I add it to my
ResultIsReadyMsg?
> Some thoughts about your description:
>
> - You should include an EPR in OpenAccountMsg, pointing to the
> service
Do you mean the client need to add <wsa:ReplyTo> in OpenAccountMsg? If
yes, how can I enforce it in WSDL?
> - Why do not you include the results in the event notification
> itself?
I want the client.wsdl to be as simple as possible. Since I provide
Get<X>Result services for all the asynchronous services (<X>), clients
already know how to handle the responses. I thought that it would be
extra work for them implementing Accept<X>Result services, too. You
might say me to only use Accept<X>Result in client.wsdl and remove
Get<X>Result from the server.wsdl. But, I have to provide Get<X>Result
services to handle notification error situations. Thus, the clients
will be able to query if they somehow haven't got the notification
message yet.
Again, thank you very much for your valuable comments.
Best regards,
Ali Sadik Kumlali
--- Rodrigo Ruiz <[EMAIL PROTECTED]> wrote:
> Ali,
>
> 1) The scenario you describe seems correct to me. Event Notification
> is
> a rather common pattern, and some specifications that can be of help
> are
> WS-Eventing and WS-BaseNotification. Anyway, your scenario is simple
> enough for, as Anne stated, WS-Addressing being enough to implement
> it.
>
> 2) The solution you are considering is basically correct, but putting
>
> and EndPointReference to the service will be better than a simple
> service name. Shortly, it will safe you some programming at the
> client
> side if you get a ready-to-use EPR ;-)
>
> Some thoughts about your description:
>
> - You should include an EPR in OpenAccountMsg, pointing to the
> service
> that will receive the notification in the client side.
> - Why do not you include the results in the event notification
> itself?
>
> Regards,
> Rodrigo Ruiz
>
> Anne Thomas Manes wrote:
> > WS-Addressing.
> >
> > On 4/27/06, *Ali Sadik Kumlali* <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> wrote:
> >
> > Hi all,
> >
> > I want to send a notification message to my clients when their
> requests
> > are processed and the results are ready. Then I expect them to
> call a
> > service to acquire the results. Here is the sample scenario:
> >
> > server.wsdl
> > ------------
> > - OpenAccount
> > - input: OpenAccountMsg
> >
> > - GetOpenAccountResult
> > - input: GetOpenAccountResultMsg
> > - output: GetOpenAccountResultResponseMsg
> >
> > client.wsdl
> > ------------
> > - ResultIsReady (input only)
> > - input: ResultIsReadyMsg
> >
> >
> > OpenAccountMsg (MessageId: A)
> > Client ----------------------------------------------------->
> Server
> >
> >
> > ResultIsReadyMsg (MessageId: B, RelatesTo: A)
> > Client <-----------------------------------------------------
> Server
> >
> >
> > GetOpenAccountResultMsg (MessageId: C, RelatesTo: A)
> > Client ----------------------------------------------------->
> Server
> > <-----------------------------------------------------
> > GetOpenAccountResultResponseMsg (MessageId: D,
> RelatesTo: A)
> >
> >
> > Here are the questions:
> > 1) Do you see any flaw in this scenario? Or is there a common
> and
> > standards based way to accomplish this kind of asynchronous
> > communication?
> >
> > 2) I haven't found a good way to say my clients which service
> do they
> > need to call for getting the results. I'm planning to put the
> name of
> > result service name (GetOpenAccountResultMsg) in notification
> message
> > (ResultIsReadyMsg).
> >
> > Could you please enlighten me? Any help would be great!
> >
> > Ali Sadik Kumlali
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> >
> >
> >
>
------------------------------------------------------------------------
> >
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.1.385 / Virus Database: 268.5.0/325 - Release Date:
> 26/04/2006
>
> --
> -------------------------------------------------------------------
> GRIDSYSTEMS Rodrigo Ruiz Aguayo
> Parc Bit - Son Espanyol
> 07120 Palma de Mallorca mailto:[EMAIL PROTECTED]
> Baleares - Espa�a Tel:+34-971435085 Fax:+34-971435082
> http://www.gridsystems.com
> -------------------------------------------------------------------
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.5.0/325 - Release Date:
> 26/04/2006
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
