Hi Rodrigo, Thank you very much for your valuable help. It really saves my time and life ;-)
Please see my inline comments. (Since there are too much line, I had to cut older postings.) --- Rodrigo Ruiz <[EMAIL PROTECTED]> wrote: > 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> Thank you very much. I'll try it ASAP. > 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. Putting it in request body... Good idea :) I'm going to reconsider it. > >> - 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 Actually, since I'm not an expert on these issues, I don't feel myself in the position of rejecting anything :) All the ways and thoughts are kindly welcomed :) The way you suggest is our current solution :) But I feel we do something inelegantly by providing the same message for all the results and requiring the clients to dispatch it. In this way, I see no direct relation between the request and the response message in WSDL. May be I'm missing something ;-) Again, thank you very much for taking your time and sharing your thoughts. Best regards, Ali Sadik Kumlali __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
