Daniel Kulp wrote:
- ensuring the multiplicity of conduit beans configured alongside a
failover selector is consistent with the set of ports defined in the
WSDL, as the CXF static failover strategy is based on burning the
alternate ports into a multi-port service definition in the WSDL.
Well, this COULD actually remove that limitation. A FailoverSelector
could have a bunch of conduits configured via configuration (like
roundrobin) and failover from one to the other. Thus, the failover
stuff would work for code first cases much better. If the
FailoverSelector doesn't have any conduits coming in from spring, it
could use the multi-port strategy it currently uses.
Yeah, that makes sense all right in the particular case of the alternate
addresses being taken from the WSDL. Encoding the alternate addresses in
<wsdl:port>s versus configuring the same info in the <jaxws:conduit>
would be similar strategies in the sense that in both cases the cluster
is statically defined (i.e. of fixed size and membership, modulo changes
to WSDL or config, which would generally require a restart/refresh in
the client).
But I also had in mind the case where the addresses are retrieved
dynamically from some external agency, such as a registry service. I've
built an example of this approach in another project which is layered
over CXF. In this case the cluster is dynamically assembled, and no
specific addressing info is statically burned into the client's WSDL (or
config).
Now in this latter case, there's a slightly different possible use-case
for the <jaxws:conduit> wiring. Instead of using this mechanism to
inject the target addresses (and other config) for individual conduits,
we could instead have a place-holder "abstract" conduit bean containing
only non-address config to be used for any concrete conduit instance (of
a particular type) created for this proxy over its lifetime, including
any failover events.
So for example, suppose I wanted to ensure that AllowChunking was always
set to false for a particular proxy because I suspect there's a bug in
the server-side stack's support for HTTP chunking (real-life example
from our own in-house interop testing). And say I'm using my
registry-mediated faliover strategy. In this case it would be neat to
just do something like:
<jaxws:client name="{http://apache.org/hw}MyPort";>
<clustering:failover>
<clustering:strategy>
<ref bean="RegistryMediated"/>
</clustering:strategy>
</clustering:failover>
<jaxws:conduit>
<http:conduit name="{http://apache.org/hw}MyPort.http-conduit";
abstract="true">
<http:client AllowChunking="false"/>
</http:conduit>
</jaxws:conduit>
...
</jaxws:client>
and have the AllowChunking="false" applied to *any* HTTP conduit created
for this proxy over its lifetime.
Cheers,
Eoghan
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
