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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

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


Subject: Re: [sca-bindings]ISSUE 130: Testing experience suggests requirementsBWS40002 & BWS40003 are too strict for services



Eric,

I can think of a case where I write an application that uses the features of SOAP 1.2 - an example might be use of the extra headers
that SOAP 1.2 uses.

If I have such an application, then restricting the service endpoint to SOAP 1.2 is exactly what the application wants - providing a SOAP 1.1
endpoint ain't going to work.

That's the benefit.

I think now that I can see a way to implement the function, that it is reasonable to say that SCA runtimes must provide it.


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: sca-bindings@lists.oasis-open.org
Date: 02/07/2010 18:40
Subject: Re: [sca-bindings]ISSUE 130: Testing experience suggests requirements BWS40002 & BWS40003 are too strict for services





Hi Mike,

The counterpoint I can offer to "close, no action", is simply this:

What's the use case for being restrictive in what we accept?

The discussion seems to be, so far, yes, we can jump through hoops, file bugs, get problems fixed, and work-around others.  But to what benefit?  That it simply makes the spec harder to implement?

Eric.

On 07/02/2010 04:06 AM, Mike Edwards wrote:


Anish,


One important point to remember here is that Intents mark restrictions - and the restrictions are supposed to be honoured.


If I follow your thought that "additional" stuff is OK, let's look at what that might mean when it comes to Intents in the area of Security.


Let's consider a Service marked with the @Confidentiality intent.  So that means a restriction that the service is only supposed to

deal with messages that are encrypted.  May be encrypted in the transport (eg HTTPS) or encrypted in the Messages (various

alternatives from WS-Security), but it must be encrypted.


Following your logic below, it will be "OK" if the same service is ALSO offered via an additional transport/protocol that is NOT encrypted.

This does not make sense to me, and I feel the heavy tramp of the corporate security guys towards my door.


I think that in this scenario, it is most certainly NOT good to offer more ways of accessing such a service.



Returning to SOAP.v1_2 - presumably if a service is marked this way, it is done for a reason.  Perhaps the service inspects headers

from SOAP 1.2 and depends on them. In this case too, offering the service over SOAP 1.1 is not going to work - @requires="SOAP.v1_2"

is a restriction and has some meaning.  The meaning needs to be honoured.



So, my position now on Issue 130 is to Close with No Action - the spec is correct as written and the SCA Runtime vendors are going

to have to fix up their code, for example using header processors of the type that Jim described in his recent note.  This will work with

the one fly in the ointment that Axis (as far as I can see) will still advertise support for SOAP 1.1 even when only SOAP 1.2 is accepted.

Time to get Axis fixed....




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: Anish Karmarkar <Anish.Karmarkar@oracle.com>
To: sca-bindings@lists.oasis-open.org
Date: 01/07/2010 17:05
Subject: Re: [sca-bindings] NEW ISSUE: Testing experience suggests requirements BWS40002 & BWS40003 are too strict for services






I think the higher-level issue, regardless of whether an implementation
as it exists can be restricted or not, is:
does it make sense for the spec to say that a particular service must
not support *additional* transports/protocols?
I tend to think that it is sufficient for the spec to say what the
service must do and stay away from saying what it must not do. For
example, if a service wants to accept messages from entities outside of
SCA, why should the SCA spec restrict it?

-Anish
--

