This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 9609 - Enum: Support WS-Management's optimization of Enumerations with small result sets
Summary: Enum: Support WS-Management's optimization of Enumerations with small result ...
Status: CLOSED REMIND
Alias: None
Product: WS-Resource Access
Classification: Unclassified
Component: Enumeration (show other bugs)
Version: LC
Hardware: All All
: P2 enhancement
Target Milestone: ---
Assignee: Gilbert Pilz
QA Contact: notifications mailing list for WS Resource Access
URL:
Whiteboard:
Keywords: externalComments
Depends on:
Blocks:
 
Reported: 2010-04-28 21:56 UTC by Gilbert Pilz
Modified: 2010-07-28 09:11 UTC (History)
1 user (show)

See Also:


Attachments
expanded description of the use case and motivation behind the optimized Enumerate feature (59.00 KB, application/msword)
2010-06-01 20:18 UTC, Gilbert Pilz
Details
Proposal by Rich Landau (61.00 KB, application/msword)
2010-06-15 17:53 UTC, Robert Freund
Details

Description Gilbert Pilz 2010-04-28 21:56:36 UTC
WS-Management v1.1 [1] Section 8.2.3 defines an extension to WS-Enumeration wherein the initial Enumerate/EnumerateResponse exchange functions as an implicit Pull/PullResponse exchange. This behavior is useful in cases where the enumeration has such a small number of items that the initial EnumerateResponse could reasonably include the entire result, without the need for a subsequent Pull to retrieve the items.

It is the opinion of the WS-Man WG that this feature is sufficiently general as to warrant inclusion in the base specification. The WS-Man WG requests that WS-RA WG incorporate this extension as an optional feature of WS-Enumeration.

[1] http://www.dmtf.org/standards/published_documents/DSP0226_1.1.pdf

---

Proposal:

1. Add an optional element to the Enumerate request equivalent to wsman:OptimizeEnumeration.

2. Add optional wsen:MaxTime, wsen:MaxElements, and wsen:MaxCharacters elements to the wsen:Enumerate element. These elements must not appear unless the OptimizeEnumeration element is also present. It may make sense to make these elements children of the OptimizeEnumeration element to align the schema and semantic optionalities.

3. Add optional wsen:Items and wsen:EndOfSequence elements to the wsen:EnumerateResponse element. These elements must not appear unless the consumer included OptimizeEnumeration in the corresponding Enumerate request.

4. Add wsen:TimedOut to the list of faults that may be generated by the Enumerate request.

5. Add a parameter to the wsenu:DataSource assertion to indicate that an endpoint supports the Optimized enumeration feature.

6. Define an additional fault to cover the case where a consumer requests the optimized enumeration from a data source that does not support this feature.

7. Define a mechanism to allow a client to specify whether the request should be performed with or without the use of this feature in a way similar to the way mustUnderstand works.
Comment 1 Gilbert Pilz 2010-05-12 04:53:40 UTC
The WS-RA WG considered this request during the face to face meeting of May 11th, 2010. The following points were raised:

1.) The described use case (small number of items) is directly contrary to the use case that motivates WS-Enumeration ("transferring large data sets over SOAP"). If it is known that the representation of a resource will fit into a single SOAP message, that resource should be modeled using WS-Transfer.

2.) Folding the Pull operation into the Enumerate operation (as WS-Man v1.1 does) dramatically increases the complexity of both the specification and implementations.

3.) Removing the Enumerate operation and folding its semantics into the Pull operation (as the WG also considered) adds less complexity than (2) but creates potentially undesireable side effects such as removing the ability to create an enumeration in a way that doesn't pull any data items.

The WS-RA WG decided that the benefits of supporting the optimization (one less round trip) were outweighed by cost of increased complexity.
Comment 2 Gilbert Pilz 2010-06-01 20:18:30 UTC
Created attachment 886 [details]
expanded description of the use case and motivation behind the optimized Enumerate feature
Comment 3 Robert Freund 2010-06-15 17:53:38 UTC
Created attachment 887 [details]
Proposal by Rich Landau
Comment 4 Robert Freund 2010-06-15 17:54:19 UTC
Reopened by agreement 2010-06-01
Comment 6 Doug Davis 2010-06-29 20:25:30 UTC
add fault for too many items on first pull, add policy to indicate max items on first pull
Comment 7 Doug Davis 2010-06-29 20:28:02 UTC
make it a boolean instead of a max #