[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
On 7/5/2010 3:41 AM, Mike Edwards wrote: > > 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. > Which ones are you thinking of? The only header that SOAP 1.2 defines is the Upgrade header, which isn't relevant here. The header architecture (from a practical perspective) is the same for both SOAP 1.1 and 1.2 (especially when you bring in WS-I BP), modulo minor difference such as 'actor' is called 'role' and SOAP 1.2 defines intermediaries much more rigorously. -Anish -- > 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_ <mailto:mike_edwards@uk.ibm.com> > > From: Anish Karmarkar _<Anish.Karmarkar@oracle.com>_ > <mailto:Anish.Karmarkar@oracle.com> > To: _sca-bindings@lists.oasis-open.org_ > <mailto: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> > <_mailto:mike_edwards@uk.ibm.com_> > >> > >> > >> From: Bryan Aupperle <_aupperle@us.ibm.com_ > <mailto: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> > >> <_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> > <_mailto:aupperle@us.ibm.com_> > >> > >> From: Eric Johnson <_eric@tibco.com_ <mailto:eric@tibco.com> > <_mailto:eric@tibco.com_>> > >> To: OASIS SCA Bindings <_sca-bindings@lists.oasis-open.org_ > <mailto: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]