sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-bindings] Issue 124 proposal version 2 - a comment
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Bindings" <sca-bindings@lists.oasis-open.org>
- Date: Tue, 6 Apr 2010 15:10:59 +0100
Folks,
The gap may be small, but it is an important
gap.
I think that the binding.ws specification
must add a single normative statement indicating that support
of WS-Policy is *required* - and that
this support takes 2 forms:
a) accepting WS-Policy statements in
WSDLs
b) accepting WS-Policy statements in
PolicySets
Note that I do NOT mean that a binding.ws
implementation must accept any particular concrete policy assertion,
just that it cannot reject policy assertions
on the basis that they use the WS-Policy language. It can reject
them
on the basis that the particular policy
assertion is not supported. If binding.ws ever requires support of
specific
policy assertions, then such requirements
would be added as separate normative statements (there is one
of these associated with the callback
protocol, although it is not mandatory to support this).
Next question:
Should we add this requirement for WS-Policy
to the proposal for Issue 124 or do we need a new issue?
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
From:
| Eric Johnson <eric@tibco.com>
|
To:
| Mike Edwards/UK/IBM@IBMGB
|
Cc:
| Anish Karmarkar <Anish.Karmarkar@oracle.com>,
sca-bindings@lists.oasis-open.org
|
Date:
| 27/03/2010 00:05
|
Subject:
| Re: [sca-bindings] Issue 124 proposal
version 2 - a comment |
Hi Mike,
Was their discussion of your point during the conference call?
What are the cases here?
- service, @wsdlElement references port - BWS20007 states
that you must somehow interpret policy from the WSDL, and that that policy
must match....
- service, @wsdlElement references binding - BWS20011 -
ditto.
- reference, @wsdlElement references port - BWS20009 - ditto
- reference, @wsdlElement references binding - BWS20013
- ditto.
- reference, @wsdlElement references service - oops, looks
like we missed this case.
So my interpretation is
that if you reference a WSDL directly, if you don't understand some policy
language, then you'll be forced to reject scenarios that the customer expects
you to accept. Yet, if I'm reading SCA-Policy correctly, a conforming
runtime will already support WS-Policy. So the scenario is that it
could somehow feign ignorance of WS-Policy when it encounters it in WSDL
when used by binding.ws, but support it in other circumstances?
I agree that there's a gap here, but it is a really small one.
Here's a question: If I refer to a WSDL port, is it legitimate for an implementation
to *add* policy implementation on top of a bare port declaration - that
is one that doesn't have WS-Policy statements? For example:
- Can an implementation satisfy a policy intent with the
use of mutual SSL authentication, even if there's nothing about that stated
in the WSDL port that the @wsdlElement references (although presumably
it uses an "https" URL scheme)?
- Likewise, can an implementation decide to use WS-RM even
if the referenced WSDL port doesn't state that in the WSDL?
The
port form of @wsdlElement, then, becomes a way to specify mapping of SOAP
constructs to the XML payload, and not necessarily other constraints.
Are we over-specifying this?
On the WSDL generation side, do we want to mandate that a WSDL MUST be
generated with WS-Policy statements? Should we add something to section
2.4? My quick take is that we should not mandate it.
-Eric.
On 03/25/2010 04:42 AM, Mike Edwards wrote:
Folks,
I'd like to pick up on something Eric mentions in his email below:
" In the context of SCA, if someone uses the @wsdlElement
form, then they'd be forced to support the WS-Policy spec"
I find it surprising that the SCA binding.ws specification does not REQUIRE
support of the WS-Policy specification.
This is particularly the case given that the spec defines a WS-Policy policy.
So: Should we raise an issue to add a conformance requirement that a binding.ws
implementation MUST support the WS-Policy
specification (although not any specific policy assertions other than the
one defined within the binding.ws spec).?
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
Hi Anish,
On 03/24/2010 02:51 PM, Anish Karmarkar wrote:
Version 2 based on feedback from last week's call is attached.
* Fixed editorial bugs pointed out by EricJ in section 6.
* I did some due diligence on the question of whether creating independent
conformance points for WSCB service/client results in a problem (as pointed
out by EricJ), since the other non-section5 conformance items are no longer
applicable to WSCB service/client. I found 5 assertions that are somewhat
related (noted below). The others are about binding.ws syntactic elements/attributes
or something similar.
Thanks for spending the time to do that. I've been hoping to find
the time to get to that all week, and didn't, so I'm glad you did.
a) there is MUST for SOAP 1.1 and a SHOULD for SOAP 1.2. Section 5 also
talks in several places about SOAP header blocks. Strictly speaking there
is no necessity to require SOAP (1.1 or 1.2) for this protocol. It could
depend only on WS-Addressing. But that is a separate issue. To fix this,
I have changed the intro to 5.1 to state that this is a soap/ws-addressing
based protocol. I didn't see a reason to introduce assertions for requiring
SOAP/WS-A. It is required by definition. But if ppl feel strongly we can
introduce new conformance items.
Seems sort of ironic, though, if we define this stand-alone protocol, and
then it is possible to implement it in a way that is conformant, and yet
not compatible with an SCA runtime. Seems to me that we should require
the equivalent level of SOAP support, and therefore have the MUST and SHOULD
requirements around SOAP.
Maybe this is an equivalent nit, but we should likewise require support
for HTTP & HTTPS.
BWS50010 is sort of tricky. In the context of SCA, if someone uses
the @wsdlElement form, then they'd be forced to support the WS-Policy spec,
as well as this requirement to recognize this policy assertion when it
appears in WSDL. Yet if we step away from that, to this stand-alone
definition, what's the conformance target for saying "if your WSCB
supports WSDL, then you must support this policy assertion?"
Likewise for BWS50013 & 50014.
b) There is a requirement for conforming to SCA assembly and policy. I
don't think this is needed (it would defeat the purpose of the issue itself).
c) There is a SHOULD for http endpoints to provide a wsdl description when
queried with ?wsdl and a SHOULD for non http endpoints to provide some
way to obtain the WSDL descriptions. I didn't see a need to have this requirement
on WSCB service/client endpoints. I see this as a SCA runtime requirement
not a protocol requirement.
* wrt Dave's comment about BWS5005/7, I'm not sure what needs to change.
I added a sentence at the beginning of section 5.1 that says that WSCB
service implements the forward interface and the WSCB client implements
the callback interface.
Comments?
Miscellaneous nit - Sections 6.2 & 6.3 reference Appendix B for "Conformance
items related to WSCB...", but that shows up as Appendix C.
And in section C, I don't see that you've separated out the conformance
requirements for WSCB client and server into a separate section.
Two minor editorial nits that I noticed, which Anish's proposal didn't
change, per-se:
"There are four categories of artifacts for which... SCA WS Binding
XML Document ... SCA Runtime"
Shouldn't this be (to match the plural form):
"There are four categories of artifacts for which... SCA WS Binding
XML Documents ... SCA Runtimes"
I also don't like the use of "artifact" here, because I associate
the word with something less operational than an "SCA Runtime".
Can't we just use the phrase:
"This specification defines four targets for conformance:"
-Eric
-Anish
--
On 3/18/2010 9:01 AM, Anish Karmarkar wrote:
Proposal for issue 124 as outlined in [1] is attached.
-Anish
--
[1] http://lists.oasis-open.org/archives/sca-bindings/201003/msg00000.html
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]