On 7/1/2010 8:54 AM, Jim Marino wrote:
> As quick thought, have you tried inserting a JAX-WS handler that checks
> the message version (I'm assuming Axis2 supports JAX-WS handlers since
> it claims to be JAX-WS compliant)?
>
> I'm pretty sure Metro (the JAX-WS RI) can also be configured at a lower
> level to do this by inserting a custom Tube into the processing chain
> that handles requests. WSIT layers on top of Metro in this way to
> provide support for WS-Policy, WS-Security and reliable messaging. We've
> done this for a number of things in Fabric3 as well, including
> integrating WS-Security with the F3 authentication and authorization
> infrastructure. In general, we have found Metro to be easier to deal
> with than Axis2.
>
> Jim
>
> On Jul 1, 2010, at 9:02 AM, Mike Edwards wrote:
>
>>
>> Bryan,
>>
>> The client (JAXWS) side is set up so that it either sends SOAP 1.1 or
>> SOAP 1.2. The SCA server side uses Tuscany which uses Axis2.
>>
>> We can't (yet) find a way to get Axis2 to stop accepting SOAP 1.1
>> messages for a simple <binding.ws requires="SOAP.v1_2"/> binding.
>>
>> We have not tried using a WSDL on the server side, but that is missing
>> the point, since the test is trying to test the simple binding of the
>> form above.
>>
>>
>> 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 <mailto:mike_edwards@uk.ibm.com>
>>
>>
>> From:                  Bryan Aupperle <
aupperle@us.ibm.com <mailto:aupperle@us.ibm.com>>
>> To:                  OASIS SCA Bindings <
sca-bindings@lists.oasis-open.org
>> <
mailto:sca-bindings@lists.oasis-open.org>>
>> Date:                  30/06/2010 14:39
>> Subject:                  Re: [sca-bindings] NEW ISSUE: Testing experience suggests
>> requirements BWS40002 & BWS40003 are too strict for services
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> Mike,
>> when you were trying to force a service to only receive messages using
>> SOAPI 1.2, what happened if the only binding in the WSDL had a
>> <SOAP:binding/> element with the transport attribute set to the SOAP
>> 1.2 URL (_
http://www.w3.org/2003/05/soap/bindings/HTTP/_)?
>>
>> I think you can control this using the JAX-WS @BindingType annotation.
>>
>> Bryan Aupperle, Ph.D.
>> STSM, WebSphere Enterprise Platform Software Solution Architect
>> WW Center of Excellence for Enterprise Systems & Banking Center of
>> Excellence Application Integration Architect
>>
>> Research Triangle Park, NC
>> +1 919-254-7508 (T/L 444-7508)
>> Internet Address:
aupperle@us.ibm.com <mailto:aupperle@us.ibm.com>
>>
>> From:                  Eric Johnson <
eric@tibco.com <mailto:eric@tibco.com>>
>> To:                  OASIS SCA Bindings <
sca-bindings@lists.oasis-open.org
>> <
mailto:sca-bindings@lists.oasis-open.org>>
>> Date:                  06/17/2010 06:59 PM
>> Subject:                  [sca-bindings] NEW ISSUE: Testing experience suggests
>> requirements BWS40002 & BWS40003 are too strict for services
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> Target: sca-wsbinding-1.1-spec-cd03
>>
>> Title: Testing experience suggests requirements BWS40002 & BWS40003 are
>> too strict for services
>>
>> Description:
>>
>> Current normative statements:
>>
>> When the SOAP.1_1 intent is required, the SCA runtime MUST transmit and
>> receive messages using only SOAP 1.1. [BWS40002]
>>
>> When the SOAP.1_2 intent is required, the SCA runtime MUST transmit and
>> receive messages using only SOAP 1.2. [BWS40003]
>>
>> Mike Edward's experience in creating test cases suggests that at least
>> two existing implementations (Axis, JAX-WS reference implementation) of
>> SOAP stacks will gladly accept SOAP 1.1 or SOAP 1.2 at a given endpoint,
>> and that restricting them to only allowing SOAP 1.1 or SOAP 1.2 is
>> actually tricky, if it is even possible.
>>
>> This suggests that the normative statements, when applied to *services*
>> are perhaps overly strict. Note that it still makes sense to have these
>> policy intents on references.
>>
>> Proposal:
>>
>> Change the normative statements to read as follows:
>> When the SOAP.1_1 intent is required on a reference, the SCA runtime
>> MUST transmit and receive messages using only SOAP 1.1. [BWS40002]
>>
>> When the SOAP.1_2 intent is required on a reference, the SCA runtime
>> MUST transmit and receive messages using only SOAP 1.2. [BWS40003]
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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/
>>
>>
>>
>>
>>
>>
>

---------------------------------------------------------------------
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]