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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

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


Subject: Re: [wsdm] Guaranteed Delivery and one-way (was MEP Edits from todaysConference Call)


Dan,

Thanks for the clarification.

I guess I was also unclear on what was meant by guaranteed delivery, as 
well as "asynch".

1. When we say "asynch" are we really intending SOAP one-way messages? 
(Because the HTTP underneath is still request-response, and of course it 
is running on TCP underneath that, not UDP.)

2.  As Dan already asked, does the lack of an HTTP 200 or 202 response 
require the notification sender to retry?  (once-only v. at-least-once)

The quote below has R2715 that requires at-least-once.  But as we have 
already agreed, we are not going to slavishly adhere to items in here. 
OTOH, if this seems sensible to us, we might as well use the same approach.

Thanks.

The WS-I Basic Profile does mention:
"5.6.11 One-Way Operations

There are differing interpretations of how HTTP is to be used when 
performing one-way operations.

    R2714 For one-way operations, an INSTANCE MUST NOT return a HTTP
    response that contains a SOAP envelope. Specifically, the HTTP
    response entity-body must be empty.

    R2750 A CONSUMER MUST ignore a SOAP response carried in a response
    from a one-way operation.

    R2715 An CONSUMER MUST NOT consider transmission of one-way
    operations complete until a HTTP response status code of either
    "200 OK" or "202 Accepted" is received by the HTTP client.

    R2727 For one-way operations, an CONSUMER MUST NOT interpret the HTTP
    response status code of "200 OK" or "202 Accepted" to mean the
    message is valid or that the receiver would process it.

One-way operations do not produce SOAP responses. Therefore, the Profile 
prohibits sending a SOAP envelope in response to a one-way operation. 
This means that transmission of one-way operations can not result in 
processing level responses or errors. For example, an "500 Internal 
Server Error" HTTP response that includes a SOAP message containing a 
SOAP Fault element can not be returned.

The HTTP response to a one-way operation indicates the success or 
failure of the transmission of the message. Based on the semantics of 
the different response status codes supported by the HTTP protocol, the 
Profile specifies that "200" and "202" are the only response status 
codes that the sender should interpret as signifying that the message 
was successfully delivered. A successful transmission is no way an 
indicator that the SOAP processing layer and the application logic has 
had a chance to validate the message or are committing to processing it.

Despite the fact that the HTTP 1.1 assigns different meanings to 
response status codes "200" and "202", in the context of the Profile 
they should be considered equivalent by the initiator of the request. 
The Profile accepts both status codes because some SOAP implementations 
have little control over the HTTP protocol implementation and cannot 
control which of these response status codes is sent.
"

Dan Foody wrote:

> When using http with SOAP one-way messages, the HTTP 200 OK response
> serves as an a "I received it" notification.  If the sender gets HTTP
> 200 OK, the sender can assume that the message was correctly received.
> Otherwise (if a different outcome than 200 OK), the sender needs to
> resend it (unless it's a persistent failure).  This behavior gives you a
> guarantee of at-least-once delivery.
> 
> My question about [FR003.3] (Must support guaranteed notifications) is
> whether the intent is guarantee of once-only delivery or at-least once
> delivery?
> 
> To support once-only delivery semantics, we would need to require
> something like WS-ReliableMessaging (rather than trying to layer our own
> once-only semantics on top of standard at-least-once delivery).
> 
> Cheers.
> 
> --
> Daniel M. Foody
> CTO, Actional Corporation
> 701 N. Shoreline Blvd. 
> Mountain View, CA  94043 
> 
> http://www.actional.com
> 
> 
> 
>>-----Original Message-----
>>From: John DeCarlo [mailto:jdecarlo@mitre.org] 
>>Sent: Wednesday, June 04, 2003 12:39 PM
>>To: Heather Kreger
>>Cc: wsdm@lists.oasis-open.org
>>Subject: Re: [wsdm] MEP Edits from todays Conference Call
>>
>>
>>Hello,
>>
>>I also have another quibble that I didn't want to get into on 
>>the call. 
>>  I don't know if anyone else considers this important or not.
>>
>>By at least one definition, a notification is an unsolicited message 
>>(typically from managed resource to manager).
>>
>>While we often assume notifications are asynchronous (such as an SNMP 
>>Trap), it isn't necessarily so.  Other related discussions talk about 
>>using request-response approach, but simply having an "I received it" 
>>response automatically sent.  This would work for 
>>notifications as well.
>>
>>In fact, one could argue that if you want FR003.3, guaranteed 
>>delivery 
>>of notifications, that having an "I received it" response from the 
>>receiver would be beneficial.
>>
>>In summary, I present the case that we need not link 
>>Notifications being 
>>  originated from the managed resource with asynchronous messaging.
>>
>>Thanks.
>>
>>Heather Kreger wrote:
>>
>>
>>>[FR003]  MUST support delivery of notifications from manageable 
>>>resources to manager. (Source: IBM, HP, MPTC)
>>>
>>>
>>>
>>>
>>>      [FR003.1] The notification receiver SHOULD be able to control 
>>>what notifications are sent to it. (filtering and/or 
>>
>>subscription at 
>>
>>>managed resource side) (Source: HP)
>>>      [FR003.2] The notification receiver SHOULD be able to 
>>
>>indicate 
>>
>>>whether it wants to receive notifications asynchronously as 
>>
>>and when 
>>
>>>they happen or poll them periodically. (Source: HP) {#90}
>>>            [FR003.2C] SHOULD support asynchronous delivery of 
>>>notifications
>>>            [FR003.2.D] MUST support synchronous polling 
>>
>>for notifications
>>
>>>            [FR003.2.E] The managed resource MUST be able 
>>
>>to indicate 
>>
>>>if it supports asynch or polling notifications mechanisms.
>>>      [FR003.3] Must support guaranteed notifications. {#90} (and 
>>>advertise its support)
>>>      [FR003.4] Must support ordering of notifications from 
>>
>>a managed 
>>
>>>resource's perspective. {#90}
>>>      [FR003.4] Support synchronous as well as asynchronous. {#142}
>>><Delete: Dup of 3.2>
>>
>>-- 
>>
>>John DeCarlo, The MITRE Corporation, My Views Are My Own
>>email:      jdecarlo@mitre.org
>>voice:      703-883-7116
>>fax:        703-883-3383
>>DISA cube:  703-882-0593
>>
>>
>>
>>You may leave a Technical Committee at any time by visiting 
> 
> http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgrou
> p.php
> 
> 

-- 

John DeCarlo, The MITRE Corporation, My Views Are My Own
email:      jdecarlo@mitre.org
voice:      703-883-7116
fax:        703-883-3383
DISA cube:  703-882-0593




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