- From: David Snelling <david.snelling@uk.fujitsu.com>
- Date: Mon, 20 Dec 2010 15:46:47 +0000
- To: Gilbert Pilz <gilbert.pilz@oracle.com>
- CC: Doug Davis <dug@us.ibm.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <9B335D3F-2BEA-453C-A30A-E04838868931@uk.fujitsu.com>
Gil,
[Again, I'm not sure I like this suggestion, it is just an option.]
On 20 Dec 2010, at 15:05, Gilbert Pilz wrote:
> I'm not sure I understand your last paragraph. Are you suggesting that we require Event Sinks to support both wrapped and unwrapped and allow the Source to dynamically pick which one it wants to use at runtime?
Yes, you do understand the proposal.
> If this is your implicit proposal, I have to say that I don't see the point. All of the arguments for using either wrapped or unwrapped deal with the way the Sink receives and processes Notifications and how you go about building the code that performs these functions base on your understanding (or lack thereof) of the structure of the Notifications.
From my perspective, this is not hard to deal with. If the notification message's outermost element is <wse:NotifyEvent/>, the message is wrapped, otherwise it's not. The SOAP envelope handles the intermediaries and the final recipient can handle the above simple choice easily.
>
> ~ gp
>
> On 12/20/2010 12:56 AM, David Snelling wrote:
>>
>> Doug,
>>
>> I agree. Even where lightweight devices are managed externally, the few bytes to add a wrapper in the name of actual interoperability seems worth it.
>>
>> One other alternative, which I don't know if I like or not. We could require the event sink to always understand both. They are trivial to tell apart (wse:NotifyEvent is NS qualified) and the sinks tend to be smarter anyway. Also, we could then make the sources even simpler.
>>
>> On 18 Dec 2010, at 15:34, Doug Davis wrote:
>>
>>>
>>> While I don't think it would be accurate to claim that support for both (option 4) is cost-free, given everything else that an event source/subMgr needs to do I have my doubts that supporting wrapped will push an implementation over the edge. When we consider the cost of managing subscriptions, possibly filtering, timeouts, etc.... these seem much heavier than supporting wrapped. To me it comes down to a boolean (wrapped vs unwrapped) per subscription and then a few lines to code to add an extra wrapper to the Body. Of course people's mileage may vary, but if it requires a whole lot more than that I think the implementation may have more serious things to worry about. :-)
>>>
>>> thanks
>>> -Doug
>>> ______________________________________________________
>>> STSM | Standards Architect | IBM Software Group
>>> (919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
>>> The more I'm around some people, the more I like my dog.
>>>
>>>
>>> Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
>>> 12/17/2010 07:10 PM
>>>
>>> To
>>> Gilbert Pilz <gilbert.pilz@oracle.com>, "Chou, Wu (Wu)" <wuchou@avaya.com>
>>> cc
>>> Bob Freund <bob.freund@hitachisoftware.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, "public-ws-resource-access-request@w3.org" <public-ws-resource-access-request@w3.org>, Doug Davis/Raleigh/IBM@IBMUS, "tom@coastin.com" <tom@coastin.com>
>>> Subject
>>> RE: Options on "Wrap" and "Unwrap" formats for WS-Eventing
>>>
>>>
>>>
>>>
>>>
>>>
>>> My preference is option (2) below.
>>>
>>> On option (4) – requiring support for both formats is a problem for resource-constrained low-powered devices. In constrained environments, implementations are usually up against the wall in terms of what they can build into resource-constrained devices. Supporting features those devices would never use is an unnecessary burden. Usually such implementations carefully avoid all unnecessary features so as to save precious battery life and to improve efficiency. For WS-Eventing to be useful in such environments, it is important to keep the specification generic enough so those specialized environments can use and specialize the specification for their own needs; otherwise, such implementations may be forced to invent their own eventing solutions. Hence, it is important to require only those features in the specification that are absolutely essential and leave room for variability/optionality.
>>>
>>> From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
>>> Sent: Friday, December 17, 2010 12:13 PM
>>> To: Chou, Wu (Wu)
>>> Cc: Bob Freund; public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org; Doug Davis; Ram Jeyaraman; tom@coastin.com
>>> Subject: Re: Options on "Wrap" and "Unwrap" formats for WS-Eventing
>>>
>>> Wu,
>>>
>>> Overall it seems that there are 4 ways we can address this issue:
>>>
>>> 1.) Allow Event Sources to optionally support either wrapped, unwrapped, or neither (state of the current draft).
>>>
>>> 2.) Require Event Sources to support unwrapped; allow optional support of wrapped.
>>>
>>> 3.) Require Event Sources to support wrapped; allow optional support of unwrapped.
>>>
>>> 4.) Require Event Sources to support both wrapped and unwrapped.
>>>
>>> Oracle cannot accept (1) due to the interoperability issues with mis-matched delivery formats. Oracle also cannot accept (3) because of the issues we have with wrapped notifications [1]. Oracle would prefer option (2), but we could live with option (4).
>>>
>>> [1] http://blogs.oracle.com/wsinterop/2009/02/the_problem_with_wrapped_notif.html
>>>
>>> ~ gp
>>>
>>> On 12/16/2010 1:25 PM, Chou, Wu (Wu) wrote:
>>> Bob,
>>>
>>> Here is our study on Wrap and Unwrap delivery format options for WS-Eventing.
>>>
>>> It is enclosed here for information sharing as some food of thought, because this can be a major decision and deserves a deeper study.
>>>
>>> Many thanks,
>>>
>>> - Wu Chou.
>>>
>>> Avaya Labs Research
>>>
>>> ------------------
>>> Background - WS-Eventing specifies two delivery formats - wrap and unwrap. Both have critical use cases and widely used.
>>> Question - Should “wrap” event delivery format be optional or should both “wrap” and “unwrap” formats be required features for an event source implementation.
>>> Observation - After some study, we think - both wrap and unwrap delivery formats should be required features for WS-Eventing implementation (Doug’s proposal) - is a better one for the following reasons.
>>> 1. Maximizing the interoperability of WS-E implementation
>>> When both wrap and unwrap delivery formats are required for an event source implementation, it eliminates the interoperability issue caused by having “wrap” delivery format as an option. This interoperability issue is acute, as a client with a “wrap” event sink cannot receive events from a source that does not support “wrap” event delivery.
>>>
>>> 2. Maximizing the benefits of WS-E client (event subscribers)
>>> One event source can have thousands of event subscribers (clients) from various environments that subscribe to it. When both “wrap” and “unwrap” formats are required, a client can have its own choice on which format is best for its needs and application.
>>>
>>> If “wrap” format is optional, then the event source may terminate at will the support of “wrap” event delivery for new event subscription request. As a consequence, every client has to prepare a separate “unwrap” event sink as a backup at all times, in case that during the next subscription to the same event source, the “wrap” option is terminated. This is going to be a huge problem and cause many applications to break – making the WS-E client based on “wrap” event delivery not workable.
>>>
>>> 3. Maximizing the application scope of WS-E
>>> This “wrap” delivery format specified in WS-E provides a standard generic event sink to receive events from various sources. This decoupling – provided in “wrap” format delivery - allows a client to develop its event sink in a distributed fashion, and use one event sink for all events, including some new event sources that may be yet to occur, e.g. event sink that acts as a proxy for all interested events from all sources – a typical case for both resource constrained devices or event sink gateway.
>>>
>>> 4. Negligible implementation cost
>>> The implementation overhead from supporting “unwrap” to supporting both “wrap”, and “unwrap” delivery format is negligible (e.g. in the interceptor chain architecture), as the only thing involved is to add a standard element wrapper on the notification message.
>>>
>>> Summary
>>> “wrap” event delivery format is better to be a required feature for an event source implementation due to the following reasons:
>>> 1. Maximizing the interoperability
>>> 2. Maximizing the benefits of WS-E client implementation
>>> 3. Maximizing the application scope of WS-E
>>> 4. Negligible implementation cost.
>>>
>>> Without “wrap” event delivery as a required feature, the “wrap” delivery format is broken – redundant, unreliable, not interoperable, tightly coupled programming model, unfit for event proxy applications, resource waste for WS-E client implementation for using wrapped delivery, etc.
>>> -------------------------------------------------
>>>
>>> ______________________________________________________________________
>>> This email has been scanned by the MessageLabs Email Security System.
>>> For more information please visit http://www.messagelabs.com/email
>>> ______________________________________________________________________
>>
>> Take care:
>>
>> Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
>> Fujitsu Laboratories of Europe Limited
>> Hayes Park Central
>> Hayes End Road
>> Hayes, Middlesex UB4 8FE
>> Reg. No. 4153469
>>
>> +44-7590-293439 (Mobile)
>>
>>
>> ______________________________________________________________________
>>
>> Fujitsu Laboratories of Europe Limited
>> Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
>> Registered No. 4153469
>>
>> This e-mail and any attachments are for the sole use of addressee(s) and
>> may contain information which is privileged and confidential. Unauthorised
>> use or copying for disclosure is strictly prohibited. The fact that this
>> e-mail has been scanned by Trendmicro Interscan does not guarantee that
>> it has not been intercepted or amended nor that it is virus-free.
Take care:
Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
Fujitsu Laboratories of Europe Limited
Hayes Park Central
Hayes End Road
Hayes, Middlesex UB4 8FE
Reg. No. 4153469
+44-7590-293439 (Mobile)
______________________________________________________________________
Fujitsu Laboratories of Europe Limited
Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
Registered No. 4153469
This e-mail and any attachments are for the sole use of addressee(s) and
may contain information which is privileged and confidential. Unauthorised
use or copying for disclosure is strictly prohibited. The fact that this
e-mail has been scanned by Trendmicro Interscan does not guarantee that
it has not been intercepted or amended nor that it is virus-free.
Received on Monday, 20 December 2010 15:47:10 UTC