I had thought that Eoghan's original objection was that a Conduit,
implied the use of a Client when he needed Decoupled Endpoints, because
Dan want's the Client to manage Decoupled Endpoints, and Eoghan wants
the Conduit to handle them.
Maybe we need just another abstraction in the middle to satisfy both
parties?
It seems to me that a Conduit is merely a "one-way" "client" side way of
talking to an Endpoint. Somethings need to be configured on it, so that
it does certain things according to protocol, and handles responses(if any).
There might be another entity that handles two-way communication on
which you can set destinations, decoupled endpoints, that use a conduit
(or something else?) in the client-to-server direction. This entity
would be better suited to following security/assurance policies
regarding two-way communication. Like using a "secure" conduit, with a
"secure" decoupled endpoint.
A Client can use that entity in a specific default way. And Eoghan can
use this entity without specifying a Client, but still have the
flexibility he desires, and the user can still have some opportunity to
configure/check that things are on the up'n'up.
Does that seem like a plausible approach?
Cheers,
-Polar
Dan Diephouse wrote:
Just because you see this as the way to solve your use case doesn't
necessarily mean it is the way we should support. I'm certainly want to
support this scenario and I'm sure we will come to some agreement
about how
to best support it. BUT, there are other goals as well though - like
simplicity and coherency. If we've already got mechanisms for this
type of
thing, why go inventing others?
Do you agree that it is possible to delay the addition of Binding
interceptors to the chain inside the Client? Would it maybe be better to
delay this decision until later in the chain? This would avoid the
introduction of a flag mechanism.
If so, then why don't we just allow users to select a different
Binding up
to POST_LOGICAL phase? For instance, the ObjectBinding interceptors
could be
added if that person wanted to do a local invocation. They could also
select
a new Conduit up to this point as well. If the user doesn't select a
different binding or conduit, then we'll just use the default ones.
In addition to allowing your use case of allowing the interceptor to
control the binding, this makes the URI based approach much easier as
well.
One last addition, because I didn't address getting the part about
getting
the Conduit up front.
Let me sidestep first to your questions of why your proposal is
getting so
much scrutiny - well there are conflated discussions of whether or not
Conduits are needed for in process dispatching and whether or not we
should
adopt my proposed client changes. If we say that a Conduit is optional
for
invocations, then that has big ramifications in those areas.
If all we're trying to decide on is creating a way to avoid
initializing a
Conduit by default, then I only have two questions before adopting your
approach:
- Why should we have a ConduitInitiatorStrategy as opposed to just
setting a
flag on the Conduit? If someone sets the flag to false the
MessageSenderInterceptor can always fall back and init a Conduit later
using
the EndpointInfo.
- Is your only objection that we may not always need the specific Conduit
that is inited? And that this may consume resources? Or is the motivation
for this approach that you just don't want to use a Conduit at all. It
seems
like it is mostly the later, which is what all my hubbub is about.
- Dan
