You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Dan Diephouse <da...@envoisolutions.com> on 2007/02/27 17:05:50 UTC
Client API, EPRs
Hi All,
Is there a way to use WS-Adressing from the Client API? Specifically I'd
like to be able to set the replyTo/faultTo locations somehow for the Client
itself and then also on the invocation context:
client.setReplyTo(new EndpointReference("http://foo/replyTo"));
Or:
Map<String, Object> context = ...;
context.put(REPLY_TO, epr);
client.invoke(operation, args, context);
This brings up the question in my mind of whether or not we really want to
use EndpointReferenceType throughout the codebase. I'm uncomfortable with
the way things stand as
- EndpointRefenceType has an ugly API. It is not easy to create an EPR from
a String/URL and I think it should be doable via a constructor. (Yeah, we
can create factories, but thats ugly and it still doesn't make retrieving
values friendlier).
- We seem to have an odd mixture of EndpointReferenceTypes and EndointInfos
going on in our transport interfaces. On some methods we require both. It
seems like it should be either one or the other.
- WIth that said, using an EndpointInfo is odd to me as thats part of the
service model. Using an EPR seems unnatural for reasons I state above.
Whats the advantage of using EndpointReferenceType throughout the codebase
as opposed to our own class?
Regards,
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Client API, EPRs
Posted by Andrea Smyth <an...@iona.com>.
Yes this should be possible , at least it was at some stage. Right now
the corresponding system test is disabled, see
org.apache.cxf.systest.ws.addressing.MAPTestBase.xtestExplicitMAPs().
Andrea.
Daniel Kulp wrote:
>On Tuesday 27 February 2007 11:05, Dan Diephouse wrote:
>
>
>>Is there a way to use WS-Adressing from the Client API?
>>
>>
>
>We need it as part of JAX-WS 2.1. I haven't had time to look into what
>changes we need to support that.
>
>Dan
>
>
>
>
>>Specifically I'd
>>like to be able to set the replyTo/faultTo locations somehow for the
>>Client itself and then also on the invocation context:
>>
>>client.setReplyTo(new EndpointReference("http://foo/replyTo"));
>>
>>Or:
>>
>>Map<String, Object> context = ...;
>>context.put(REPLY_TO, epr);
>>client.invoke(operation, args, context);
>>
>>This brings up the question in my mind of whether or not we really want
>>to use EndpointReferenceType throughout the codebase. I'm uncomfortable
>>with the way things stand as
>>- EndpointRefenceType has an ugly API. It is not easy to create an EPR
>>from a String/URL and I think it should be doable via a constructor.
>>(Yeah, we can create factories, but thats ugly and it still doesn't make
>>retrieving values friendlier).
>>- We seem to have an odd mixture of EndpointReferenceTypes and
>>EndointInfos going on in our transport interfaces. On some methods we
>>require both. It seems like it should be either one or the other.
>>- WIth that said, using an EndpointInfo is odd to me as thats part of
>>the service model. Using an EPR seems unnatural for reasons I state
>>above.
>>
>>Whats the advantage of using EndpointReferenceType throughout the
>>codebase as opposed to our own class?
>>
>>Regards,
>>- Dan
>>
>>
>
>
>
Re: Client API, EPRs
Posted by Daniel Kulp <da...@iona.com>.
On Tuesday 27 February 2007 11:05, Dan Diephouse wrote:
> Is there a way to use WS-Adressing from the Client API?
We need it as part of JAX-WS 2.1. I haven't had time to look into what
changes we need to support that.
Dan
> Specifically I'd
> like to be able to set the replyTo/faultTo locations somehow for the
> Client itself and then also on the invocation context:
>
> client.setReplyTo(new EndpointReference("http://foo/replyTo"));
>
> Or:
>
> Map<String, Object> context = ...;
> context.put(REPLY_TO, epr);
> client.invoke(operation, args, context);
>
> This brings up the question in my mind of whether or not we really want
> to use EndpointReferenceType throughout the codebase. I'm uncomfortable
> with the way things stand as
> - EndpointRefenceType has an ugly API. It is not easy to create an EPR
> from a String/URL and I think it should be doable via a constructor.
> (Yeah, we can create factories, but thats ugly and it still doesn't make
> retrieving values friendlier).
> - We seem to have an odd mixture of EndpointReferenceTypes and
> EndointInfos going on in our transport interfaces. On some methods we
> require both. It seems like it should be either one or the other.
> - WIth that said, using an EndpointInfo is odd to me as thats part of
> the service model. Using an EPR seems unnatural for reasons I state
> above.
>
> Whats the advantage of using EndpointReferenceType throughout the
> codebase as opposed to our own class?
>
> Regards,
> - Dan
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
RE: Client API, EPRs
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> Contrary to what Eoghan said, the JAX-WS EndpointReference is
> actually LESS
> friendly.
Well I said it was less ugly, not more friendly ... Eye of the beholder
and all that :)
/Eoghan
Re: Client API, EPRs
Posted by Daniel Kulp <da...@iona.com>.
On Tuesday 27 February 2007 11:05, Dan Diephouse wrote:
> This brings up the question in my mind of whether or not we really want
> to use EndpointReferenceType throughout the codebase. I'm uncomfortable
> with the way things stand as
> - EndpointRefenceType has an ugly API. It is not easy to create an EPR
> from a String/URL and I think it should be doable via a constructor.
> (Yeah, we can create factories, but thats ugly and it still doesn't make
> retrieving values friendlier).
> - We seem to have an odd mixture of EndpointReferenceTypes and
> EndointInfos going on in our transport interfaces. On some methods we
> require both. It seems like it should be either one or the other.
> - WIth that said, using an EndpointInfo is odd to me as thats part of
> the service model. Using an EPR seems unnatural for reasons I state
> above.
>
> Whats the advantage of using EndpointReferenceType throughout the
> codebase as opposed to our own class?
The main advantage is that it's schema driven/jaxb generated and can be
written/read directly via normal JAXB operations. It also means it
should (in theory) be easy to convert to/from other implementations (like
the JAX-WS 2.1 EndpointReference).
Contrary to what Eoghan said, the JAX-WS EndpointReference is actually LESS
friendly. It doesn't provide ANY access to any of the information other
than a "write(Result)" method to write it to a Result. The
only "constructor" is:
EndpointReference readFrom(Source eprInfoset)
The main thing the JAX-WS stuff has is methods to automatically create
proxies and for the EndpointReferences and to create EndpointReferences
from the Service and such.
Is there a way to get JAXB to generate it as "AbstractEPR" and then provide
a concrete class that subclasses it that the ObjectFactory would create?
We could provide a bunch of utility constructors, methods, etc... I
think I need to read the jaxb extensor stuff a bit more.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: Client API, EPRs [subject got lost last time ...]
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 3/16/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
>
> > 99.9999% of the people will have a Client.
>
> Agreed a lot of folks will use the client. Maybe 99.9999%, maybe any
> other percentage you care to pluck from the air.
>
> But I don't see why that justifies making it gratuitously awkward to
> avoid using it.
Its not gratuitously awkward to create your own Destination. You create your
EPR and then your Destination. From the amount of work that is required, it
certainly isn't more than creating a ClientPolicy and setting the EPR on the
ClientPolicy. However it does avoid the things I mention below...
> Because of API complexity and inconsistency as I've stated in my other
>
> > emails.
>
> Can you be explicit as to exactly what in the API you consider complex
> and/or inconsistent.
This: c.getPolicy(ConduitPolicy.class).setDecoupledEndpoint(myEPR)
This has the following affects compared to my proposal
1. Creation of a new ConduitPolicy class - *which is unnecessary*
2. It creates a different way of creating Destinations that is only used
sometimes. You're saying that users should use the ClientPolicy to set up
the ReplyTo and for any other decoupled destinations (like FaultTo or
AcksTo), they have to create it using the DestinationFactory API.
3. It requires an additional Conduit method - Conduit.getBackChannel() -
which complexifies the Conduit concept.
4. Creates a non DI friendly API (see below)
> Its not DI/Spring friendly though.
>
> Couldn't a DRE bean just be <ref>erred to from the Conduit bean, if
> Spring-loading of the DRE is the issue?
>
> As opposed to wiring it into a new Client bean, thereby forcing the
> usage of a Client?
>
> What makes the wiring the DRE bean into the Client bean any more
> "DI/Spring friendly" than wiring it into the Conduit bean?
c.getPolicy(ConduitPolicy.class) is not spring friendly at all. You would
have to create a <map>, <entry>, a clientpolicy bean, and then set the
decoupled EPR. I'm looking for a more bean oriented approach. I want to be
able to create a destination and inject it directly into my client.
You're also nesting the destination unnecessarily inside the conduit. What
if I just want to change the decoupled destination? Adding a ConduitPolicy
bean is unnecessary.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Client API, EPRs [subject got lost last time ...]
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> 99.9999% of the people will have a Client.
Agreed a lot of folks will use the client. Maybe 99.9999%, maybe any
other percentage you care to pluck from the air.
But I don't see why that justifies making it gratuitously awkward to
avoid using it.
> Because of API complexity and inconsistency as I've stated in my other
> emails.
Can you be explicit as to exactly what in the API you consider complex
and/or inconsistent.
> Its not DI/Spring friendly though.
Couldn't a DRE bean just be <ref>erred to from the Conduit bean, if
Spring-loading of the DRE is the issue?
As opposed to wiring it into a new Client bean, thereby forcing the
usage of a Client?
What makes the wiring the DRE bean into the Client bean any more
"DI/Spring friendly" than wiring it into the Conduit bean?
/Eoghan
Re: Client API, EPRs
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 3/16/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: 16 March 2007 01:24
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Client API, EPRs
> >
> > On 3/15/07, Glynn, Eoghan <eo...@iona.com> wrote:
> > >
> > >
> > > >
> > > >
> > > > -1: as I stated in my other email, there isn't any reason to put
> > > > the DRE inside the conduit.
> > > >
> > > > It is much more straightforward to put the Destination on
> > the Client
> > > > and and have the Client shutdown both the Conduit & DRE. Its
> > > > completely unncessary to introduce yet more complexity into our
> > > > transport APIs for this.
> > >
> > >
> > > Obviously my -1 to your -1 :)
> > >
> > > It's a separation of concerns thing. The DRE is IMO an
> > aspect of the
> > > transport. Thus it is best managed within the realm of the
> > transport.
> > >
> > > It's also an existence issue. First we're not guaranteed to
> > even have
> > > a Client instance. Apart from the JAX-WS Dispatch example,
> > which fair
> > > enough could might someday be rebased on the Client (though
> > the return
> > > value handling is a bit different, a List in the Client's
> > case, but a
> > > single Object of type Source or SOAPMessage for the
> > Dispatch). But do
> > > we really want to _require_ that a Client is always used?
> > Suppose the
> > > app just wants to throw together some special-purpose interceptor
> > > chain and kick off the dispatch directly itself. Do we want to
> > > disallow this approach, or force the app to directly manage the DRE
> > > itself in that case?
> >
> >
> > Is that hard for them to do a
> > destinationFactory.getDestination(epr)? I don't think so.
>
>
> Well I do think so :)
>
> The problem is not the complexity of a making a call to
> DestinationFactory.getDestination() per se.
>
> It's the fact of either always having to make this call
> programmatically, or else manage a configuration mechanism so the DRE
> may be specificied declaratively (in config) if the application doesn't
> set it explicitly.
>
> I hope you're not suggesting that we *only* support setting the DRE
> imperatively, i.e. via a programmatic API?
>
> Assuming you're not, then obviously we'd need the option of pulling the
> DRE in from config. But what would this config policy be associated
> with?
>
> The Client? Well maybe there's no Client as I've pointed out.
You pointed out that there is no client if someone is wiring a bunch of
interceptors together by themselves. 99.9999% of the people will have a
Client. And the other people are already working so low level that they're
not going to want an automatically launched DRE anyway.
And yes this configuration can be set with the client and it even makes a
lot more sense that way.
<jaxws:client id="...SomePort">
<asynchronousEPR>...</asynchronousEPR>
</jaxws:client>
OR
<jaxws:client id="...SomePort">
<destination><http:destination...></destination>
</jaxws:client>
As an added bonus this also addresses one of my big gripes about the Client
and transport APIs. Namely that Conduits & Destinations can't be dependency
injected. I should be able to create a client, and wire in arbitrary
conduits/destinations with it. This allows for much more flexibility in your
spring configuration. It gets rid of the need to associate a conduit with an
port name.
Why not just pick it up from the Conduit? We already have an established
> Conduit configuration, and we can always be sure a Conduit will exist
> whenever it makes sense to set a DRE.
Because of API complexity and inconsistency as I've stated in my other
emails.
>
> > If they wanted, they could even create a DecoupledConduit
> > class which transparently manages the underlying Conduit &
> > Destination. But this logic shouldn't be in the normal low
> > level conduits though.
>
>
> I've already suggested putting it into the AbstractConduit. Would that
> address your issue with it being in the low-level Conduits?
NO. It does nothing to address the API complexity or inconsistency issues
I've pointed out.
> And related to both the existence argument and SoC, I'm
> > thinking we may
> > > not even need a Conduit instance at all when mediating an
> > invocation.
> > > An example would be an optimized form of dispatch where a
> > client-side
> > > interceptor can short-circuit out the whole marshalling/transport
> > > thing and instead handle the request directly. So creating
> > the Conduit
> > > from
> > > Client.invoke() seems premature. Which leads me to think
> > that the idea
> > > of the MessageSenderInterceptor creating the conduit, that you
> > > proposed in another with discussion with Polar as an
> > alternate way of
> > > handling the Message.ENDPOINT_ADDRESS override, may in fact be the
> > > proper way to go in *all* cases (if the
> > ConduitInitiator.getConduit()
> > > were to take responsibility for caching pre-existing
> > Conduits with the
> > > same EndpointInfo & target).
> >
> >
> > Are you saying you just want to pass of the request object or
> > whatever to something else and avoid the any kind of
> > serialization or transport? That is completely possible right
> > now. Just make a Conduit which understands
> > Message.getContent(Object.class) and write an ObjectBinding
> > which doesn't do any databinding. The APIs were made to
> > handle *any* representation and if they can't handle one we
> > should be changing those APIs instead of trying to make
> > Conduits optional. I'm strongly against removing the Conduit
> > off the client. Its really handy for manipulating the
> > Conduit's configuration, providing a different Conduit or the like.
>
>
> The Conduit's configuration could be just as easily manipulated via the
> EndpointInfo as I've suggested.
Thats not Spring/Dependency injenction friendly.
And as far as I can see, its *impossible* as things currently stand for
> a different Conduit instance to be provided to the ClientImpl by a
> JAX-WS application. That's because the ClientImpl.initedConduit field is
> protected and may only be set externally via the ctor, which is called
> in jaxws.ServiceImpl.getPort() outside the direct control of the
> application.
>
> So that's hardly really handy.
Also the choice of ConduitInitiator is driven by
> EndpointInfo.getTransportID(). As explained above, a JAX-WS app can't
> avoid the usage of the ConduitInitiator to get the Conduit, i.e. can't
> provide an alternative Conduit implementation upfront. And the
> transportID on the EndpointInfo is currently fixed on creation.
Just because its that way right now, doesn't make it right. We can change
the client to add a setConduit() method.
However the issue of whether the existance of Client implies the
> existance of a Conduit is slightly tangential to the main questions:
>
> 1. must we force Client to exist in order for an invocation to be
> mediated?
If you want to have a DRE automatically set up, then yes, you must the
client.
2. if not, must the application take responsibility for retrieving the
> DRE from config?
No.
3. if not, what other component manages the DRE config?
The Client.
>
> > I still don't see why all these gymnastics are necessary.
>
>
> By gymnastics, do you mean
> "c.getPolicy(ConduitPolicy.class).setDecoupledEndpoint(myEPR)" versus
> "c.setDecoupledEndpoint(myEPR)"?
>
> Its only one extra API call for the app to make. Hardly a quantum leap
> in terms of complexity.
Its not DI/Spring friendly though. It is also inconsistent as I've pointed
out.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Client API, EPRs
Posted by Polar Humenn <ph...@iona.com>.
Dan Diephouse wrote:
> On 3/16/07, Polar Humenn <ph...@iona.com> wrote:
>>
>> I'm trying to follow this discussion, but I need more info on what a
>> "destination" is.
>
>
> A Destination is something that receives messages. Kind of similar to an
> endpoint ;-) It also has a back channel with which to send responses back
> (could be asynchronous or sync)
>
> I'll post a summary of my proposal shortly which people can review, as
> this
> discussion is getting a bit convoluted.
>
> However, I'm in agreement with Dan on the Client-Conduit issue.
>>
>> I am now just *barely* able to hold onto making a trust decision about
>> information that goes out over the wire from the application. At least,
>> with the 1 to 1 relationship between the Client and the Condult, there
>> is some hope that the code operating the client can say it wants its
>> requests to go over a particular conduit it trusts.
>>
>> Completely getting rid of that correlation would ruin that ability.
>>
>>
> Well, we still need to be able to override the address we're talking
> to at
> runtime via the JAX-WS properties. That should probably result in a new
> conduit ala ConduitInitiator.getConduit(EndpointInfo, EPR) instead of
> handling the address change inside the Conduit I would think. But I think
> you don't like that from a security standpoint if I'm reading correctly.
>
> My question to you is this: you're very concerned about somehow getting a
> new conduit which isn't configured with the proper security. But a
> user can
> select a new conduit at any time via the API. Setting the endpoint
> address
> is pretty much equivalent to doing this. Is there really anything we
> can do
> at all in that scenario other than hope that users don't use a conduit
> they
> haven't configured?
>
The goal is assurance and trust. Assurance in the fact that what I
command, actually happens, and trust in the destination (endpoint) of
information.
The components we have are Client and Conduit.
Apparently, the Client is associated with one conduit to which
information flows. If this is the abstraction we can get at that API
level, we must lay our assurance in those components, such that if the
application selects a client and lays certain requirements (security
properties) on that client and conduit we are assured that the system
will comply with our requirements.
I don't mind the "address" switching within the conduit, provided we
make the security requirements (trust decision) know that can happen.
My formost concern is the Client-Conduit relationship. If the Conduit
were allowed to be switched out from underneath the Client, the Client
should get notified of this before it is actually used, so that the
client, or some object governing the security of the Client has a chance
to review, trust, and assure.
Although I haven't investigated it so thoroughly the issue of
Destinations, EndpointReferenceTypes (EPRs), and back channels, it seems
that an architectural decision to associate one particular Conduit with
a Client is the less complicated approach.
The "assurance" questions are, what *assurances* and/or constraints does
the Conduit bring to the table as far as the Client is concerned?
Endpoint Address stability? Protocol Stability Connection Stability?
Trusted Path Stability (proxies?). And equally as important, how to
these assurances and constraints transcend upwards to the Client and to
the application code using the Client.
Cheers,
-Polar
> - Dan
>
Re: Client API, EPRs
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 3/16/07, Polar Humenn <ph...@iona.com> wrote:
>
> I'm trying to follow this discussion, but I need more info on what a
> "destination" is.
A Destination is something that receives messages. Kind of similar to an
endpoint ;-) It also has a back channel with which to send responses back
(could be asynchronous or sync)
I'll post a summary of my proposal shortly which people can review, as this
discussion is getting a bit convoluted.
However, I'm in agreement with Dan on the Client-Conduit issue.
>
> I am now just *barely* able to hold onto making a trust decision about
> information that goes out over the wire from the application. At least,
> with the 1 to 1 relationship between the Client and the Condult, there
> is some hope that the code operating the client can say it wants its
> requests to go over a particular conduit it trusts.
>
> Completely getting rid of that correlation would ruin that ability.
>
>
Well, we still need to be able to override the address we're talking to at
runtime via the JAX-WS properties. That should probably result in a new
conduit ala ConduitInitiator.getConduit(EndpointInfo, EPR) instead of
handling the address change inside the Conduit I would think. But I think
you don't like that from a security standpoint if I'm reading correctly.
My question to you is this: you're very concerned about somehow getting a
new conduit which isn't configured with the proper security. But a user can
select a new conduit at any time via the API. Setting the endpoint address
is pretty much equivalent to doing this. Is there really anything we can do
at all in that scenario other than hope that users don't use a conduit they
haven't configured?
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Client API, EPRs
Posted by Polar Humenn <ph...@iona.com>.
I'm trying to follow this discussion, but I need more info on what a
"destination" is.
However, I'm in agreement with Dan on the Client-Conduit issue.
I am now just *barely* able to hold onto making a trust decision about
information that goes out over the wire from the application. At least,
with the 1 to 1 relationship between the Client and the Condult, there
is some hope that the code operating the client can say it wants its
requests to go over a particular conduit it trusts.
Completely getting rid of that correlation would ruin that ability.
Cheers,
-Polar
Dan Diephouse wrote:
> On 3/15/07, Glynn, Eoghan <eo...@iona.com> wrote:
>>
>>
>> >
>> >
>> > -1: as I stated in my other email, there isn't any reason to
>> > put the DRE inside the conduit.
>> >
>> > It is much more straightforward to put the Destination on the
>> > Client and and have the Client shutdown both the Conduit &
>> > DRE. Its completely unncessary to introduce yet more
>> > complexity into our transport APIs for this.
>>
>>
>> Obviously my -1 to your -1 :)
>>
>> It's a separation of concerns thing. The DRE is IMO an aspect of the
>> transport. Thus it is best managed within the realm of the transport.
>>
>> It's also an existence issue. First we're not guaranteed to even have a
>> Client instance. Apart from the JAX-WS Dispatch example, which fair
>> enough could might someday be rebased on the Client (though the return
>> value handling is a bit different, a List in the Client's case, but a
>> single Object of type Source or SOAPMessage for the Dispatch). But do we
>> really want to _require_ that a Client is always used? Suppose the app
>> just wants to throw together some special-purpose interceptor chain and
>> kick off the dispatch directly itself. Do we want to disallow this
>> approach, or force the app to directly manage the DRE itself in that
>> case?
>
>
> Is that hard for them to do a destinationFactory.getDestination(epr)? I
> don't think so. WS-Addressing interceptors will still work fine even
> though
> there is no client. Its the same case as if they wanted a different
> FaultTo
> or AcksTo.
>
> If they wanted, they could even create a DecoupledConduit class which
> transparently manages the underlying Conduit & Destination. But this
> logic
> shouldn't be in the normal low level conduits though.
>
> And related to both the existence argument and SoC, I'm thinking we may
>> not even need a Conduit instance at all when mediating an invocation. An
>> example would be an optimized form of dispatch where a client-side
>> interceptor can short-circuit out the whole marshalling/transport thing
>> and instead handle the request directly. So creating the Conduit from
>> Client.invoke() seems premature. Which leads me to think that the idea
>> of the MessageSenderInterceptor creating the conduit, that you proposed
>> in another with discussion with Polar as an alternate way of handling
>> the Message.ENDPOINT_ADDRESS override, may in fact be the proper way to
>> go in *all* cases (if the ConduitInitiator.getConduit() were to take
>> responsibility for caching pre-existing Conduits with the same
>> EndpointInfo & target).
>
>
> Are you saying you just want to pass of the request object or whatever to
> something else and avoid the any kind of serialization or transport?
> That is
> completely possible right now. Just make a Conduit which understands
> Message.getContent(Object.class) and write an ObjectBinding which
> doesn't do
> any databinding. The APIs were made to handle *any* representation and if
> they can't handle one we should be changing those APIs instead of
> trying to
> make Conduits optional. I'm strongly against removing the Conduit off the
> client. Its really handy for manipulating the Conduit's configuration,
> providing a different Conduit or the like.
>
> But if there's a DRE involved, then there's also necessarily a Conduit,
>> as we've agreed that the decoupled transport must be the same as the
>> outgoing.
>>
>> To summarize:
>> A) An invocation doesn't imply the existence of Client
>
>
> Not that hard to set up a response destination .
>
> B) A Client shouldn't IMO imply the existence of a Conduit
>
>
> IMO a Client should always have a Conduit.
>
> C) A DRE does imply the existence of a Conduit
>
>
> Sure, but that doesn't mean it should be in the Conduit :-)
>
> This seems to me a complete logical justification for referencing the
>> DRE from the Conduit.
>
>
> I disagree. :-)
>
> And we could actually go one step further than what's currently there
>> and completely decouple the Client from any direct interaction with the
>> transport, by removing the reference even to the Conduit, and setting
>> this up from the MessageSenderInterceptor instead.
>
>
> No need to.
>
>
>
>> 3. My main issue was to avoid a proliferation of
>> > automatically launched
>> > > DREs, as the responsibility for the lifecycle mgmt of these DREs
>> > > should be the responsibility of CXF. Fair enough, the DRE shutdown
>> > > isn't done properly currently, but it would be a tractable
>> > problem to
>> > > do so, by virtue of the cardinality being limited to
>> > one-per-Conduit.
>> > > My whole point was that we shouldn't move to a scenario where for
>> > > example the application setting a replyTo on an
>> > AddressingProperties
>> > > instance set in request context would cause CXF to
>> > automatically launch a new listener.
>> > > The problem here of course is that allowing a per-request setting
>> > > would facilitate the application causing many listeners to
>> > be created
>> > > by CXF, without a good way for the CXF runtime to know when these
>> > > should be shutdown. I take it from your comments in more
>> > recent mails
>> > > on this thread that this is not the sort of mechanism
>> > you're looking
>> > > for, correct?
>> >
>> >
>> > I just want to do :
>> >
>> > Client c = ...
>> > c.setDecoupledEndpoint(myEPR);
>> > c.invoke(...);
>> > c.close();
>>
>>
>> How about this instead:
>>
>> Client c = ...
>> c.getPolicy(ConduitPolicy.class).setDecoupledEndpoint(myEPR);
>> c.invoke(...);
>> c.close();
>>
>> From the point-of-view of the application, both approaches look and
>> smell very similar.
>>
>> Then internally, we'd implement the Client.getPolicy() API something
>> like:
>>
>> public <T> T getPolicy(Class<T> type) {
>> return
>> endpoint.getEndpointInfo().getTraversedExtensor(type.newInstance(),
>> type);
>> }
>>
>> ... ensuring that getTraversedExtensor() caches up the policy instance
>> so that its available to the Conduit when its first created during the
>> message dispatch.
>
>
> I still don't see why all these gymnastics are necessary.
>
>
>>
>> Agreed on getDestination() caching and return a preexisting one if poss.
>>
>> Similarly for ConduitInitiator.getConduit() as I suggest above.
>>
>
> Cool.
>
> - Dan
>
RE: Client API, EPRs
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 16 March 2007 01:24
> To: cxf-dev@incubator.apache.org
> Subject: Re: Client API, EPRs
>
> On 3/15/07, Glynn, Eoghan <eo...@iona.com> wrote:
> >
> >
> > >
> > >
> > > -1: as I stated in my other email, there isn't any reason to put
> > > the DRE inside the conduit.
> > >
> > > It is much more straightforward to put the Destination on
> the Client
> > > and and have the Client shutdown both the Conduit & DRE. Its
> > > completely unncessary to introduce yet more complexity into our
> > > transport APIs for this.
> >
> >
> > Obviously my -1 to your -1 :)
> >
> > It's a separation of concerns thing. The DRE is IMO an
> aspect of the
> > transport. Thus it is best managed within the realm of the
> transport.
> >
> > It's also an existence issue. First we're not guaranteed to
> even have
> > a Client instance. Apart from the JAX-WS Dispatch example,
> which fair
> > enough could might someday be rebased on the Client (though
> the return
> > value handling is a bit different, a List in the Client's
> case, but a
> > single Object of type Source or SOAPMessage for the
> Dispatch). But do
> > we really want to _require_ that a Client is always used?
> Suppose the
> > app just wants to throw together some special-purpose interceptor
> > chain and kick off the dispatch directly itself. Do we want to
> > disallow this approach, or force the app to directly manage the DRE
> > itself in that case?
>
>
> Is that hard for them to do a
> destinationFactory.getDestination(epr)? I don't think so.
Well I do think so :)
The problem is not the complexity of a making a call to
DestinationFactory.getDestination() per se.
It's the fact of either always having to make this call
programmatically, or else manage a configuration mechanism so the DRE
may be specificied declaratively (in config) if the application doesn't
set it explicitly.
I hope you're not suggesting that we *only* support setting the DRE
imperatively, i.e. via a programmatic API?
Assuming you're not, then obviously we'd need the option of pulling the
DRE in from config. But what would this config policy be associated
with?
The Client? Well maybe there's no Client as I've pointed out.
Some other abstraction that's gratuitously added to the mix just to make
this work?
Why not just pick it up from the Conduit? We already have an established
Conduit configuration, and we can always be sure a Conduit will exist
whenever it makes sense to set a DRE.
> WS-Addressing interceptors will still work fine even though
> there is no client. Its the same case as if they wanted a
> different FaultTo or AcksTo.
WS-A is not the issue here.
> If they wanted, they could even create a DecoupledConduit
> class which transparently manages the underlying Conduit &
> Destination. But this logic shouldn't be in the normal low
> level conduits though.
I've already suggested putting it into the AbstractConduit. Would that
address your issue with it being in the low-level Conduits?
> And related to both the existence argument and SoC, I'm
> thinking we may
> > not even need a Conduit instance at all when mediating an
> invocation.
> > An example would be an optimized form of dispatch where a
> client-side
> > interceptor can short-circuit out the whole marshalling/transport
> > thing and instead handle the request directly. So creating
> the Conduit
> > from
> > Client.invoke() seems premature. Which leads me to think
> that the idea
> > of the MessageSenderInterceptor creating the conduit, that you
> > proposed in another with discussion with Polar as an
> alternate way of
> > handling the Message.ENDPOINT_ADDRESS override, may in fact be the
> > proper way to go in *all* cases (if the
> ConduitInitiator.getConduit()
> > were to take responsibility for caching pre-existing
> Conduits with the
> > same EndpointInfo & target).
>
>
> Are you saying you just want to pass of the request object or
> whatever to something else and avoid the any kind of
> serialization or transport? That is completely possible right
> now. Just make a Conduit which understands
> Message.getContent(Object.class) and write an ObjectBinding
> which doesn't do any databinding. The APIs were made to
> handle *any* representation and if they can't handle one we
> should be changing those APIs instead of trying to make
> Conduits optional. I'm strongly against removing the Conduit
> off the client. Its really handy for manipulating the
> Conduit's configuration, providing a different Conduit or the like.
The Conduit's configuration could be just as easily manipulated via the
EndpointInfo as I've suggested.
And as far as I can see, its *impossible* as things currently stand for
a different Conduit instance to be provided to the ClientImpl by a
JAX-WS application. That's because the ClientImpl.initedConduit field is
protected and may only be set externally via the ctor, which is called
in jaxws.ServiceImpl.getPort() outside the direct control of the
application.
So that's hardly really handy.
Also the choice of ConduitInitiator is driven by
EndpointInfo.getTransportID(). As explained above, a JAX-WS app can't
avoid the usage of the ConduitInitiator to get the Conduit, i.e. can't
provide an alternative Conduit implementation upfront. And the
transportID on the EndpointInfo is currently fixed on creation.
Of course we could change things so that the JAX-WS client could do
something like:
ClientProxy.getClient(proxy).getEndpoint().getEndpointInfo().setTranspor
tID("foo:bar");
so that an alternative ConduitInitiator was used instead of the one
provided by full-blown transport.
Or instead allow it to provide an different Conduit instance with
something like:
ClientProxy.getClient(proxy).setConduit(new AlternateConduit());
But I wouldn't agree that this sort of jiggery-pokery to artificially
ensure that there's a Conduit present (that does effectively nothing
anyway) is better than just allowing the outgoing interceptor chain not
to involve a Conduit in the first place if one is not required.
However the issue of whether the existance of Client implies the
existance of a Conduit is slightly tangential to the main questions:
1. must we force Client to exist in order for an invocation to be
mediated?
2. if not, must the application take responsibility for retrieving the
DRE from config?
3. if not, what other component manages the DRE config?
> But if there's a DRE involved, then there's also necessarily
> a Conduit,
> > as we've agreed that the decoupled transport must be the
> same as the
> > outgoing.
> >
> > To summarize:
> > A) An invocation doesn't imply the existence of Client
>
>
> Not that hard to set up a response destination .
As I've said above, not hard in the simplistic case, where its done
programmatically by the application.
But surely we also need to support the declarative approach, where this
is driven from config?
In that case we need *something* to hang the config off.
> B) A Client shouldn't IMO imply the existence of a Conduit
>
>
> IMO a Client should always have a Conduit.
I don't agree. In situations where a Conduit wouldn't add any value, I
find it hard to see why we must force one to exist, only to do nothing
useful.
> C) A DRE does imply the existence of a Conduit
>
>
> Sure, but that doesn't mean it should be in the Conduit :-)
I can't think of a better place for it, short of requiring the existence
of a Client.
The only bullet-proof existence relation we have is that for a DRE to
make sense we MUST have a Conduit.
> This seems to me a complete logical justification for referencing the
> > DRE from the Conduit.
>
>
> I disagree. :-)
>
> And we could actually go one step further than what's currently there
> > and completely decouple the Client from any direct interaction with
> > the transport, by removing the reference even to the Conduit, and
> > setting this up from the MessageSenderInterceptor instead.
>
>
> No need to.
>
>
>
> > 3. My main issue was to avoid a proliferation of
> > > automatically launched
> > > > DREs, as the responsibility for the lifecycle mgmt of
> these DREs
> > > > should be the responsibility of CXF. Fair enough, the
> DRE shutdown
> > > > isn't done properly currently, but it would be a tractable
> > > problem to
> > > > do so, by virtue of the cardinality being limited to
> > > one-per-Conduit.
> > > > My whole point was that we shouldn't move to a scenario
> where for
> > > > example the application setting a replyTo on an
> > > AddressingProperties
> > > > instance set in request context would cause CXF to
> > > automatically launch a new listener.
> > > > The problem here of course is that allowing a
> per-request setting
> > > > would facilitate the application causing many listeners to
> > > be created
> > > > by CXF, without a good way for the CXF runtime to know
> when these
> > > > should be shutdown. I take it from your comments in more
> > > recent mails
> > > > on this thread that this is not the sort of mechanism
> > > you're looking
> > > > for, correct?
> > >
> > >
> > > I just want to do :
> > >
> > > Client c = ...
> > > c.setDecoupledEndpoint(myEPR);
> > > c.invoke(...);
> > > c.close();
> >
> >
> > How about this instead:
> >
> > Client c = ...
> > c.getPolicy(ConduitPolicy.class).setDecoupledEndpoint(myEPR);
> > c.invoke(...);
> > c.close();
> >
> > From the point-of-view of the application, both approaches look and
> > smell very similar.
> >
> > Then internally, we'd implement the Client.getPolicy() API something
> > like:
> >
> > public <T> T getPolicy(Class<T> type) {
> > return
> > endpoint.getEndpointInfo().getTraversedExtensor(type.newInstance(),
> > type);
> > }
> >
> > ... ensuring that getTraversedExtensor() caches up the
> policy instance
> > so that its available to the Conduit when its first created
> during the
> > message dispatch.
>
>
> I still don't see why all these gymnastics are necessary.
By gymnastics, do you mean
"c.getPolicy(ConduitPolicy.class).setDecoupledEndpoint(myEPR)" versus
"c.setDecoupledEndpoint(myEPR)"?
Its only one extra API call for the app to make. Hardly a quantum leap
in terms of complexity.
Cheers,
Eoghan
Re: Client API, EPRs
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 3/15/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
> >
> >
> > -1: as I stated in my other email, there isn't any reason to
> > put the DRE inside the conduit.
> >
> > It is much more straightforward to put the Destination on the
> > Client and and have the Client shutdown both the Conduit &
> > DRE. Its completely unncessary to introduce yet more
> > complexity into our transport APIs for this.
>
>
> Obviously my -1 to your -1 :)
>
> It's a separation of concerns thing. The DRE is IMO an aspect of the
> transport. Thus it is best managed within the realm of the transport.
>
> It's also an existence issue. First we're not guaranteed to even have a
> Client instance. Apart from the JAX-WS Dispatch example, which fair
> enough could might someday be rebased on the Client (though the return
> value handling is a bit different, a List in the Client's case, but a
> single Object of type Source or SOAPMessage for the Dispatch). But do we
> really want to _require_ that a Client is always used? Suppose the app
> just wants to throw together some special-purpose interceptor chain and
> kick off the dispatch directly itself. Do we want to disallow this
> approach, or force the app to directly manage the DRE itself in that
> case?
Is that hard for them to do a destinationFactory.getDestination(epr)? I
don't think so. WS-Addressing interceptors will still work fine even though
there is no client. Its the same case as if they wanted a different FaultTo
or AcksTo.
If they wanted, they could even create a DecoupledConduit class which
transparently manages the underlying Conduit & Destination. But this logic
shouldn't be in the normal low level conduits though.
And related to both the existence argument and SoC, I'm thinking we may
> not even need a Conduit instance at all when mediating an invocation. An
> example would be an optimized form of dispatch where a client-side
> interceptor can short-circuit out the whole marshalling/transport thing
> and instead handle the request directly. So creating the Conduit from
> Client.invoke() seems premature. Which leads me to think that the idea
> of the MessageSenderInterceptor creating the conduit, that you proposed
> in another with discussion with Polar as an alternate way of handling
> the Message.ENDPOINT_ADDRESS override, may in fact be the proper way to
> go in *all* cases (if the ConduitInitiator.getConduit() were to take
> responsibility for caching pre-existing Conduits with the same
> EndpointInfo & target).
Are you saying you just want to pass of the request object or whatever to
something else and avoid the any kind of serialization or transport? That is
completely possible right now. Just make a Conduit which understands
Message.getContent(Object.class) and write an ObjectBinding which doesn't do
any databinding. The APIs were made to handle *any* representation and if
they can't handle one we should be changing those APIs instead of trying to
make Conduits optional. I'm strongly against removing the Conduit off the
client. Its really handy for manipulating the Conduit's configuration,
providing a different Conduit or the like.
But if there's a DRE involved, then there's also necessarily a Conduit,
> as we've agreed that the decoupled transport must be the same as the
> outgoing.
>
> To summarize:
> A) An invocation doesn't imply the existence of Client
Not that hard to set up a response destination .
B) A Client shouldn't IMO imply the existence of a Conduit
IMO a Client should always have a Conduit.
C) A DRE does imply the existence of a Conduit
Sure, but that doesn't mean it should be in the Conduit :-)
This seems to me a complete logical justification for referencing the
> DRE from the Conduit.
I disagree. :-)
And we could actually go one step further than what's currently there
> and completely decouple the Client from any direct interaction with the
> transport, by removing the reference even to the Conduit, and setting
> this up from the MessageSenderInterceptor instead.
No need to.
> 3. My main issue was to avoid a proliferation of
> > automatically launched
> > > DREs, as the responsibility for the lifecycle mgmt of these DREs
> > > should be the responsibility of CXF. Fair enough, the DRE shutdown
> > > isn't done properly currently, but it would be a tractable
> > problem to
> > > do so, by virtue of the cardinality being limited to
> > one-per-Conduit.
> > > My whole point was that we shouldn't move to a scenario where for
> > > example the application setting a replyTo on an
> > AddressingProperties
> > > instance set in request context would cause CXF to
> > automatically launch a new listener.
> > > The problem here of course is that allowing a per-request setting
> > > would facilitate the application causing many listeners to
> > be created
> > > by CXF, without a good way for the CXF runtime to know when these
> > > should be shutdown. I take it from your comments in more
> > recent mails
> > > on this thread that this is not the sort of mechanism
> > you're looking
> > > for, correct?
> >
> >
> > I just want to do :
> >
> > Client c = ...
> > c.setDecoupledEndpoint(myEPR);
> > c.invoke(...);
> > c.close();
>
>
> How about this instead:
>
> Client c = ...
> c.getPolicy(ConduitPolicy.class).setDecoupledEndpoint(myEPR);
> c.invoke(...);
> c.close();
>
> From the point-of-view of the application, both approaches look and
> smell very similar.
>
> Then internally, we'd implement the Client.getPolicy() API something
> like:
>
> public <T> T getPolicy(Class<T> type) {
> return
> endpoint.getEndpointInfo().getTraversedExtensor(type.newInstance(),
> type);
> }
>
> ... ensuring that getTraversedExtensor() caches up the policy instance
> so that its available to the Conduit when its first created during the
> message dispatch.
I still don't see why all these gymnastics are necessary.
>
> Agreed on getDestination() caching and return a preexisting one if poss.
>
> Similarly for ConduitInitiator.getConduit() as I suggest above.
>
Cool.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Client API, EPRs
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 15 March 2007 21:12
> To: cxf-dev@incubator.apache.org
> Subject: Re: Client API, EPRs
>
> On 3/15/07, Glynn, Eoghan <eo...@iona.com> wrote:
> >
> >
> >
> > Dan,
> >
> > There are a bunch of orthogonal issues becoming conflated in this
> > discussion.
> >
> > So I'm going to take a step back and try disentangling the
> following:
> >
> > 1. transport-specific versus generic mechanism to set the decoupled
> > response endpoint (DRE)
> >
> > 2. policy-driven (either specified via XML config or
> programmatically)
> > versus some other API to set the DRE
> >
> > 3. cardinality of the DRE, i.e. one-per-something (Conduit
> or Client),
> > or unlimited
> >
> > 4. association of the DRE with the Conduit or the Client instance
> >
> > 5. lifecycle mgmt of the DRE, or how to trigger a shutdown
> >
> > 6. explicit application creation and shutdown of DREs
> >
> >
> > Dealing with each issue in turn, here's my position:
> >
> > 1. If its claimed a proposed new mechanism for setting the DRE is
> > superior to the existing mechanism by virtue of its
> genericity, then I
> > don't think its unreasonable to expect it be really generic, as
> > opposed to sortta generic except for 'edge-case'
> transports. If some
> > transport specifics are required, lets at least try to
> dove-tail these
> > with the general mechanism as neatly as possible.
>
>
> I would propose just letting users set an EPR and then
> resurrecting DestinationFactory.getDestination(EPR). In this
> case its up to the transport to understand the EPR. Its a
> generic mechanism. JMS may not work right away, but we can
> make it work eventually.
>
> If you have any other ideas feel free to share them.
Well I've already shared my ideas, see point #2 of my last mail.
> 2. Since we already control transports via policies specified
> either in
> > XML config or programmatically, then for consistency it makes sense
> > IMO to stick with this model. We could genericize the
> policy by moving
> > the DecoupledEndpoint attribute to a new ConduitPolicy and
> having the
> > existing HTTPClientPolicy pick it up from there by type extension.
> > Other transports would also extend ConduitPolicy with their
> own client
> > policy type if necessary and could I guess add any additional info
> > they need (thus neatly solving the JMS issue). The generic
> > ConduitPolicy could be exposed via the AbstractConduit. Then
> > programmatic approach (as used for example in the RM
> SequenceTest) could then also become generic (i.e.
> > call AbstractConduit.getConduitPolicy() as opposed to
> > HTTPConduit.getClient() to get a hold of the policy object).
>
>
> -1: as I stated in my other email, there isn't any reason to
> put the DRE inside the conduit.
>
> It is much more straightforward to put the Destination on the
> Client and and have the Client shutdown both the Conduit &
> DRE. Its completely unncessary to introduce yet more
> complexity into our transport APIs for this.
Obviously my -1 to your -1 :)
It's a separation of concerns thing. The DRE is IMO an aspect of the
transport. Thus it is best managed within the realm of the transport.
It's also an existence issue. First we're not guaranteed to even have a
Client instance. Apart from the JAX-WS Dispatch example, which fair
enough could might someday be rebased on the Client (though the return
value handling is a bit different, a List in the Client's case, but a
single Object of type Source or SOAPMessage for the Dispatch). But do we
really want to _require_ that a Client is always used? Suppose the app
just wants to throw together some special-purpose interceptor chain and
kick off the dispatch directly itself. Do we want to disallow this
approach, or force the app to directly manage the DRE itself in that
case?
And related to both the existence argument and SoC, I'm thinking we may
not even need a Conduit instance at all when mediating an invocation. An
example would be an optimized form of dispatch where a client-side
interceptor can short-circuit out the whole marshalling/transport thing
and instead handle the request directly. So creating the Conduit from
Client.invoke() seems premature. Which leads me to think that the idea
of the MessageSenderInterceptor creating the conduit, that you proposed
in another with discussion with Polar as an alternate way of handling
the Message.ENDPOINT_ADDRESS override, may in fact be the proper way to
go in *all* cases (if the ConduitInitiator.getConduit() were to take
responsibility for caching pre-existing Conduits with the same
EndpointInfo & target).
But if there's a DRE involved, then there's also necessarily a Conduit,
as we've agreed that the decoupled transport must be the same as the
outgoing.
To summarize:
A) An invocation doesn't imply the existence of Client
B) A Client shouldn't IMO imply the existence of a Conduit
C) A DRE does imply the existence of a Conduit
This seems to me a complete logical justification for referencing the
DRE from the Conduit.
And we could actually go one step further than what's currently there
and completely decouple the Client from any direct interaction with the
transport, by removing the reference even to the Conduit, and setting
this up from the MessageSenderInterceptor instead.
To make this approach work, we'd probably also need some sort of scheme
whereby the Client.close() calls InterceptorChain.close() which
traverses the chain call Intercptor.close() on each. For the
MessageSenderInterceptor this would involve an interaction with the
ConduitInitiator to cause it to close the cached Conduit, if its not
also being used by some other Client.
> 3. My main issue was to avoid a proliferation of
> automatically launched
> > DREs, as the responsibility for the lifecycle mgmt of these DREs
> > should be the responsibility of CXF. Fair enough, the DRE shutdown
> > isn't done properly currently, but it would be a tractable
> problem to
> > do so, by virtue of the cardinality being limited to
> one-per-Conduit.
> > My whole point was that we shouldn't move to a scenario where for
> > example the application setting a replyTo on an
> AddressingProperties
> > instance set in request context would cause CXF to
> automatically launch a new listener.
> > The problem here of course is that allowing a per-request setting
> > would facilitate the application causing many listeners to
> be created
> > by CXF, without a good way for the CXF runtime to know when these
> > should be shutdown. I take it from your comments in more
> recent mails
> > on this thread that this is not the sort of mechanism
> you're looking
> > for, correct?
>
>
> I just want to do :
>
> Client c = ...
> c.setDecoupledEndpoint(myEPR);
> c.invoke(...);
> c.close();
How about this instead:
Client c = ...
c.getPolicy(ConduitPolicy.class).setDecoupledEndpoint(myEPR);
c.invoke(...);
c.close();
>From the point-of-view of the application, both approaches look and
smell very similar.
Then internally, we'd implement the Client.getPolicy() API something
like:
public <T> T getPolicy(Class<T> type) {
return
endpoint.getEndpointInfo().getTraversedExtensor(type.newInstance(),
type);
}
... ensuring that getTraversedExtensor() caches up the policy instance
so that its available to the Conduit when its first created during the
message dispatch.
> (I'm not 100% sure that it should setDecoupledEndpoint. Other
> options are setAsynchronousEndpoint or setReplyTo)
>
> Also, I would like to be able to do:
>
> Client c = ...
> c.setDestination(myDestination);
> c.invoke(...);
> c.close();
>
> I don't think it makes sense to have two ways to specify a
> decoupled endpoint (i.e. one hidden inside the Conduit and
> one in which the destination is looked up).
>
> 4. I would favour continuing to associate the DRE with the Conduit as
> > opposed to the Client, because a) the DRE is
> transport-level concern
> > IMO
>
>
> I disagree. Transports (i.e. Conduits) are a tool to do
> decoupled interactions.
Sure, Conduits are a tool to do remote interactions.
But as I pointed out above, neither a Conduit (nor a decoupled
Destination) is necessarily required for an invocation to occur. Hence
the question of whether either of these should be referenced from the
Client.
> Putting the DRE inside the conduit results in
> a) API complexity. Moving the destination outside of the
> conduit makes it more straightforward to write Conduits and
> also easier to specify DREs for interactions. You also need
> to introduce even more complexity by adding the ConduitPolicy class.
> b) Inconsistency - If people have to set up a Destination
> manually when they use per-request addressing settings, I
> don't see why we should have a different API for setting up
> decoupled destinations when you're setting up a DRE for the
> life time of a Client.
>
> and b) there may not even be a Client instance involved in
> mediating the
> > invocation (e.g. when using the JAX-WS Dispatch mechanism).
>
>
> The JAX-WS Dispatch should be using the Client. I have an
> open JIRA for this I thought... (I fixed the Provider side of
> things but ran out of time on the Dispatch end)
Pity there's no big "generate code" button in JIRA :)
> 5. The lifecycle management is much easier to deal with if the
> > cardinality is limited as per #3. As I said before I'm
> happy with your
> > suggested explicit Client.close() API (which would presumably call
> > down to Conduit.close()).
>
>
> +1 to limiting it to per Client. If people are doing something more
> +complex
> they get to manage it themselves.
>
> 6. The application should IMO be free to set a replyTo for a DRE *not*
> > created by CXF, for example if that DRE is controlled by the some
> > third party, or if the application explicitly calls
> > DestinationFactory.getDestination() itself and is prepared
> to handle
> > the shutdown when its done. Not sure if your comment "I'm
> -1 to having
> > two mechanisms to do the same exact same thing" indicates
> disagreement
> > on this point(?)
> >
> >
> I agree we should add a mechanism to tell CXF not to create a
> decoupled endpoint. The best thing would be if CXF could see
> that the user specified their own destination:
>
> Client client = ...;
> client.setDestination(myDestination);
>
> In this case they wouldn't have to set an EPR, it could just
> figure out the EPR from Destination.getAddress();
>
> Also, If I specify an EPR and a Destination already exists
> for that EPR, CXF should be able to just use that.
> DestinationFactorys aren't holding on to the Destinations
> they create which I think is bad. If they do hold on to them,
> when I call getDestination() it should just reuse the one
> that is already there.
Agreed on getDestination() caching and return a preexisting one if poss.
Similarly for ConduitInitiator.getConduit() as I suggest above.
/Eoghan
Re: Client API, EPRs
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 3/15/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
>
> Dan,
>
> There are a bunch of orthogonal issues becoming conflated in this
> discussion.
>
> So I'm going to take a step back and try disentangling the following:
>
> 1. transport-specific versus generic mechanism to set the decoupled
> response endpoint (DRE)
>
> 2. policy-driven (either specified via XML config or programmatically)
> versus some other API to set the DRE
>
> 3. cardinality of the DRE, i.e. one-per-something (Conduit or Client),
> or unlimited
>
> 4. association of the DRE with the Conduit or the Client instance
>
> 5. lifecycle mgmt of the DRE, or how to trigger a shutdown
>
> 6. explicit application creation and shutdown of DREs
>
>
> Dealing with each issue in turn, here's my position:
>
> 1. If its claimed a proposed new mechanism for setting the DRE is
> superior to the existing mechanism by virtue of its genericity, then I
> don't think its unreasonable to expect it be really generic, as opposed
> to sortta generic except for 'edge-case' transports. If some transport
> specifics are required, lets at least try to dove-tail these with the
> general mechanism as neatly as possible.
I would propose just letting users set an EPR and then resurrecting
DestinationFactory.getDestination(EPR). In this case its up to the transport
to understand the EPR. Its a generic mechanism. JMS may not work right away,
but we can make it work eventually.
If you have any other ideas feel free to share them.
2. Since we already control transports via policies specified either in
> XML config or programmatically, then for consistency it makes sense IMO
> to stick with this model. We could genericize the policy by moving the
> DecoupledEndpoint attribute to a new ConduitPolicy and having the
> existing HTTPClientPolicy pick it up from there by type extension. Other
> transports would also extend ConduitPolicy with their own client policy
> type if necessary and could I guess add any additional info they need
> (thus neatly solving the JMS issue). The generic ConduitPolicy could be
> exposed via the AbstractConduit. Then programmatic approach (as used for
> example in the RM SequenceTest) could then also become generic (i.e.
> call AbstractConduit.getConduitPolicy() as opposed to
> HTTPConduit.getClient() to get a hold of the policy object).
-1: as I stated in my other email, there isn't any reason to put the DRE
inside the conduit.
It is much more straightforward to put the Destination on the Client and and
have the Client shutdown both the Conduit & DRE. Its completely unncessary
to introduce yet more complexity into our transport APIs for this.
3. My main issue was to avoid a proliferation of automatically launched
> DREs, as the responsibility for the lifecycle mgmt of these DREs should
> be the responsibility of CXF. Fair enough, the DRE shutdown isn't done
> properly currently, but it would be a tractable problem to do so, by
> virtue of the cardinality being limited to one-per-Conduit. My whole
> point was that we shouldn't move to a scenario where for example the
> application setting a replyTo on an AddressingProperties instance set in
> request context would cause CXF to automatically launch a new listener.
> The problem here of course is that allowing a per-request setting would
> facilitate the application causing many listeners to be created by CXF,
> without a good way for the CXF runtime to know when these should be
> shutdown. I take it from your comments in more recent mails on this
> thread that this is not the sort of mechanism you're looking for,
> correct?
I just want to do :
Client c = ...
c.setDecoupledEndpoint(myEPR);
c.invoke(...);
c.close();
(I'm not 100% sure that it should setDecoupledEndpoint. Other options are
setAsynchronousEndpoint or setReplyTo)
Also, I would like to be able to do:
Client c = ...
c.setDestination(myDestination);
c.invoke(...);
c.close();
I don't think it makes sense to have two ways to specify a decoupled
endpoint (i.e. one hidden inside the Conduit and one in which the
destination is looked up).
4. I would favour continuing to associate the DRE with the Conduit as
> opposed to the Client, because a) the DRE is transport-level concern IMO
I disagree. Transports (i.e. Conduits) are a tool to do decoupled
interactions.
Putting the DRE inside the conduit results in
a) API complexity. Moving the destination outside of the conduit makes it
more straightforward to write Conduits and also easier to specify DREs for
interactions. You also need to introduce even more complexity by adding the
ConduitPolicy class.
b) Inconsistency - If people have to set up a Destination manually when they
use per-request addressing settings, I don't see why we should have a
different API for setting up decoupled destinations when you're setting up a
DRE for the life time of a Client.
and b) there may not even be a Client instance involved in mediating the
> invocation (e.g. when using the JAX-WS Dispatch mechanism).
The JAX-WS Dispatch should be using the Client. I have an open JIRA for
this I thought... (I fixed the Provider side of things but ran out of time
on the Dispatch end)
5. The lifecycle management is much easier to deal with if the
> cardinality is limited as per #3. As I said before I'm happy with your
> suggested explicit Client.close() API (which would presumably call down
> to Conduit.close()).
+1 to limiting it to per Client. If people are doing something more complex
they get to manage it themselves.
6. The application should IMO be free to set a replyTo for a DRE *not*
> created by CXF, for example if that DRE is controlled by the some third
> party, or if the application explicitly calls
> DestinationFactory.getDestination() itself and is prepared to handle the
> shutdown when its done. Not sure if your comment "I'm -1 to having two
> mechanisms to do the same exact same thing" indicates disagreement on
> this point(?)
>
>
I agree we should add a mechanism to tell CXF not to create a decoupled
endpoint. The best thing would be if CXF could see that the user specified
their own destination:
Client client = ...;
client.setDestination(myDestination);
In this case they wouldn't have to set an EPR, it could just figure out the
EPR from Destination.getAddress();
Also, If I specify an EPR and a Destination already exists for that EPR, CXF
should be able to just use that. DestinationFactorys aren't holding on to
the Destinations they create which I think is bad. If they do hold on to
them, when I call getDestination() it should just reuse the one that is
already there. The destination can be released once shutdown() is called, so
there shouldn't be any lifecycle concerns.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Client API, EPRs
Posted by "Glynn, Eoghan" <eo...@iona.com>.
Dan,
There are a bunch of orthogonal issues becoming conflated in this
discussion.
So I'm going to take a step back and try disentangling the following:
1. transport-specific versus generic mechanism to set the decoupled
response endpoint (DRE)
2. policy-driven (either specified via XML config or programmatically)
versus some other API to set the DRE
3. cardinality of the DRE, i.e. one-per-something (Conduit or Client),
or unlimited
4. association of the DRE with the Conduit or the Client instance
5. lifecycle mgmt of the DRE, or how to trigger a shutdown
6. explicit application creation and shutdown of DREs
Dealing with each issue in turn, here's my position:
1. If its claimed a proposed new mechanism for setting the DRE is
superior to the existing mechanism by virtue of its genericity, then I
don't think its unreasonable to expect it be really generic, as opposed
to sortta generic except for 'edge-case' transports. If some transport
specifics are required, lets at least try to dove-tail these with the
general mechanism as neatly as possible.
2. Since we already control transports via policies specified either in
XML config or programmatically, then for consistency it makes sense IMO
to stick with this model. We could genericize the policy by moving the
DecoupledEndpoint attribute to a new ConduitPolicy and having the
existing HTTPClientPolicy pick it up from there by type extension. Other
transports would also extend ConduitPolicy with their own client policy
type if necessary and could I guess add any additional info they need
(thus neatly solving the JMS issue). The generic ConduitPolicy could be
exposed via the AbstractConduit. Then programmatic approach (as used for
example in the RM SequenceTest) could then also become generic (i.e.
call AbstractConduit.getConduitPolicy() as opposed to
HTTPConduit.getClient() to get a hold of the policy object).
3. My main issue was to avoid a proliferation of automatically launched
DREs, as the responsibility for the lifecycle mgmt of these DREs should
be the responsibility of CXF. Fair enough, the DRE shutdown isn't done
properly currently, but it would be a tractable problem to do so, by
virtue of the cardinality being limited to one-per-Conduit. My whole
point was that we shouldn't move to a scenario where for example the
application setting a replyTo on an AddressingProperties instance set in
request context would cause CXF to automatically launch a new listener.
The problem here of course is that allowing a per-request setting would
facilitate the application causing many listeners to be created by CXF,
without a good way for the CXF runtime to know when these should be
shutdown. I take it from your comments in more recent mails on this
thread that this is not the sort of mechanism you're looking for,
correct?
4. I would favour continuing to associate the DRE with the Conduit as
opposed to the Client, because a) the DRE is transport-level concern IMO
and b) there may not even be a Client instance involved in mediating the
invocation (e.g. when using the JAX-WS Dispatch mechanism).
5. The lifecycle management is much easier to deal with if the
cardinality is limited as per #3. As I said before I'm happy with your
suggested explicit Client.close() API (which would presumably call down
to Conduit.close()).
6. The application should IMO be free to set a replyTo for a DRE *not*
created by CXF, for example if that DRE is controlled by the some third
party, or if the application explicitly calls
DestinationFactory.getDestination() itself and is prepared to handle the
shutdown when its done. Not sure if your comment "I'm -1 to having two
mechanisms to do the same exact same thing" indicates disagreement on
this point(?)
/Eoghan
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 15 March 2007 14:34
> To: cxf-dev@incubator.apache.org
> Subject: Re: Client API, EPRs
>
> On 3/14/07, Glynn, Eoghan <eo...@iona.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > We still need to support it at some level of course. And in the
> > > future we can support it at the EPR level too. What is so
> bad about
> > > that?
> > >
> > >
> > > > And as I stated, that would seem to defeat the purpose.
> > >
> > >
> > > For this single case. And in the future this single case probably
> > > won't be valid. So your objection here really doesn't carry much
> > > weight.
> >
> >
> > Well, I beg to differ ... you're motivating your proposal as a
> > mechanism that would be *consistent across transports*.
> >
> > Its not logical IMO to then turn around and disregard one transport
> > that the (supposedly standard) mechanism wouldn't work for.
>
>
> By your same logic it wouldn't make any sense to create the
> JAX-WS standard.
> The JAX-WS Handler APIs don't provide enough extension points
> for everyone to do everything they would want to do with
> messages (like work at the stream level). Yet, that doesn't
> mean that a standard isn't useful. And it doesn't mean that
> the standard can't be improved on in the future to
> accommodate future use cases. Standards almost always don't
> meet everyone's needs.
>
> You could also claim the same thing about the WS-Addressing
> standard because it doesn't offer a standard way to address
> JMS endpoints. These things will be addressed in time though,
> and for now there are proprietary extensions to handle such
> cases. It still works great for HTTP, TCP, XMPP, SMTP, etc though.
>
>
> > > I'm fine with limiting automatic launching to be per-Client.
> >
> >
> > Great as that's my main issue, i.e. to avoid a proliferation of
> > automatically launched decoupled endpoints.
>
>
> I was never asking for anything other than that.
>
> >
> > > > Instead the idea in the original Celtix code was to use a
> > > > reference counting scheme for the decoupled response
> endpoint, and
> > > > to
> > > allow this
> > > > to be shared across client transport instances. This was simply
> > > > not ported over properly to CXF.
> > > >
> > > > The original scheme worked as the HTTPClientTransport was
> > > created once
> > > > per binding instance, had well-defined shutdown semantics,
> > > and reused if
> > > > possible a pre-existing listener for the decoupled
> endpoint, even
> > > > if this was created from another HTTPClientTransport. This
> > > reuse was easy
> > > > to do as HTTPClientTransport registered the Jetty handler
> > > > directly, instead of going thru' the
> DestinationFactory, and thus
> > > > could easily check if a pre-existing handler was
> already registered.
> > >
> > >
> > > I don't see how this gets around the issues I mentioned
> in (a). It
> > > sounds like the deocupled destination would stick around
> until you
> > > shut down the HTTPClientTransport. And there is no way to
> > > automagically shut down the client transport really.
> >
> >
> > But you're proposing an explicit Client.close() API to
> handle this, no?
>
>
> That is an option on the table.
>
> My point is that you're claim that this introduces a whole
> bunch of lifcycle issues is wrong. *These lifecycle issues
> were here before.* They have absolutely nothing to do whether
> or not the endpoint is automatically launched by the client
> or by configuration.
>
> > > > This brings up an interesting point: Currently I can only
> > > > > associate a decoupled destination with a client's
> conduit AFAIK.
> > > > > But this makes absolutely no sense to me - there are many
> > > > > decoupled destinations that could be associated with
> a client.
> > > > > For instance it might have a different acksTo then
> ReplyTo. Or I
> > > > > might have a different FaultTo.
> > > >
> > > >
> > > > I don't think you're correct here. If I go and
> explicitly set the
> > > > replyTo to a Destination that I've created (via a
> > > DestinationFactory)
> > > > then this will be used for the <wsa:ReplyTo> in the
> > > outgoing message, as
> > > > opposed to the back-channel destination overwriting the
> explicit
> > > > setting.
> > > >
> > > > Similarly the acksTo could be set to any Destination,
> but RM just
> > > > happens to be implemented to use the back-channel
> destination for
> > > > convenience. By convenience, I mean it avoids the RM layer
> > > having to set
> > > > up a separate in-interceptor-chain to handle incoming
> out-of-band
> > > > messages.
> > > >
> > > > The per-Conduit restriction only applies to *automatically
> > > > launched* decoupled response endpoints. The application can go
> > > > nuts explicitly creating response endpoints all over
> town if it wants ...
> > > >
> > >
> > > First, I was talking about from a configuration point of view.
> > >
> > > Second, doesn't this kind of defeat the point of having the
> > > decoupled destination in the conduit?
> >
> >
> > Nope I don't think it defeats the point.
> >
> > The point being that the lifecycle of any automatically launched
> > decoupled endpoint is the *responsibility of the CXF
> runtime*, whereas
> > the lifecycle of any Destinations explicitly launched by the
> > application is of course the *responsibility of the
> application itself*.
>
>
> The application developer has to be aware of the lifecycle
> regardless (as you seem to admit when saying the user will
> need to call Client.close() below). It could be creating new
> clients every so often on different ports in which case it
> would still quickly exhaust its resources. Limiting the
> cardinality, as you say below, doesn't prevent that.
>
> If we limit the cardinality of the automatically launched decoupled
> > endpoint to one-per-Conduit (equivalently, one-per-Client), then we
> > have a well-defined point at which it makes sense to close
> the endpoint (i.e.
> > when the Conduit is closed, as a side-effect of your proposed new
> > Client.close() API).
>
>
> Sure thats true, BUT it would be equally easy to close the
> decoupled endpoint if it wasn't part of the Conduit. It is
> very easy for the client to call destination.close() in
> addition to conduit.close() when the Client itself is closed.
>
> In this case the cardinality of the automatically launched
> decoupled endpoint would be one per Client.
>
> If we do not limit the cardinality of the automatically launched
> > decoupled endpoints, then we'd have to either let these accumulated
> > endpoints remain active until either the Client is close()d or the
> > application exit()s, or we'd have to guess when it would
> make sense to
> > shutdown a seemingly inactive decoupled endpoint. But this
> guesswork
> > is problematic, as the decoupled endpoint could have been
> specified as
> > the acksTo for some RM sequences. It would be invalid for
> example to
> > take the approach ... hey there's no outstanding MEPs for
> which this
> > endpoint was specified as the replyTo so lets just shut it down.
> > Obviously that would pull the rug out from under RM, which
> may receive
> > any number of incoming out-of-band messages on that
> endpoint until the
> > sequence is terminated, and AFAIK by default we to allow
> the sequence
> > to proceed indefinitely rather than actively terminating
> and starting
> > up a new one every N messages or whatever.
> >
>
>
> I agree that we shouldn't just go willy nilly launching
> deocupled endpoints on every request. But it doesn't follow
> that the response Destination should be part of the Conduit from that.
>
> On the other hand, if the application wants to make many
> invocations on
> > a single Client, each with a different replyTo, then its welcome to
> > set up the relevant Destinations itself and then explicit
> shutdown()
> > when its done with each. The app knowing the appropriate
> point for the
> > shutdown to occur is the crucial point.
> >
>
>
> I'm -1 to having two mechanisms to do the same exact same thing.
>
> - Dan
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
Re: Client API, EPRs
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 3/14/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
>
> > -----Original Message-----
> > We still need to support it at some level of course. And in
> > the future we can support it at the EPR level too. What is so
> > bad about that?
> >
> >
> > > And as I stated, that would seem to defeat the purpose.
> >
> >
> > For this single case. And in the future this single case
> > probably won't be valid. So your objection here really
> > doesn't carry much weight.
>
>
> Well, I beg to differ ... you're motivating your proposal as a mechanism
> that would be *consistent across transports*.
>
> Its not logical IMO to then turn around and disregard one transport that
> the (supposedly standard) mechanism wouldn't work for.
By your same logic it wouldn't make any sense to create the JAX-WS standard.
The JAX-WS Handler APIs don't provide enough extension points for everyone
to do everything they would want to do with messages (like work at the
stream level). Yet, that doesn't mean that a standard isn't useful. And it
doesn't mean that the standard can't be improved on in the future to
accommodate future use cases. Standards almost always don't meet everyone's
needs.
You could also claim the same thing about the WS-Addressing standard because
it doesn't offer a standard way to address JMS endpoints. These things will
be addressed in time though, and for now there are proprietary extensions to
handle such cases. It still works great for HTTP, TCP, XMPP, SMTP, etc
though.
> > I'm fine with limiting automatic launching to be per-Client.
>
>
> Great as that's my main issue, i.e. to avoid a proliferation of
> automatically launched decoupled endpoints.
I was never asking for anything other than that.
>
> > > Instead the idea in the original Celtix code was to use a reference
> > > counting scheme for the decoupled response endpoint, and to
> > allow this
> > > to be shared across client transport instances. This was simply not
> > > ported over properly to CXF.
> > >
> > > The original scheme worked as the HTTPClientTransport was
> > created once
> > > per binding instance, had well-defined shutdown semantics,
> > and reused if
> > > possible a pre-existing listener for the decoupled endpoint, even if
> > > this was created from another HTTPClientTransport. This
> > reuse was easy
> > > to do as HTTPClientTransport registered the Jetty handler directly,
> > > instead of going thru' the DestinationFactory, and thus could easily
> > > check if a pre-existing handler was already registered.
> >
> >
> > I don't see how this gets around the issues I mentioned in
> > (a). It sounds
> > like the deocupled destination would stick around until you
> > shut down the
> > HTTPClientTransport. And there is no way to automagically
> > shut down the
> > client transport really.
>
>
> But you're proposing an explicit Client.close() API to handle this, no?
That is an option on the table.
My point is that you're claim that this introduces a whole bunch of lifcycle
issues is wrong. *These lifecycle issues were here before.* They have
absolutely nothing to do whether or not the endpoint is automatically
launched by the client or by configuration.
> > > This brings up an interesting point: Currently I can only
> > > > associate a decoupled destination with a client's conduit
> > > > AFAIK. But this makes absolutely no sense to me - there are
> > > > many decoupled destinations that could be associated with a
> > > > client. For instance it might have a different acksTo then
> > > > ReplyTo. Or I might have a different FaultTo.
> > >
> > >
> > > I don't think you're correct here. If I go and explicitly set the
> > > replyTo to a Destination that I've created (via a
> > DestinationFactory)
> > > then this will be used for the <wsa:ReplyTo> in the
> > outgoing message, as
> > > opposed to the back-channel destination overwriting the explicit
> > > setting.
> > >
> > > Similarly the acksTo could be set to any Destination, but RM just
> > > happens to be implemented to use the back-channel destination for
> > > convenience. By convenience, I mean it avoids the RM layer
> > having to set
> > > up a separate in-interceptor-chain to handle incoming out-of-band
> > > messages.
> > >
> > > The per-Conduit restriction only applies to *automatically launched*
> > > decoupled response endpoints. The application can go nuts explicitly
> > > creating response endpoints all over town if it wants ...
> > >
> >
> > First, I was talking about from a configuration point of view.
> >
> > Second, doesn't this kind of defeat the point of having the decoupled
> > destination in the conduit?
>
>
> Nope I don't think it defeats the point.
>
> The point being that the lifecycle of any automatically launched
> decoupled endpoint is the *responsibility of the CXF runtime*, whereas
> the lifecycle of any Destinations explicitly launched by the application
> is of course the *responsibility of the application itself*.
The application developer has to be aware of the lifecycle regardless (as
you seem to admit when saying the user will need to call Client.close()
below). It could be creating new clients every so often on different ports
in which case it would still quickly exhaust its resources. Limiting the
cardinality, as you say below, doesn't prevent that.
If we limit the cardinality of the automatically launched decoupled
> endpoint to one-per-Conduit (equivalently, one-per-Client), then we have
> a well-defined point at which it makes sense to close the endpoint (i.e.
> when the Conduit is closed, as a side-effect of your proposed new
> Client.close() API).
Sure thats true, BUT it would be equally easy to close the decoupled
endpoint if it wasn't part of the Conduit. It is very easy for the client to
call destination.close() in addition to conduit.close() when the Client
itself is closed.
In this case the cardinality of the automatically launched decoupled
endpoint would be one per Client.
If we do not limit the cardinality of the automatically launched
> decoupled endpoints, then we'd have to either let these accumulated
> endpoints remain active until either the Client is close()d or the
> application exit()s, or we'd have to guess when it would make sense to
> shutdown a seemingly inactive decoupled endpoint. But this guesswork is
> problematic, as the decoupled endpoint could have been specified as the
> acksTo for some RM sequences. It would be invalid for example to take
> the approach ... hey there's no outstanding MEPs for which this endpoint
> was specified as the replyTo so lets just shut it down. Obviously that
> would pull the rug out from under RM, which may receive any number of
> incoming out-of-band messages on that endpoint until the sequence is
> terminated, and AFAIK by default we to allow the sequence to proceed
> indefinitely rather than actively terminating and starting up a new one
> every N messages or whatever.
>
I agree that we shouldn't just go willy nilly launching deocupled endpoints
on every request. But it doesn't follow that the response Destination should
be part of the Conduit from that.
On the other hand, if the application wants to make many invocations on
> a single Client, each with a different replyTo, then its welcome to set
> up the relevant Destinations itself and then explicit shutdown() when
> its done with each. The app knowing the appropriate point for the
> shutdown to occur is the crucial point.
>
I'm -1 to having two mechanisms to do the same exact same thing.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Client API, EPRs
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> We still need to support it at some level of course. And in
> the future we can support it at the EPR level too. What is so
> bad about that?
>
>
> > And as I stated, that would seem to defeat the purpose.
>
>
> For this single case. And in the future this single case
> probably won't be valid. So your objection here really
> doesn't carry much weight.
Well, I beg to differ ... you're motivating your proposal as a mechanism
that would be *consistent across transports*.
Its not logical IMO to then turn around and disregard one transport that
the (supposedly standard) mechanism wouldn't work for.
> > Seems a lot simpler to me to drive this from config, which we know
> > works for every transport.
> >
> > Actually, let me restate that ...
> >
> > It would seem simpler to drive this via policies, that may be taken
> > from static config files, or equivalently may be dynamically set by
> > the application. I believe Andrea is using the latter approach to
> > control the decoupled endpoint(s) used in system test she's writing.
> >
> > Maybe that would be a compromise that give the best of both worlds?
> >
> > I would like to maintain some cardinality restriction on the
> > (automatically launched) decoupled response endpoint, by keeping it
> > per-Conduit as opposed to per-request (for reasons of
> lifecycle mgmt
> > and non-proliferation as I explained earlier on this thread).
> >
> > But apart from that, I've no problem with the URI (or whatever the
> > transport needs) originating from the application code as
> opposed to
> > the cxf.xml.
>
>
> Can you be more specific about what you mean by policy
> driven? I looked through the RM code a bit, but I'm still not
> sure what you're referring to.
Look at the RM system test.
Specifically the last few lines of SequenceTest.setupGreeter().
> I'm fine with limiting automatic launching to be per-Client.
Great as that's my main issue, i.e. to avoid a proliferation of
automatically launched decoupled endpoints.
> And just to be incredibly clear, I'm specifically trying to
> get away from the xml approach and make complete control of
> the endpoints easy when using the Client API.
>
> >
> > > I think you're oversimplifying the issue. Either you're trying to:
> > > a) count the number of clients which are actively invoking.
> > > In which case when I stop sending and then resume a minute later
> > > you're going to have to start it all over again, which
> wouldn't make
> > > a lot of sense. Especially in a single thread scenario as
> it would
> > > be starting & stopping a server during each invocation.
> > >
> > > b) Implement a timeout mechanism. In which case it would work
> > > equally well when setting a reply-to EPR on a Client.
> > >
> > > c) Implement a refcount & timeout mechanism. i.e. if I
> call close on
> > > my conduit, but another client still has the same decoupled
> > > server/port open we would obviously want it to stay up.
> Which once
> > > again works equally well when setting a reply to EPR on
> the client.
> > >
> > > d) Trying to call Conduit.close() when the client is
> being GC'd. But
> > > there is no sure way to do this Java. Even if you could,
> this would
> > > once again work equally as well when setting an EPR on the Client.
> >
> >
> > There's no question of what's there being an attempt to be
> timeout-based
> > or reliant on GC.
> >
> > Instead the idea in the original Celtix code was to use a reference
> > counting scheme for the decoupled response endpoint, and to
> allow this
> > to be shared across client transport instances. This was simply not
> > ported over properly to CXF.
> >
> > The original scheme worked as the HTTPClientTransport was
> created once
> > per binding instance, had well-defined shutdown semantics,
> and reused if
> > possible a pre-existing listener for the decoupled endpoint, even if
> > this was created from another HTTPClientTransport. This
> reuse was easy
> > to do as HTTPClientTransport registered the Jetty handler directly,
> > instead of going thru' the DestinationFactory, and thus could easily
> > check if a pre-existing handler was already registered.
>
>
> I don't see how this gets around the issues I mentioned in
> (a). It sounds
> like the deocupled destination would stick around until you
> shut down the
> HTTPClientTransport. And there is no way to automagically
> shut down the
> client transport really.
But you're proposing an explicit Client.close() API to handle this, no?
> > > This brings up an interesting point: Currently I can only
> > > associate a decoupled destination with a client's conduit
> > > AFAIK. But this makes absolutely no sense to me - there are
> > > many decoupled destinations that could be associated with a
> > > client. For instance it might have a different acksTo then
> > > ReplyTo. Or I might have a different FaultTo.
> >
> >
> > I don't think you're correct here. If I go and explicitly set the
> > replyTo to a Destination that I've created (via a
> DestinationFactory)
> > then this will be used for the <wsa:ReplyTo> in the
> outgoing message, as
> > opposed to the back-channel destination overwriting the explicit
> > setting.
> >
> > Similarly the acksTo could be set to any Destination, but RM just
> > happens to be implemented to use the back-channel destination for
> > convenience. By convenience, I mean it avoids the RM layer
> having to set
> > up a separate in-interceptor-chain to handle incoming out-of-band
> > messages.
> >
> > The per-Conduit restriction only applies to *automatically launched*
> > decoupled response endpoints. The application can go nuts explicitly
> > creating response endpoints all over town if it wants ...
> >
>
> First, I was talking about from a configuration point of view.
>
> Second, doesn't this kind of defeat the point of having the decoupled
> destination in the conduit?
Nope I don't think it defeats the point.
The point being that the lifecycle of any automatically launched
decoupled endpoint is the *responsibility of the CXF runtime*, whereas
the lifecycle of any Destinations explicitly launched by the application
is of course the *responsibility of the application itself*.
If we limit the cardinality of the automatically launched decoupled
endpoint to one-per-Conduit (equivalently, one-per-Client), then we have
a well-defined point at which it makes sense to close the endpoint (i.e.
when the Conduit is closed, as a side-effect of your proposed new
Client.close() API).
If we do not limit the cardinality of the automatically launched
decoupled endpoints, then we'd have to either let these accumulated
endpoints remain active until either the Client is close()d or the
application exit()s, or we'd have to guess when it would make sense to
shutdown a seemingly inactive decoupled endpoint. But this guesswork is
problematic, as the decoupled endpoint could have been specified as the
acksTo for some RM sequences. It would be invalid for example to take
the approach ... hey there's no outstanding MEPs for which this endpoint
was specified as the replyTo so lets just shut it down. Obviously that
would pull the rug out from under RM, which may receive any number of
incoming out-of-band messages on that endpoint until the sequence is
terminated, and AFAIK by default we to allow the sequence to proceed
indefinitely rather than actively terminating and starting up a new one
every N messages or whatever.
On the other hand, if the application wants to make many invocations on
a single Client, each with a different replyTo, then its welcome to set
up the relevant Destinations itself and then explicit shutdown() when
its done with each. The app knowing the appropriate point for the
shutdown to occur is the crucial point.
/Eoghan
Re: Client API, EPRs
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 3/13/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
> *snip*
>
> Sure JMS is different, but that doesn't make it an edge-case that we can
> disregard.
We still need to support it at some level of course. And in the future we
can support it at the EPR level too. What is so bad about that?
> And as I stated, that would seem to defeat the purpose.
For this single case. And in the future this single case probably won't be
valid. So your objection here really doesn't carry much weight.
> > Third, when the
> > > > decoupled destination is being set up it can still pull
> > > > configuration from xml files if people need to add extra
> > > > configuration info.
> > >
> > >
> > > Wouldn't that defeat your stated purpose? (i.e. not having to do
> > > transport-specific config)
> >
> >
> > Yes, I was simply stating this is a possibility if the user
> > needed to fall back to it. Hopefully they wouldn't need to.
>
>
> Seems a lot simpler to me to drive this from config, which we know works
> for every transport.
>
> Actually, let me restate that ...
>
> It would seem simpler to drive this via policies, that may be taken from
> static config files, or equivalently may be dynamically set by the
> application. I believe Andrea is using the latter approach to control
> the decoupled endpoint(s) used in system test she's writing.
>
> Maybe that would be a compromise that give the best of both worlds?
>
> I would like to maintain some cardinality restriction on the
> (automatically launched) decoupled response endpoint, by keeping it
> per-Conduit as opposed to per-request (for reasons of lifecycle mgmt and
> non-proliferation as I explained earlier on this thread).
>
> But apart from that, I've no problem with the URI (or whatever the
> transport needs) originating from the application code as opposed to the
> cxf.xml.
Can you be more specific about what you mean by policy driven? I looked
through the RM code a bit, but I'm still not sure what you're referring to.
I'm fine with limiting automatic launching to be per-Client.
And just to be incredibly clear, I'm specifically trying to get away from
the xml approach and make complete control of the endpoints easy when using
the Client API.
>
> > I think you're oversimplifying the issue. Either you're trying to:
> > a) count the number of clients which are actively invoking.
> > In which case when I stop sending and then resume a minute
> > later you're going to have to start it all over again, which
> > wouldn't make a lot of sense. Especially in a single thread
> > scenario as it would be starting & stopping a server during
> > each invocation.
> >
> > b) Implement a timeout mechanism. In which case it would work
> > equally well when setting a reply-to EPR on a Client.
> >
> > c) Implement a refcount & timeout mechanism. i.e. if I call
> > close on my conduit, but another client still has the same
> > decoupled server/port open we would obviously want it to stay
> > up. Which once again works equally well when setting a reply
> > to EPR on the client.
> >
> > d) Trying to call Conduit.close() when the client is being
> > GC'd. But there is no sure way to do this Java. Even if you
> > could, this would once again work equally as well when
> > setting an EPR on the Client.
>
>
> There's no question of what's there being an attempt to be timeout-based
> or reliant on GC.
>
> Instead the idea in the original Celtix code was to use a reference
> counting scheme for the decoupled response endpoint, and to allow this
> to be shared across client transport instances. This was simply not
> ported over properly to CXF.
>
> The original scheme worked as the HTTPClientTransport was created once
> per binding instance, had well-defined shutdown semantics, and reused if
> possible a pre-existing listener for the decoupled endpoint, even if
> this was created from another HTTPClientTransport. This reuse was easy
> to do as HTTPClientTransport registered the Jetty handler directly,
> instead of going thru' the DestinationFactory, and thus could easily
> check if a pre-existing handler was already registered.
I don't see how this gets around the issues I mentioned in (a). It sounds
like the deocupled destination would stick around until you shut down the
HTTPClientTransport. And there is no way to automagically shut down the
client transport really.
> > Lets say I define a
> > > > replyTo endpoint in my cxf.xmlfile. Its not going to get
> > shut down
> > > > until I specifically shut it down myself or until I shut the
> > > > appserver down. So letting CXF create a destination automatically
> > > > would not really be any different. It just makes it
> > easier for the
> > > > user to set up the decoupled endpoint via the API. Once they are
> > > > done with the client they could call
> > > > Client.getDestination().shutdown()
> > > > and release any resources.
> > >
> > >
> > > I'm not sure it would be that simple.
> > >
> > > The user may have specified different decoupled destinations for a
> > > series of invocations mediated by the same Client instance.
> >
> >
> > So are we going let these accumulate and then have a
> > > close-all-in-one-fell-swoop type API on Client, say
> > > shutdownAllDestinations()?
> >
> >
> > This is an issue *regardless of how you are setting up the decoupled
> > destination.* The only way to auto-close them is to combine
> > it with a refcount/timeout mechanism like I outlined above or
> > to have the user explicitly close them (either on a per
> > request or client lifecycle basis).
> >
> > But that would have the effect of the client hogging
> > transport resources
> > > (e.g. HTTP ports or JMS Destinations) for much longer than
> > necessary,
> > > i.e. for the period after the client has stopped using these as the
> > > replyTo for requests, but before the corresponding JAX-WS proxy or
> > > whatever goes away.
> > >
> > > Also there's the issue of what WS-RM uses as its acksTo
> > address. AFAIK
> > > this is still just the decoupled endpoint associated with
> > the Conduit.
> > > However, it needs to continue to be available to receive
> > ACKs for the
> > > lifetime of the RM sequence. So we don't want the application to be
> > > able pull the rug out from under RM by specifying a
> > short-lived replyTo.
> >
> >
> > There are a couple ways to solve this:
> > - We can ref count the decoupled server endpoint. If the
> > client closed, there would still be an outstanding reference
> > to the server. So the server endpoint wouldn't close until RM
> > terminated its sequence and it called
> > close() on the decoupled destination.
> > - We could add extension points via a Client.close() API so
> > that RM could terminate the sequence and shut down the
> > decoupled destination when its called.
> >
> > This brings up an interesting point: Currently I can only
> > associate a decoupled destination with a client's conduit
> > AFAIK. But this makes absolutely no sense to me - there are
> > many decoupled destinations that could be associated with a
> > client. For instance it might have a different acksTo then
> > ReplyTo. Or I might have a different FaultTo.
>
>
> I don't think you're correct here. If I go and explicitly set the
> replyTo to a Destination that I've created (via a DestinationFactory)
> then this will be used for the <wsa:ReplyTo> in the outgoing message, as
> opposed to the back-channel destination overwriting the explicit
> setting.
>
> Similarly the acksTo could be set to any Destination, but RM just
> happens to be implemented to use the back-channel destination for
> convenience. By convenience, I mean it avoids the RM layer having to set
> up a separate in-interceptor-chain to handle incoming out-of-band
> messages.
>
> The per-Conduit restriction only applies to *automatically launched*
> decoupled response endpoints. The application can go nuts explicitly
> creating response endpoints all over town if it wants ...
>
First, I was talking about from a configuration point of view.
Second, doesn't this kind of defeat the point of having the decoupled
destination in the conduit?
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Client API, EPRs
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 12 March 2007 20:18
> To: cxf-dev@incubator.apache.org
> Subject: Re: Client API, EPRs
>
> On 3/12/07, Glynn, Eoghan <eo...@iona.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > > Sent: 11 March 2007 21:48
> > > To: cxf-dev@incubator.apache.org
> > > Subject: Re: Client API, EPRs
> > >
> > > Hola,
> > >
> > > Apologies for the lag here. Too much traveling going on
> and I wanted
> > > to spend some time thinking through this some more.
> > >
> > > Some comments inline.
> > >
> > > On 3/6/07, Glynn, Eoghan <eo...@iona.com> wrote:
> > > >
> > > >
> > > >
> > > > Hi Dan,
> > > >
> > > > Well if CXF is embedded in another product that *already*
> > > exposes an
> > > > endpoint (e.g. a HTTP listsner) from the client process space,
> > > > then CXF could use that to receive decoupled responses. All the
> > > app needs
> > > > to do is to provide an appropriate EPR via
> > > > AddressingProperties.setReplyTo (), set this on the request
> > > context,
> > > > and the CXF WS-A layer won't over-write this with any decoupled
> > > > response endpoint that may (or may not) have been
> > > configured on the Conduit.
> > > >
> > > > However, I don't think its reasonable to expect CXF to
> *actively*
> > > > launch a decoupled response endpoint on the basis of a
> replyTo EPR
> > > > provided by the application, for a number of reasons:
> > > >
> > > > 1. the replyTo EPR may not contain all the info that
> the transport
> > > > needs to initiate receipt of incoming messages, e.g.
> JMS may need
> > > > stuff like a username/password for the connection factory,
> > > maybe a JNDI provider etc.
> > > > This sort of transport-specific stuff may not be suitable for
> > > > shoe-horning into an EPR, and would probably need to be
> > > configured in
> > > > a transport-specific way.
> > >
> > >
> > > First, thats an edge case.
> >
> >
> > JMS is an edge-case?
>
>
> In the sense that:
> a) Most people use HTTP
> b) Soon we should have a mechanism to stuff all this stuff into an EPR
> c) There are other transports beside just JMS and HTTP, like
> XMPP or TCP or FTP which work just fine with URIs. JMS is the
> odd ball in the sense that historically it has needed stuff
> outside the EPR.
Sure JMS is different, but that doesn't make it an edge-case that we can
disregard.
Its only seems like an odd-ball because all the other transports are
connection-oriented URI-friendly protocols.
If we had more MOM-style transports in CXF, it would seem like less of
an exceptional case.
> > Second, people are defining
> > > standards to shoe-horn JMS info into IRIs.
> >
> >
> > Be that as it may, but as things currently stand, JMS needs
> more than
> > a URI.
>
>
> Whats your point?
My point is as stated ... right now JMS needs more than a URI,
regardless of any as yet incomplete standardization efforts.
> As I stated in point #3 if they absolutely
> needed to they could fall back to configuring a specific
> destination if they wanted via XML or the API.
And as I stated, that would seem to defeat the purpose.
> > Third, when the
> > > decoupled destination is being set up it can still pull
> > > configuration from xml files if people need to add extra
> > > configuration info.
> >
> >
> > Wouldn't that defeat your stated purpose? (i.e. not having to do
> > transport-specific config)
>
>
> Yes, I was simply stating this is a possibility if the user
> needed to fall back to it. Hopefully they wouldn't need to.
Seems a lot simpler to me to drive this from config, which we know works
for every transport.
Actually, let me restate that ...
It would seem simpler to drive this via policies, that may be taken from
static config files, or equivalently may be dynamically set by the
application. I believe Andrea is using the latter approach to control
the decoupled endpoint(s) used in system test she's writing.
Maybe that would be a compromise that give the best of both worlds?
I would like to maintain some cardinality restriction on the
(automatically launched) decoupled response endpoint, by keeping it
per-Conduit as opposed to per-request (for reasons of lifecycle mgmt and
non-proliferation as I explained earlier on this thread).
But apart from that, I've no problem with the URI (or whatever the
transport needs) originating from the application code as opposed to the
cxf.xml.
> > 2. there's no guarantee that the replyTo EPR specified by the
> > > app makes
> > > > any sense, e.g. it may be for a different transport to that
> > > used for
> > > > the outbound request (and we discussed the
> undesirability of mixed
> > > > transport within an MEP on this list a while back).
> > >
> > >
> > > We should add checks to ensure that this is sane & valid
> then. Its
> > > not that hard to ensure that the ReplyTo transport is the same as
> > > the outgoing one.
> > > We simply need to match up the transport IDs or the
> protocol part of
> > > the URL.
> > >
> > > 3. its hard to see how to manage the lifecycle of a
> listener created
> > > on
> > > > demand by CXF on foot of an application-provided replyTo.
> > > What if the
> > > > app specifies a different replyTo URI for each
> sucessive request,
> > > > maybe intending that the listener is a one-shot deal
> (i.e. is only
> > > > intended to accept a single decoupled response). There's no way
> > > > for the app to communicate this intended lifecycle with CXF, so
> > > > CXF wouldn't know when to shutdown the Destination.
> > > >
> > >
> > > Lets ignore the per request case a moment: How would this differ
> > > from how things currently are?
> >
> > Well the intention was that the decoupled endpoint is
> ref-counted, and
> > then shutdown when the last HTTPConduit referencing it is closed.
> >
> > However, looking at the code, this intention seems to be
> frustrated by
> > two factors:
> > - Conduit.close() is not being called anywhere
> > - the ref count has morphed into being non-static
> >
> > Gonna have to fix that ...
>
>
> I think you're oversimplifying the issue. Either you're trying to:
> a) count the number of clients which are actively invoking.
> In which case when I stop sending and then resume a minute
> later you're going to have to start it all over again, which
> wouldn't make a lot of sense. Especially in a single thread
> scenario as it would be starting & stopping a server during
> each invocation.
>
> b) Implement a timeout mechanism. In which case it would work
> equally well when setting a reply-to EPR on a Client.
>
> c) Implement a refcount & timeout mechanism. i.e. if I call
> close on my conduit, but another client still has the same
> decoupled server/port open we would obviously want it to stay
> up. Which once again works equally well when setting a reply
> to EPR on the client.
>
> d) Trying to call Conduit.close() when the client is being
> GC'd. But there is no sure way to do this Java. Even if you
> could, this would once again work equally as well when
> setting an EPR on the Client.
There's no question of what's there being an attempt to be timeout-based
or reliant on GC.
Instead the idea in the original Celtix code was to use a reference
counting scheme for the decoupled response endpoint, and to allow this
to be shared across client transport instances. This was simply not
ported over properly to CXF.
The original scheme worked as the HTTPClientTransport was created once
per binding instance, had well-defined shutdown semantics, and reused if
possible a pre-existing listener for the decoupled endpoint, even if
this was created from another HTTPClientTransport. This reuse was easy
to do as HTTPClientTransport registered the Jetty handler directly,
instead of going thru' the DestinationFactory, and thus could easily
check if a pre-existing handler was already registered.
> The issue is there is no great place to call Conduit.close().
> You need to do it once you're done with the client, but there
> is no way to be sure of that.
> So the next best thing is to allow the user to do it them
> selves and possibly auto-close/reopen if necessary.
Sure, giving the user the capability to shut down the Client explicitly
wouldn't be a bad thing.
> > Lets say I define a
> > > replyTo endpoint in my cxf.xmlfile. Its not going to get
> shut down
> > > until I specifically shut it down myself or until I shut the
> > > appserver down. So letting CXF create a destination automatically
> > > would not really be any different. It just makes it
> easier for the
> > > user to set up the decoupled endpoint via the API. Once they are
> > > done with the client they could call
> > > Client.getDestination().shutdown()
> > > and release any resources.
> >
> >
> > I'm not sure it would be that simple.
> >
> > The user may have specified different decoupled destinations for a
> > series of invocations mediated by the same Client instance.
>
>
> So are we going let these accumulate and then have a
> > close-all-in-one-fell-swoop type API on Client, say
> > shutdownAllDestinations()?
>
>
> This is an issue *regardless of how you are setting up the decoupled
> destination.* The only way to auto-close them is to combine
> it with a refcount/timeout mechanism like I outlined above or
> to have the user explicitly close them (either on a per
> request or client lifecycle basis).
>
> But that would have the effect of the client hogging
> transport resources
> > (e.g. HTTP ports or JMS Destinations) for much longer than
> necessary,
> > i.e. for the period after the client has stopped using these as the
> > replyTo for requests, but before the corresponding JAX-WS proxy or
> > whatever goes away.
> >
> > Also there's the issue of what WS-RM uses as its acksTo
> address. AFAIK
> > this is still just the decoupled endpoint associated with
> the Conduit.
> > However, it needs to continue to be available to receive
> ACKs for the
> > lifetime of the RM sequence. So we don't want the application to be
> > able pull the rug out from under RM by specifying a
> short-lived replyTo.
>
>
> There are a couple ways to solve this:
> - We can ref count the decoupled server endpoint. If the
> client closed, there would still be an outstanding reference
> to the server. So the server endpoint wouldn't close until RM
> terminated its sequence and it called
> close() on the decoupled destination.
> - We could add extension points via a Client.close() API so
> that RM could terminate the sequence and shut down the
> decoupled destination when its called.
>
> This brings up an interesting point: Currently I can only
> associate a decoupled destination with a client's conduit
> AFAIK. But this makes absolutely no sense to me - there are
> many decoupled destinations that could be associated with a
> client. For instance it might have a different acksTo then
> ReplyTo. Or I might have a different FaultTo.
I don't think you're correct here. If I go and explicitly set the
replyTo to a Destination that I've created (via a DestinationFactory)
then this will be used for the <wsa:ReplyTo> in the outgoing message, as
opposed to the back-channel destination overwriting the explicit
setting.
Similarly the acksTo could be set to any Destination, but RM just
happens to be implemented to use the back-channel destination for
convenience. By convenience, I mean it avoids the RM layer having to set
up a separate in-interceptor-chain to handle incoming out-of-band
messages.
The per-Conduit restriction only applies to *automatically launched*
decoupled response endpoints. The application can go nuts explicitly
creating response endpoints all over town if it wants ...
/Eoghan
Re: Client API, EPRs
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 3/12/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: 11 March 2007 21:48
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Client API, EPRs
> >
> > Hola,
> >
> > Apologies for the lag here. Too much traveling going on and I
> > wanted to spend some time thinking through this some more.
> >
> > Some comments inline.
> >
> > On 3/6/07, Glynn, Eoghan <eo...@iona.com> wrote:
> > >
> > >
> > >
> > > Hi Dan,
> > >
> > > Well if CXF is embedded in another product that *already*
> > exposes an
> > > endpoint (e.g. a HTTP listsner) from the client process space, then
> > > CXF could use that to receive decoupled responses. All the
> > app needs
> > > to do is to provide an appropriate EPR via
> > > AddressingProperties.setReplyTo (), set this on the request
> > context,
> > > and the CXF WS-A layer won't over-write this with any decoupled
> > > response endpoint that may (or may not) have been
> > configured on the Conduit.
> > >
> > > However, I don't think its reasonable to expect CXF to *actively*
> > > launch a decoupled response endpoint on the basis of a replyTo EPR
> > > provided by the application, for a number of reasons:
> > >
> > > 1. the replyTo EPR may not contain all the info that the transport
> > > needs to initiate receipt of incoming messages, e.g. JMS may need
> > > stuff like a username/password for the connection factory,
> > maybe a JNDI provider etc.
> > > This sort of transport-specific stuff may not be suitable for
> > > shoe-horning into an EPR, and would probably need to be
> > configured in
> > > a transport-specific way.
> >
> >
> > First, thats an edge case.
>
>
> JMS is an edge-case?
In the sense that:
a) Most people use HTTP
b) Soon we should have a mechanism to stuff all this stuff into an EPR
c) There are other transports beside just JMS and HTTP, like XMPP or TCP or
FTP which work just fine with URIs. JMS is the odd ball in the sense that
historically it has needed stuff outside the EPR.
> Second, people are defining
> > standards to shoe-horn JMS info into IRIs.
>
>
> Be that as it may, but as things currently stand, JMS needs more than a
> URI.
Whats your point? As I stated in point #3 if they absolutely needed to they
could fall back to configuring a specific destination if they wanted via XML
or the API.
> Third, when the
> > decoupled destination is being set up it can still pull
> > configuration from xml files if people need to add extra
> > configuration info.
>
>
> Wouldn't that defeat your stated purpose? (i.e. not having to do
> transport-specific config)
Yes, I was simply stating this is a possibility if the user needed to fall
back to it. Hopefully they wouldn't need to.
> 2. there's no guarantee that the replyTo EPR specified by the
> > app makes
> > > any sense, e.g. it may be for a different transport to that
> > used for
> > > the outbound request (and we discussed the undesirability of mixed
> > > transport within an MEP on this list a while back).
> >
> >
> > We should add checks to ensure that this is sane & valid
> > then. Its not that hard to ensure that the ReplyTo transport
> > is the same as the outgoing one.
> > We simply need to match up the transport IDs or the protocol
> > part of the URL.
> >
> > 3. its hard to see how to manage the lifecycle of a listener
> > created on
> > > demand by CXF on foot of an application-provided replyTo.
> > What if the
> > > app specifies a different replyTo URI for each sucessive request,
> > > maybe intending that the listener is a one-shot deal (i.e. is only
> > > intended to accept a single decoupled response). There's no way for
> > > the app to communicate this intended lifecycle with CXF, so CXF
> > > wouldn't know when to shutdown the Destination.
> > >
> >
> > Lets ignore the per request case a moment: How would this
> > differ from how things currently are?
>
> Well the intention was that the decoupled endpoint is ref-counted, and
> then shutdown when the last HTTPConduit referencing it is closed.
>
> However, looking at the code, this intention seems to be frustrated by
> two factors:
> - Conduit.close() is not being called anywhere
> - the ref count has morphed into being non-static
>
> Gonna have to fix that ...
I think you're oversimplifying the issue. Either you're trying to:
a) count the number of clients which are actively invoking. In which case
when I stop sending and then resume a minute later you're going to have to
start it all over again, which wouldn't make a lot of sense. Especially in a
single thread scenario as it would be starting & stopping a server during
each invocation.
b) Implement a timeout mechanism. In which case it would work equally well
when setting a reply-to EPR on a Client.
c) Implement a refcount & timeout mechanism. i.e. if I call close on my
conduit, but another client still has the same decoupled server/port open we
would obviously want it to stay up. Which once again works equally well when
setting a reply to EPR on the client.
d) Trying to call Conduit.close() when the client is being GC'd. But there
is no sure way to do this Java. Even if you could, this would once again
work equally as well when setting an EPR on the Client.
The issue is there is no great place to call Conduit.close(). You need to do
it once you're done with the client, but there is no way to be sure of that.
So the next best thing is to allow the user to do it them selves and
possibly auto-close/reopen if necessary.
> Lets say I define a
> > replyTo endpoint in my cxf.xmlfile. Its not going to get shut
> > down until I specifically shut it down myself or until I shut
> > the appserver down. So letting CXF create a destination
> > automatically would not really be any different. It just
> > makes it easier for the user to set up the decoupled endpoint
> > via the API. Once they are done with the client they could call
> > Client.getDestination().shutdown()
> > and release any resources.
>
>
> I'm not sure it would be that simple.
>
> The user may have specified different decoupled destinations for a
> series of invocations mediated by the same Client instance.
So are we going let these accumulate and then have a
> close-all-in-one-fell-swoop type API on Client, say
> shutdownAllDestinations()?
This is an issue *regardless of how you are setting up the decoupled
destination.* The only way to auto-close them is to combine it with a
refcount/timeout mechanism like I outlined above or to have the user
explicitly close them (either on a per request or client lifecycle basis).
But that would have the effect of the client hogging transport resources
> (e.g. HTTP ports or JMS Destinations) for much longer than necessary,
> i.e. for the period after the client has stopped using these as the
> replyTo for requests, but before the corresponding JAX-WS proxy or
> whatever goes away.
>
> Also there's the issue of what WS-RM uses as its acksTo address. AFAIK
> this is still just the decoupled endpoint associated with the Conduit.
> However, it needs to continue to be available to receive ACKs for the
> lifetime of the RM sequence. So we don't want the application to be able
> pull the rug out from under RM by specifying a short-lived replyTo.
There are a couple ways to solve this:
- We can ref count the decoupled server endpoint. If the client closed,
there would still be an outstanding reference to the server. So the server
endpoint wouldn't close until RM terminated its sequence and it called
close() on the decoupled destination.
- We could add extension points via a Client.close() API so that RM could
terminate the sequence and shut down the decoupled destination when its
called.
This brings up an interesting point: Currently I can only associate a
decoupled destination with a client's conduit AFAIK. But this makes
absolutely no sense to me - there are many decoupled destinations that could
be associated with a client. For instance it might have a different acksTo
then ReplyTo. Or I might have a different FaultTo.
Regards,
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Client API, EPRs
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 11 March 2007 21:48
> To: cxf-dev@incubator.apache.org
> Subject: Re: Client API, EPRs
>
> Hola,
>
> Apologies for the lag here. Too much traveling going on and I
> wanted to spend some time thinking through this some more.
>
> Some comments inline.
>
> On 3/6/07, Glynn, Eoghan <eo...@iona.com> wrote:
> >
> >
> >
> > Hi Dan,
> >
> > Well if CXF is embedded in another product that *already*
> exposes an
> > endpoint (e.g. a HTTP listsner) from the client process space, then
> > CXF could use that to receive decoupled responses. All the
> app needs
> > to do is to provide an appropriate EPR via
> > AddressingProperties.setReplyTo (), set this on the request
> context,
> > and the CXF WS-A layer won't over-write this with any decoupled
> > response endpoint that may (or may not) have been
> configured on the Conduit.
> >
> > However, I don't think its reasonable to expect CXF to *actively*
> > launch a decoupled response endpoint on the basis of a replyTo EPR
> > provided by the application, for a number of reasons:
> >
> > 1. the replyTo EPR may not contain all the info that the transport
> > needs to initiate receipt of incoming messages, e.g. JMS may need
> > stuff like a username/password for the connection factory,
> maybe a JNDI provider etc.
> > This sort of transport-specific stuff may not be suitable for
> > shoe-horning into an EPR, and would probably need to be
> configured in
> > a transport-specific way.
>
>
> First, thats an edge case.
JMS is an edge-case?
> Second, people are defining
> standards to shoe-horn JMS info into IRIs.
Be that as it may, but as things currently stand, JMS needs more than a
URI.
> Third, when the
> decoupled destination is being set up it can still pull
> configuration from xml files if people need to add extra
> configuration info.
Wouldn't that defeat your stated purpose? (i.e. not having to do
transport-specific config)
> 2. there's no guarantee that the replyTo EPR specified by the
> app makes
> > any sense, e.g. it may be for a different transport to that
> used for
> > the outbound request (and we discussed the undesirability of mixed
> > transport within an MEP on this list a while back).
>
>
> We should add checks to ensure that this is sane & valid
> then. Its not that hard to ensure that the ReplyTo transport
> is the same as the outgoing one.
> We simply need to match up the transport IDs or the protocol
> part of the URL.
>
> 3. its hard to see how to manage the lifecycle of a listener
> created on
> > demand by CXF on foot of an application-provided replyTo.
> What if the
> > app specifies a different replyTo URI for each sucessive request,
> > maybe intending that the listener is a one-shot deal (i.e. is only
> > intended to accept a single decoupled response). There's no way for
> > the app to communicate this intended lifecycle with CXF, so CXF
> > wouldn't know when to shutdown the Destination.
> >
>
> Lets ignore the per request case a moment: How would this
> differ from how things currently are?
Well the intention was that the decoupled endpoint is ref-counted, and
then shutdown when the last HTTPConduit referencing it is closed.
However, looking at the code, this intention seems to be frustrated by
two factors:
- Conduit.close() is not being called anywhere
- the ref count has morphed into being non-static
Gonna have to fix that ...
> Lets say I define a
> replyTo endpoint in my cxf.xmlfile. Its not going to get shut
> down until I specifically shut it down myself or until I shut
> the appserver down. So letting CXF create a destination
> automatically would not really be any different. It just
> makes it easier for the user to set up the decoupled endpoint
> via the API. Once they are done with the client they could call
> Client.getDestination().shutdown()
> and release any resources.
I'm not sure it would be that simple.
The user may have specified different decoupled destinations for a
series of invocations mediated by the same Client instance.
So are we going let these accumulate and then have a
close-all-in-one-fell-swoop type API on Client, say
shutdownAllDestinations()?
But that would have the effect of the client hogging transport resources
(e.g. HTTP ports or JMS Destinations) for much longer than necessary,
i.e. for the period after the client has stopped using these as the
replyTo for requests, but before the corresponding JAX-WS proxy or
whatever goes away.
Also there's the issue of what WS-RM uses as its acksTo address. AFAIK
this is still just the decoupled endpoint associated with the Conduit.
However, it needs to continue to be available to receive ACKs for the
lifetime of the RM sequence. So we don't want the application to be able
pull the rug out from under RM by specifying a short-lived replyTo.
Believe me, I thought about more dynamic approaches like what you're
advocating, but came to the conclusion that the lifecycle mgmt could be
much more error-prone.
/Eoghan
> (I also would not be opposed to establishing a client life
> cycle. I.e. a user can call Client.close() once they are done
> with everything. This would allow RM to terminate the
> sequence at the same time. But maybe that is a topic for
> another thread.)
>
> Regarding the per request use case, my initial reaction is
> that we should not do any automatic setup here. The main use
> case that I'm targeting is creating a standard way to create
> a decoupled endpoint. If the user is overriding it at a per
> request level they probably have a good reason for doing so
> and can manage the endpoint creation themselves. I don't see
> that as a very common case though.
>
> I don't think there is anything that evil about auto-creating
> a decoupled endpoint for the user if they specify it. But it
> does make it easy for anyone to do it in a standard way.
> Which simplifies configuration and documentation.
>
> Regards,
> - Dan
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
Re: Client API, EPRs
Posted by Dan Diephouse <da...@envoisolutions.com>.
Hola,
Apologies for the lag here. Too much traveling going on and I wanted to
spend some time thinking through this some more.
Some comments inline.
On 3/6/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
>
> Hi Dan,
>
> Well if CXF is embedded in another product that *already* exposes an
> endpoint (e.g. a HTTP listsner) from the client process space, then CXF
> could use that to receive decoupled responses. All the app needs to do
> is to provide an appropriate EPR via AddressingProperties.setReplyTo (),
> set this on the request context, and the CXF WS-A layer won't over-write
> this with any decoupled response endpoint that may (or may not) have
> been configured on the Conduit.
>
> However, I don't think its reasonable to expect CXF to *actively* launch
> a decoupled response endpoint on the basis of a replyTo EPR provided by
> the application, for a number of reasons:
>
> 1. the replyTo EPR may not contain all the info that the transport needs
> to initiate receipt of incoming messages, e.g. JMS may need stuff like a
> username/password for the connection factory, maybe a JNDI provider etc.
> This sort of transport-specific stuff may not be suitable for
> shoe-horning into an EPR, and would probably need to be configured in a
> transport-specific way.
First, thats an edge case. Second, people are defining standards to
shoe-horn JMS info into IRIs. Third, when the decoupled destination is being
set up it can still pull configuration from xml files if people need to add
extra configuration info.
2. there's no guarantee that the replyTo EPR specified by the app makes
> any sense, e.g. it may be for a different transport to that used for the
> outbound request (and we discussed the undesirability of mixed transport
> within an MEP on this list a while back).
We should add checks to ensure that this is sane & valid then. Its not that
hard to ensure that the ReplyTo transport is the same as the outgoing one.
We simply need to match up the transport IDs or the protocol part of the
URL.
3. its hard to see how to manage the lifecycle of a listener created on
> demand by CXF on foot of an application-provided replyTo. What if the
> app specifies a different replyTo URI for each sucessive request, maybe
> intending that the listener is a one-shot deal (i.e. is only intended to
> accept a single decoupled response). There's no way for the app to
> communicate this intended lifecycle with CXF, so CXF wouldn't know when
> to shutdown the Destination.
>
Lets ignore the per request case a moment: How would this differ from how
things currently are? Lets say I define a replyTo endpoint in my
cxf.xmlfile. Its not going to get shut down until I specifically shut
it down
myself or until I shut the appserver down. So letting CXF create a
destination automatically would not really be any different. It just makes
it easier for the user to set up the decoupled endpoint via the API. Once
they are done with the client they could call
Client.getDestination().shutdown()
and release any resources.
(I also would not be opposed to establishing a client life cycle. I.e. a
user can call Client.close() once they are done with everything. This would
allow RM to terminate the sequence at the same time. But maybe that is a
topic for another thread.)
Regarding the per request use case, my initial reaction is that we should
not do any automatic setup here. The main use case that I'm targeting is
creating a standard way to create a decoupled endpoint. If the user is
overriding it at a per request level they probably have a good reason for
doing so and can manage the endpoint creation themselves. I don't see that
as a very common case though.
I don't think there is anything that evil about auto-creating a decoupled
endpoint for the user if they specify it. But it does make it easy for
anyone to do it in a standard way. Which simplifies configuration and
documentation.
Regards,
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Client API, EPRs
Posted by "Glynn, Eoghan" <eo...@iona.com>.
Hi Dan,
Well if CXF is embedded in another product that *already* exposes an
endpoint (e.g. a HTTP listsner) from the client process space, then CXF
could use that to receive decoupled responses. All the app needs to do
is to provide an appropriate EPR via AddressingProperties.setReplyTo(),
set this on the request context, and the CXF WS-A layer won't over-write
this with any decoupled response endpoint that may (or may not) have
been configured on the Conduit.
However, I don't think its reasonable to expect CXF to *actively* launch
a decoupled response endpoint on the basis of a replyTo EPR provided by
the application, for a number of reasons:
1. the replyTo EPR may not contain all the info that the transport needs
to initiate receipt of incoming messages, e.g. JMS may need stuff like a
username/password for the connection factory, maybe a JNDI provider etc.
This sort of transport-specific stuff may not be suitable for
shoe-horning into an EPR, and would probably need to be configured in a
transport-specific way.
2. there's no guarantee that the replyTo EPR specified by the app makes
any sense, e.g. it may be for a different transport to that used for the
outbound request (and we discussed the undesirability of mixed transport
within an MEP on this list a while back).
3. its hard to see how to manage the lifecycle of a listener created on
demand by CXF on foot of an application-provided replyTo. What if the
app specifies a different replyTo URI for each sucessive request, maybe
intending that the listener is a one-shot deal (i.e. is only intended to
accept a single decoupled response). There's no way for the app to
communicate this intended lifecycle with CXF, so CXF wouldn't know when
to shutdown the Destination.
Makes sense, or?
Cheers,
Eoghan
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 03 March 2007 00:59
> To: cxf-dev@incubator.apache.org
> Subject: Re: Client API, EPRs
>
> Hi Eoghan,
> I'm a bit concerned about having to set this on the
> HTTPConduit (or its configuration). This seems to force the
> user to always be involved in setting up the decoupled
> endpoint as there is no standard way across transports to set
> up the decoupled channel.
>
> Lets say I embed CXF in another product and I need to
> configure via the API the ReplyTo EPR for sequence
> acknowledgements. Now my product needs to be aware of each
> and every transport that supports decoupling and how to set
> up the decoupled response channel. i.e.
> HTTPClientPolicy.setDecoupledEndpoint(...);
> on each transport.
>
> Couldn't we make a generic way for people to specify the
> ReplyTo EPR and let CXF take care of the rest? By "the rest"
> I mean that CXF would set up the decoupled response listener
> with just the knowledge of my EPR. Or am I missing something here?
>
> - Dan
>
> On 2/27/07, Glynn, Eoghan <eo...@iona.com> wrote:
> >
> >
> > Dan,
> >
> > Have a look at the ws_addressing demo, specifically the explicit
> > propogation model.
> >
> > Here the JAX-WS request context is used to associate a specific
> > AddressingProperties instance with the invocation, in this
> case to use
> > a particular message ID.
> >
> > Note however that setting the replyTo to a specific EPR won't cause
> > the HTTP transport to start listening for decoupled
> responses on this URI.
> > We've discussed this before on this list, and as you know the
> > decoupled response endpoint is currently sepcified as part of the
> > HTTPConduit config.
> >
> > Also as DanK points, the JAX-WS 2.1 subsumes JAX-WSA and provides a
> > bunch of convenience APIs for WS-A, including a
> > javax.xml.ws.EndpointReference type with a less ugly API
> than the JAXB
> > generated type that you're complaining about. Instances of
> this type
> > may be created via BindingProvider.getEndpointReference() and then
> > used for example to retrieve a proxy via
> > Service.getPort(EndpointReference epr, ...).
> >
> > Cheers,
> > Eoghan
> >
> > > -----Original Message-----
> > > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > > Sent: 27 February 2007 16:06
> > > To: cxf-dev@incubator.apache.org
> > > Subject: Client API, EPRs
> > >
> > > Hi All,
> > >
> > > Is there a way to use WS-Adressing from the Client API?
> > > Specifically I'd like to be able to set the replyTo/faultTo
> > > locations somehow for the Client itself and then also on the
> > > invocation context:
> > >
> > > client.setReplyTo(new EndpointReference(" http://foo/replyTo"));
> > >
> > > Or:
> > >
> > > Map<String, Object> context = ...;
> > > context.put(REPLY_TO, epr);
> > > client.invoke(operation, args, context);
> > >
> > > This brings up the question in my mind of whether or not
> we really
> > > want to use EndpointReferenceType throughout the codebase. I'm
> > > uncomfortable with the way things stand as
> > > - EndpointRefenceType has an ugly API. It is not easy to
> create an
> > > EPR from a String/URL and I think it should be doable via a
> > > constructor. (Yeah, we can create factories, but thats
> ugly and it
> > > still doesn't make retrieving values friendlier).
> > > - We seem to have an odd mixture of EndpointReferenceTypes and
> > > EndointInfos going on in our transport interfaces. On
> some methods
> > > we require both. It seems like it should be either one or
> the other.
> > > - WIth that said, using an EndpointInfo is odd to me as
> thats part
> > > of the service model. Using an EPR seems unnatural for reasons I
> > > state above.
> > >
> > > Whats the advantage of using EndpointReferenceType throughout the
> > > codebase as opposed to our own class?
> > >
> > > Regards,
> > > - Dan
> > > --
> > > Dan Diephouse
> > > Envoi Solutions
> > > http://envoisolutions.com | http://netzooid.com/blog
> > >
> >
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
Re: Client API, EPRs
Posted by Dan Diephouse <da...@envoisolutions.com>.
Hi Eoghan,
I'm a bit concerned about having to set this on the HTTPConduit (or its
configuration). This seems to force the user to always be involved in
setting up the decoupled endpoint as there is no standard way across
transports to set up the decoupled channel.
Lets say I embed CXF in another product and I need to configure via the API
the ReplyTo EPR for sequence acknowledgements. Now my product needs to be
aware of each and every transport that supports decoupling and how to set up
the decoupled response channel. i.e.
HTTPClientPolicy.setDecoupledEndpoint(...);
on each transport.
Couldn't we make a generic way for people to specify the ReplyTo EPR and let
CXF take care of the rest? By "the rest" I mean that CXF would set up the
decoupled response listener with just the knowledge of my EPR. Or am I
missing something here?
- Dan
On 2/27/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
> Dan,
>
> Have a look at the ws_addressing demo, specifically the explicit
> propogation model.
>
> Here the JAX-WS request context is used to associate a specific
> AddressingProperties instance with the invocation, in this case to use a
> particular message ID.
>
> Note however that setting the replyTo to a specific EPR won't cause the
> HTTP transport to start listening for decoupled responses on this URI.
> We've discussed this before on this list, and as you know the decoupled
> response endpoint is currently sepcified as part of the HTTPConduit
> config.
>
> Also as DanK points, the JAX-WS 2.1 subsumes JAX-WSA and provides a
> bunch of convenience APIs for WS-A, including a
> javax.xml.ws.EndpointReference type with a less ugly API than the JAXB
> generated type that you're complaining about. Instances of this type may
> be created via BindingProvider.getEndpointReference() and then used for
> example to retrieve a proxy via Service.getPort(EndpointReference epr,
> ...).
>
> Cheers,
> Eoghan
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: 27 February 2007 16:06
> > To: cxf-dev@incubator.apache.org
> > Subject: Client API, EPRs
> >
> > Hi All,
> >
> > Is there a way to use WS-Adressing from the Client API?
> > Specifically I'd like to be able to set the replyTo/faultTo
> > locations somehow for the Client itself and then also on the
> > invocation context:
> >
> > client.setReplyTo(new EndpointReference(" http://foo/replyTo"));
> >
> > Or:
> >
> > Map<String, Object> context = ...;
> > context.put(REPLY_TO, epr);
> > client.invoke(operation, args, context);
> >
> > This brings up the question in my mind of whether or not we
> > really want to use EndpointReferenceType throughout the
> > codebase. I'm uncomfortable with the way things stand as
> > - EndpointRefenceType has an ugly API. It is not easy to
> > create an EPR from a String/URL and I think it should be
> > doable via a constructor. (Yeah, we can create factories, but
> > thats ugly and it still doesn't make retrieving values friendlier).
> > - We seem to have an odd mixture of EndpointReferenceTypes
> > and EndointInfos going on in our transport interfaces. On
> > some methods we require both. It seems like it should be
> > either one or the other.
> > - WIth that said, using an EndpointInfo is odd to me as thats
> > part of the service model. Using an EPR seems unnatural for
> > reasons I state above.
> >
> > Whats the advantage of using EndpointReferenceType throughout
> > the codebase as opposed to our own class?
> >
> > Regards,
> > - Dan
> > --
> > Dan Diephouse
> > Envoi Solutions
> > http://envoisolutions.com | http://netzooid.com/blog
> >
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Client API, EPRs
Posted by "Glynn, Eoghan" <eo...@iona.com>.
Dan,
Have a look at the ws_addressing demo, specifically the explicit
propogation model.
Here the JAX-WS request context is used to associate a specific
AddressingProperties instance with the invocation, in this case to use a
particular message ID.
Note however that setting the replyTo to a specific EPR won't cause the
HTTP transport to start listening for decoupled responses on this URI.
We've discussed this before on this list, and as you know the decoupled
response endpoint is currently sepcified as part of the HTTPConduit
config.
Also as DanK points, the JAX-WS 2.1 subsumes JAX-WSA and provides a
bunch of convenience APIs for WS-A, including a
javax.xml.ws.EndpointReference type with a less ugly API than the JAXB
generated type that you're complaining about. Instances of this type may
be created via BindingProvider.getEndpointReference() and then used for
example to retrieve a proxy via Service.getPort(EndpointReference epr,
...).
Cheers,
Eoghan
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 27 February 2007 16:06
> To: cxf-dev@incubator.apache.org
> Subject: Client API, EPRs
>
> Hi All,
>
> Is there a way to use WS-Adressing from the Client API?
> Specifically I'd like to be able to set the replyTo/faultTo
> locations somehow for the Client itself and then also on the
> invocation context:
>
> client.setReplyTo(new EndpointReference("http://foo/replyTo"));
>
> Or:
>
> Map<String, Object> context = ...;
> context.put(REPLY_TO, epr);
> client.invoke(operation, args, context);
>
> This brings up the question in my mind of whether or not we
> really want to use EndpointReferenceType throughout the
> codebase. I'm uncomfortable with the way things stand as
> - EndpointRefenceType has an ugly API. It is not easy to
> create an EPR from a String/URL and I think it should be
> doable via a constructor. (Yeah, we can create factories, but
> thats ugly and it still doesn't make retrieving values friendlier).
> - We seem to have an odd mixture of EndpointReferenceTypes
> and EndointInfos going on in our transport interfaces. On
> some methods we require both. It seems like it should be
> either one or the other.
> - WIth that said, using an EndpointInfo is odd to me as thats
> part of the service model. Using an EPR seems unnatural for
> reasons I state above.
>
> Whats the advantage of using EndpointReferenceType throughout
> the codebase as opposed to our own class?
>
> Regards,
> - Dan
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>