I had one action item, which was to investigate whether JAX-WS could
control the use of the namespace for the generated element in the case
of RPC/literal bindings. After pouring over the JAX-WS specification
for some time, and looking carefully at the "WebParam" annotation,
which comes closest to covering this issue, I came to the conclusion
that JAX-WS is silent on this issue. That annotation is actually
defined in JSR 181, and looking at that specification, it says, clearly
"Only used if the operation is document style or the paramater maps to
a header." Since this is not the case we're concerned about it would
seem that it does not apply. In the interest of satisfying other
possible concerns about the "MUST" for the specific choice of
namespace, I've suggested below that we change it to a "SHOULD."
The revised proposal for resolving issue 11:
Section 2.2, paragraph #1 currently reads:
When binding.ws is used on a service or reference with an interface
that is not defined by interface.wsdl, then a WSDL portType for the
service or reference is derived from the interface by the rules defined
for that SCA interface type.
I suggest changing this to:
When binding.ws is used on a service or reference with an interface
that is not defined by interface.wsdl, then a WSDL portType for the
service or reference is derived from the interface by the rules defined
for that SCA interface type. A conforming An
SCA runtime MUST raise an
error if the interface does not map to a WSDL portType.
4 Transport Binding
The binding.ws element provides numerous ways to
specify exactly how messages ought to be transmitted from or to the
reference or service. Those ways include references to WSDL binding
elements from the @wsdlElement attribute, policy intents, and even
vendor extensions within the binding.ws element. However, all of
those ways to indicate how messages get carried happen to be
optional. This section describes the defaults to
be used if the
specific transport
details are not otherwise specified.
4.1 Intents
So as to narrow the range of choices for how messages
are carried, the following policy intents affect the transport
binding.
-
soap
This indicates that messages MUST be transmitted using SOAP. One or
more SOAP versions can be used.
-
soap.1_1
Messages MUST be transmitted using only SOAP 1.1.
-
soap.1_2
Messages MUST be transmitted using only SOAP 1.2.
4.2 Default Transport Binding Rules
4.2.1 WS-I Basic Profile Alignment
To align to WS-I Basic Profile, the resulting WSDL port needs
to be all
document-literal, or all rpc-literal binding (R2705).
This means, for any given portType, for all messages referenced by all
operations in that portType, either
- that every message part references an XML Schema type
(rpc-literal pattern)
- or that every message references exactly zero or one XML
Schema elements (document-literal pattern)
A portType that does not fit one of these two patterns MUST be
treated as an error by a conforming implementation.For a
service element, the portType from the service's interface or
derived from the service's interface MUST fit one of these two
patterns. The rest of this
section assumes the short-hand reference of a "rpc-literal" or
"document-literal" pattern, depending on which of the two bullet points
above it matches.
4.2.2 Default Transport Binding Rules
In the event that the transport details are not otherwise
determined, a conforming implementation MUST enable the following
configuration:
-
HTTP-based transfer protocol
-
Except when an intent or policy mandates the use of only
SOAP
1.2, generate bindings for SOAP 1.1
Bindings
for SOAP 1.1 MUST be provided and additional
bindings MAY be provided, unless policy is applied that explicitly
restricts this.
-
"literal" format as described in section 3.5 of [WSDL11]
-
For document literal
pattern, each message uses "document" style, as per section 3.5 of
[WSDL11].
-
For rpc-literal
pattern, each message uses "rpc" style, as per section 3.5 of
[WSDL11]. In this case, the child elements of the SOAP Body element MUST
be namespace qualified with a
non-empty namespace name. This
namespace MUSTSHOULD be the structural URI
associated with the binding.
-
For SOAP 1.1 messages, the SOAPAction HTTP header described in
section 6.1.1 represents the empty string, in quotes ("").
-
For SOAP 1.2 messages, the SOAP
Action feature
described in section 6.5 of [SOAP12Adjuncts] does not appear.
-
All WSDL message parts are carried in the SOAP body
B. Appendix - WSDL Generation
Due to the number of factors that determine how a WSDL might be
generated, including compatibility with existing WSDL uses, precise
details cannot be specified. For example, implementation decisions can
affect the way WSDL
might be generated. For reference, and consistency, this section
suggests non-normative choices for some of the various details
involved in generating WSDL. For brevity, the following definitions
apply:
- component name = the value of the @name attribute of the
component element containing the binding.ws element
- service name = the value of the @name attribute of the service
element containing the binding.ws element
- binding name = the value of @name attribute of the binding.ws
element, or the default if no @name attribute is present
- SOAP version = either "SOAP11" or "SOAP12" as appropriate
With those definitions in place, here are the suggested choices:
-
wsdl:definitions/@name =
<component name> + "." + <service
name>
-
wsdl:definitions/@targetNamespace =
<structural URI for the service>
-
import each WSDL 1.1 portType,
rather than putting them inline
-
wsdl:binding/@name = <binding
name> + <SOAP version> + "Binding"
|