OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsrm] WSDL for WSRM ??


> For Szabolcs:
> >
> >   1) define WSRM functionalities TRANSPARENT to existing SOAP MEP
> >      ------------------------------------------------------------
> > ...
> How would the WS-RM WSDL look like in this case? 

I think, the WSDL may stay as it was in the non-reliable WSDL definition. Maybe should be extended by something (see below).

> We would 
> just define the structure of the header without specifying any 
> supported MEP?

Yes. SOAP-layer MEPs are there. Either the standard One-way and Request-Response, or even more complex ones.
 If we also define realible-MEPs, those differ from SOAP MEPs then we have to double all MEP-related solutions. (There will be the non-relibale MEPs and the reliable MEPs)

 So I would say: it may be possible to NOT talk about realiable-MEPs. In this case WSRM doesn't have to "support" MEPs, because it is independent from it, "transparent". I will show below, how.

> [...]
> offering the service. Consider the case of a one-way 
> operation, which could be
> mapped to a synch. req-response (message on the req, ack on 
> the response): in
> this case the service exposed is actually a req-response and not a 
> one-way.

I donn't asume we should change the semantics of the WSDL 1.1. If WSDL says that one operation is one-way, then it must be a one-way message, consisting on one SOAP message. The acknowledgement must be sent, of course, but who said that the Acknowledgement would have to be sent in the frame of the same operation? (in WSDL sense)? The only thingk we have to guaranteee that the Ack must be transferred. Doesn't matter, where, as the Acknowledgement itself contains the correlation information that connects it with the original message. 

> If I do not
> misunderstand what you mean with this first possibility, in 
> this case the original WSDL (describing the one-way operation at 
> the application level) should be used and
> the WS-RM processor would be free to implement any different MEP.

I would rather assume that the WSRM processor is free to choose where to include the WSRM header in the SOAP messages targeted at the other node. But the operations as described in WSDL should be kept as they are.

I might have been too short. I'm afraid of writing too long emails, but if you have some free time to follow my thinking, I would present my model of realible SOAP messaging (would be much easier with figures, but anyway...)

What we do here is that we mix the application message exchanges (that is the function of the SOAP Body, basically) with the message exchange of the reliability solution. How we implement reliability here? With Acknowledgement. What does it mean? It can be modeled as a request-response "acknowledging" service offered by the recipient, that has the functionality:
  - the AckRequest says: "The SOAP message I'm travelling with, it labelled with this MessageID. Please confirm when reception of the SOAP message I'm conveyed within"
  - the Acknowledgement says: "I've received the SOAP message lablled with this MessageID"

As an example, let's consider an application semantics of a service that can query user status with a request-response operation (StatusRequest, StatusResponse), and can send notifications about the current status of the user with a one-way operation (Notification).

 Let's see the first application funcion (query). BY receiving a StatusRequest with a WSRM header, the server has to serve two "operations":
  - must send back a StatusResponse to the StatusRequest
  - must send bakc and Acknowledgement to the AckRequested in the WSRM header.

 In this case the two abstract MEPs are conincide: both the status query and the acknowledgement mechanism use the same request-response type of message exchange.

 Let's see the one-way Notification example. By receiving a Notification message with a WSRM header, the server has two operations to fulfill:
  - must consume a Notifiaction message, and send back nothing.
  - must send back an Acknowledgement to the Ackrequeste in the WSRM header.

 So here is the problem: the message exchange of the application logic is one-way, the message exchange of the abstract "acknowledging" mechanism is request-reponse. 

Conclusion: The acknowledging mechanism can be modeled as a request-response type. The application mechaism can have whatever message exchange you can imagine. We have to select how to mix the Ack function with the appication function. The problem: thay may not be the same, and not mix easily.

 What I meant with opetion 1) was that the SOAP message exchange should follow the message exchange as defined by the application. And the Acknowledg-ing solution should align with the message exchange realized by the application, in the following way:

 - The AckRequests should be sent along with the message to be Ack-ed.
 - The Acknowledgements shuold be "piggybacked" on other SOAP messages. It need not to be specified where the Acknowledgement headers are sent. Wherever the WSRM processor find it appropriate. Maybe included in another SOAP message, of another operation. Maybe sent as multiple acknowledgements after waiting some Acks to be gathered. Up to implementation optimizations.

 Of course, ther may be "pending" Acknoledgements those could not be sent, because could not be "piggybacked". 
So there could be WSRM-defined operations, purely for sending and recieving Acknowledgements, with empty Body. 
 - SendAck operation to send an acknowledgement if there is a "pending" one.
And because there are some requirements for firewall support etc..:
 - PollAck may be needed for requesting acknowledgement if we assume that there is a pending Acknowledgement on the other end.

So the server who offers can define its Notification operation abouve in the WSDL in different ways:

version 1) 
  - define a one-way Notification operation.
  - bcasue Acks must be sent somehow, 
      - it sends Acks of Notification along with other SOAP messages to the client (e.g. along with StatusResponse)
      - if it is not possible (no traffic to the client), it check if client can receive SendAck operation, as a One-way operation with empty Body. This contains the Ack. 
      - if client if not able to receive one-way SendAck messages, then waits for PollAck.

version 2)
  - define a request-response Notification operation. 
  - The <input> of the Notification operation is the same as the one-way Notificatio above.
      - The <output> of the Notification operation is with empty Body, and contains the Ack.
      - or the <output> it doesn't contain the Ack, because the server found the processing too long, and rather postponed sending the Ack. The Ack will be sent later somehow else, like in the version 1) above. (SendAck or PollAck).
In this case all the control is in the hand of the server, 
 - by defining the WSDL however it wants (can preserve "one-wayness" if wants, but can map to request-response if wishes so)
 - by deciding where and when to send back Acknowledgements. Note that availability of Acknowledgement can depend of the semantics of the Ack in the actual scenario (between a given clinet as server it might mean "I've processed the message, or I've stored the message in a nuclear-safe supersafe mechanism", and that can last long)

> An other point is that if we do not describe the MEPs 
> supported by the ws-rm
> processors in the WSDL, where
> are the parties going to collect these informations?

See above. In this case there is no such term as "WSRM-supported MEP". 
> >   2) we define Reliable-MEPs OVER the existing SOAP MEPs
> >      ---------------------------------------------------
> In this moment, the option I like most is the second: ws-rm 
> should offer to the
> application layer (1) reliable one-way and (2) req-response 
> MEPs. These might be
> supported at ws-rm layer by using several standard SOAP MEPs. 
> All of these MEPs
> should be described through WSDL 1.1, to allow 
> interoperability. In our spec we
> would have to define the possible translations of reliable 
> MEPs to "unreliable"
> standard SOAP
> MEPs.
> What about this solution?

That's another possibility, that's what I called option 2). We should consider, what advantages an disadvantages this mapping between "WSRM-MEP" and "SOAP-EP" has.

	Best regards

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]