Hi Ali, see my comments in-line :-)
Ali Sadik Kumlali wrote:
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?
Yes, that is the type I was referring to :-)
The type definition is included in the WS-Addressing XSD schema. You
just have to import it into your WSDL descriptors and use it as any
other type. For example:
<xsd:complexType name="ResultIsReadyRequestType">
<xsd:sequence>
<!-- Your fields here -->
<xsd:element name="GetResultsService"
type="wsa:EndpointReferenceType"/>
</xsd:sequence>
</xsd:complexType>
In your server, you can use some kind of session id (perhaps the
original message identifier, perhaps any other generated value) to
identify the operation, and include this id as a ReferenceProperty of
the returned EPR. This way, the EPR will have all the necessary data to
identify the operation results to return.
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?
You can put the EPR within the headers or within the body.
If you put it in the header, you may use ReplyTo and FaultTo to specify
the addresses of the services to be notified on success and error, or
ReferenceParameters if you feel the previous ones do not fit your
semantics, but AFAIK you will have no way to enforce this in your WSDL.
If I am right, these fields(ReplyTo and FaultTo) were intended to be
used for redirecting the response of synchronous services.
The other option is to put it within the request body, as an element of
the request message (see my previous comment). This option does allows
you to enforce the syntax, as you make it explicit.
- 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.
I see your point :-)
Anyway, I would not reject this option too fast. My personal opinion has
always been that there is no one-and-only correct way of doing things.
Just scan what I write, and then do whatever you want to ;-)
- You could put all your result types in a single XSD schema, and import
it in both WSDLs. From the point of view of maintainability, your client
wsdd will be almost as simple as before. You just have to add a single
extra element to the notification messages.
- Your client already has the logic for processing the results. When
receiving the notification, you could call the same method/function in
your client.
- Reducing the number of messages, you also reduce:
- the possibilities of a remote exception :-)
- the latency for obtaining the results.
- the workload in the server
Cheers,
Rodrigo Ruiz
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
--
-------------------------------------------------------------------
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.1/326 - Release Date: 27/04/2006
