Issue 168 (Which Operation?) / Requirement R114

This message contains a fairly detailed analysis of issue 168 / requirement 
R114.

NARROWLY ADDRESSING ISSUE 168
Regarding issue 168 ("Which operation?"): 
http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/wsd-issues.html#x168
I think the narrow issue raised by Mark Baker can be addressed by adding 
some clarification to our spec, to be clear whether/how the operation name 
is determinable without application-specific knowledge.

THE ICEBERG BENEATH THE SURFACE
However, lurking under the surface is a much larger dilemma: Every proposal 
thus far to satisfy requirement R114 has been rejected by the WG, but we 
still have the requirement.  Requirement R114, 
http://www.w3.org/TR/ws-desc-reqs/ , states:
[[
R114
     The description language MUST allow unambiguously mapping any 
on-the-wire Message to an Operation. (From WG discussion. Last revised 4 
Apr 2002.)
]]

We've had two proposals that would have met this requirement.  The first 
proposal
( http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0112.html )
was to require global element names to be unique (this was the "uniqueness 
on the wire" discussion), so that the operation name could be inferred from 
the global element names.  The proposal was rejected by the WG:
http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0059.html
[[
Strawpoll 1. adopting the GED proposal from Umit/Roberto
              for: 5, oppose 11
]]

However, at the same time the WG also re-affirmed the need for the 
requirement:
[[
JeffM:     How many think the requirement should be addressed some way?
strawpoll 2. each wsdl must have a required feature associated with 
dispatching
              for 3, against 13
strawpoll 3. enable people to indicate so in normative way
              for 13, against 3
]]
And the WG gave Umit and Glen an action for a new proposal:
[[
ACTION:   Umit (with help of Glen) will write up a proposal for normative
           dispatching feature.
]]

The second proposal used Features and Properties to provide a normative way 
to indicate how the operation name could be determined:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0082.html
After much discussion in the WG, this proposal was also rejected in a 
formal vote (6 against, 4 in favor):
http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0039.html

VIEWPOINTS TOWARD REQUIREMENT R114
Polarizing viewpoints on requirement R114 seem to range from:

>"We don't need R114.  It's the application's problem to dispatch how it 
>sees fit -- perhaps using an operation name, perhaps using something 
>else.  If someone writes an ambiguous WSD and they don't know how to 
>dispatch with it, it's their problem.  We shouldn't try to prevent them 
>from shooting themselves in the foot."

to:

>"R114 is important.  Without it we won't have interoperability."

Why has this been such a difficult issue?

THE ROOT OF THIS DILEMMA
Part of the difficulty is that industry makes a fairly clear distinction 
between WSDL toolkits and WS applications, but the WSDL specification does 
not make such a clear distinction between them.  (The WSDL specification 
has only limited mention of a conformant WSDL processor.)  There has been a 
strong implicit assumption that WSDL documents are targeted at WSDL 
toolkits, which should be able to do a number of things based only on a 
given WSDL document, without knowledge of the particular application 
semantics.  Conversely, there's been a strong leaning toward having the 
application-specific portions of a requester or provider agent should ONLY 
have to deal with tasks that are application specific, i.e., the 
application code should NOT have to deal with things like transport 
encodings, protocols, etc.  (I realize that last statement is technically a 
tautology, but hopefully you get the drift.)

These assumptions are rooted in the desire for a clean separation of 
concerns (or layering) between the application semantics and the mechanics 
of how the application interacts with others.  Indeed, these assumptions 
are at the basis for the existence of WSDL itself: One of the main 
motivations for WSDL to exist is to ease the task of creating interoperable 
requester and provider agents, i.e., to permit generic tools to generate 
the portions of the agent code that handle the mechanics of the interaction 
-- the protocols, the transport encodings, etc.

I think this distinction between toolkit concerns and application concerns 
is at the heart of our difficulty in coming to agreement on a solution for 
requirement R114, because the implicit motivation behind R114 seems to be a 
desire to enable a WSDL toolkit -- not application-specific code -- to 
perform dispatching based on the operation name.

The potential problem can be illustrated with a hypothetical scenario.

SCENARIO X
A provider entity wishes to make a Web service available.  It uses toolkit 
T1 from vendor V1 to create and test both a provider agent PA and a WSD W 
that describes its interfaces, protocols, location, etc.  Toolkit T1 hides 
the details and grunt work of creating both the WSD W and much of the 
provider agent PA.  Toolkit T1 assumes that the operation name will be 
transmitted using a particular convention C, although this fact is not 
formally expressed in the WSDL document, i.e., WSD w contains neither a 
required Feature nor a required XML extension to formally signal the use of 
convention C to a WSDL processor.  (Indeed, although convention C is not 
required by the WSDL specification, vendor V1 believes that their toolkit 
T1 offers greater value over competing toolkits, because it removes the 
burden that the provider entity would otherwise have to implement their own 
dispatch mechanism in application code.)  The provider entity completes the 
application-specific portions of provider agent PA, and carefully notes all 
application semantics of the application code that has been added.  The 
application semantics are documented in a human-readable document S that is 
also made available to potential requester entities, along with WSD W.  The 
semantics document S also does not mention the fact that provider agent PA 
expects the operation name to be transmitted using convention C, because 
the provider entity is unaware of this fact: the provider entity did not 
add *any* application code to implement convention C.  Provider agent PA 
goes live and awaits interaction from requester agents.

Requester entity RE1 then builds a requester agent RA1 using WSD W and 
semantics document S that were supplied by the provider entity for this 
purpose.  RA1 happens to use the same toolkit T1 as was used by provider 
agent PA, so RA1 uses convention C to send the operation name to provider 
agent PA in each request.  RA1 is deployed and interacts flawlessly with PA.

Another requester entity RE2 then builds a requester agent RA2, also using 
WSD W and semantics document S.  However, RA2 happens to use a different 
toolkit T2 from vendor V2, which does NOT use convention C to send the 
operation name to provider agent PA in each request.  RA2 is deployed, but 
doesn't work when it tries to interact with PA.  After many hours spent 
checking the implementation of RA2 against WSD W and semantics document S 
and finding nothing amiss, RE2 calls the provider entity to complain that 
PA is not working according to WSD W and semantics document S.  The 
provider entity assures RE2 that provider agent PA *is* working fine and 
that nobody else's requester agent has reported any problem with it.  The 
provider entity tells RE2: "Your toolkit must be broken.  Everyone else is 
using toolkit T1.  Try that one."

SCENARIO X: WHO IS TO BLAME?
RE2 thinks the problem is the provider entity's fault, because RA2 conforms 
to everthing that is specified in WSD W and semantics document S.  The 
provider entity thinks the problem is RE2's fault, because PA works fine 
for other requester agents that were created using toolkit T1.  Vendor V2 
says the problem is vendor V1's fault, because the generated WSD W does not 
mention convention C as a required extension.  Vendor V1 says that 
convention C is outside the scope of WSDL -- that it falls in the scope of 
the application semantics, which are beyond WSDL.  But the provider entity 
did not mention convention C in the semantics document S because it didn't 
add *any* application-specific code for convention C, and thus it didn't 
know anything about convention C.

OPTIONS FOR MOVING FORWARD
I believe the scenario above illustrates the heart of this dilemma.  Would 
this scenario represent an acceptable reality?  Or should this WG try to 
prevent it?  If so, how?

We are now approaching Last Call, which is the time when we announce to the 
world that we believe we have met all of our requirements.  We cannot 
afford to delay LC, but we obviously have not yet met requirement 
R114.  What should we do?  I see a few options.

Option 1a: Rescind requirement R114.

Option 1b: Acknowledge in our LC draft that R114 has not been met, without 
formally rescinding it.  At this point I don't know if there is much 
difference between this option and option 1a.  Either one is likely to 
result in minority opinions being filed.

Option 2: Come up with a new proposal and adopt it.  (But we are running 
out of time to do so.)

Option 3: Reconsider an existing proposal.



-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273

Received on Wednesday, 30 June 2004 14:18:49 UTC