On Jul 2, 2010, at 12:57 PM, Mike Edwards wrote:
Jim,
You're almost certainly right that this
approach of inserting handlers which inspect the namespace of the SOAP
messages would do the job
- and it is likely that this could be
done for most implementations of Web services.
My disappointment is that (certainly
for Axis), the generated WSDL contains the SOAP 1.1 bindings even when
you ask for SOAP 1.2 (you can
suppress the SOAP 1.2 bindings, but
not the SOAP 1.1 ones). It seems very odd to advertise support for SOAP
1.1 and then have a handler
raise an exception when SOAP 1.1 is
received.
So, perhaps it can be done, although
at a little cost. Perhaps that cost does not matter, since most
folks are not going to care about which
version of SOAP they are using, but
for those that DO care, then getting the right SOAP version must matter
and the cost is not very relevant.
I agree that would be odd to raise an exception when SOAP 1.1 is advertised in the WSDL.
For Metro, the default generated WSDL can be replaced, which should be a way to ensure the correct bindings are advertised. Unless a runtime is using an SCA-aware web services stack, I imagine this capability of replacing (or modifying) the default generated WSDL needs to be implemented anyway as policy set merging will require it. Maybe there is a hook point in Axis2 to do this as well?
Jim
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
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
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
| From:
| Eric Johnson <eric@tibco.com>
|
| To:
| OASIS SCA Bindings <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
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
|