5. Client Configuration
I would propose that we make the decoupled destination configuration
part of
the Client
<jaxws:client id="...SomePort">
<jaxws:asynchronousEndpoint>
<wsa:Address>http://my.decoupled/endpoint</wsa:Address>
</jaxws:asynchronousEndpoint>
</jaxws:client>
<jaxws:client id="...SomePort">
<jaxws:asynchronousDestination><http:destination...></jaxws:asynchronousDestination>
</jaxws:client>
As an added bonus, we can now wire together clients and destinations
however
we want. I wouldn't *have* to create a <conduit> config element with the
port name inside it. Instead I could simply do:
<jaxws:client id="...SomePort">
<jaxws:conduit> <http:conduit... /> </jaxws:conduit>
</jaxws:client>
It also creates a central place to embed Client configuration - such as
enabling MTOM or configuring WS-*:
<jaxws:client id="...SomePort">
<jaxws:conduit>...</jaxws:conduit>
<jaxws:binding mtomEnabled="true">
<jaxws:requestContext>
<map><entry key="javax.xml.ws.session.maintain"
value="true"/></map>
</jaxws:requestContext>
</jaxws:binding>
<jaxws:features>
<wsrm:reliability timeout="10000" .../>
</jaxws:features>
</jaxws:client>
What is the connection between the <wsrm:reliability> element and the
RMAssertion? Is the timeout attribute in <wsrm:reliability> element
synonymous with the InactivityTimeout in the RMAssertion?
I would like to see the above way of configuring WS-* features in sync
with the configuration of these features as envisaged in their resp.
specs, both at the data level (i.e. reuse of the RMAssertion type for
example) and for aggregation purposes (use WS-Policy to specify
optionalities, requirements, express alternatives etc.).
Why not allow <wsp:Policy
xmlns:wsp="http://www.w3.org/2006/07/ws-policy";> child elements in
<jaxws:client>?
BTWwhat is actually jaxws specific about these features - or the
client/conduit injection for that matter? It should be possible to
inject a conduit into any kind of client (and configure its WS-*
features) - JAXWS or not.
Andrea.
