[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] NEW ISSUE: Testing experience suggests requirementsBWS40002 & 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/ >> >> >> >> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]