> We already have isGET which seriously gets on my nerves. Why
> should people be checking these flags all the time?
People don't need to check this "flag" (i.e. property on the message
indicating in-process dispatch) all the time.
The only place I'd see a definite need for checking is in the
receiver-side security interceptors.
What if a user writes an interceptor which does something to the XML
message? They would need to add this check.
This is just a reason I'm nervous about such a transparent in-dispatch
mechanism.
> > What if the server & the client use different databindings?
> >
> >
> > Data-bindings don't come into the picture.
>
>
> How is that? If my server uses Aegis and my client uses JAXB,
> then it seems you're trying to bypass the XML step which is
> needed. This is OK if it requires conscious enablement by the
> user, but automatic is another story.
Part of the transparent detection as to whether this form of dispatch is
possible would I guess have to include a check as to whether the data
bindings match and so could be by-passed.
So that the raw Java objects could be passed directly.
OK, great.
> > [First Impressions]
> > > My first impression (based on what I understand you're trying to
> > > achieve at this point) is that any solution:
> > > a) Will require the use of different binding interceptors.
> >
> >
> > No. The binding interceptors don't need to change. Instead
> they'd be
> > by-passed.
>
>
> How???
By removing the binding-level interceptors from the chain.
> The flag? This is exactly what Bindings are for
> though. Why don't we just switch bindings? Or we could delay
> the addition of the Binding. But a message flag?
The in-process message property has nothing to do with the switching out
of the binding interceptors from the chain. This is effectuated by a
prior interceptor in the chain. The property simply marks the message as
having undergone this specialized form of dispatch. It doesn't cause
this form of dispatch to occur in the first place.
> Just because you see this as the way to solve your use case doesn't
> necessarily mean it is the way we should support.
The same principle applies to you, no?
What is in SVN right now wins out. This is the same reason I can't just go
changing how Conduit decoupling works.
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.
So let me get this straight.
You hold it as an article of faith that the Conduit selection *MUST* be
done upfront in the Client, but you're prepared to allow the binding
selection to be deferred?
NO. I'm open to allowing the Conduit creation to be deferred.
I just don't understand why its such a big deal to create a Conduit that
doesn't ultimately end up being used. Its maybe 1 percent of Client creation
time. We have service factories, reflection, xml parsing, bus startup, etc.
I also just want to know why we need a strategy class instead of a simple
flag.
If you think about it, the way a Conduit is created is completely consistent
with how we treat the Binding. In your scenario the Binding is created,
configured, but never used. Thats exactly what I'm proposing with the
Conduit. We aren't trying to delay the binding creation and eliminate the
binding "overhead", so why are we trying to eliminate the Conduit
"overhead"?
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.
What would an ObjectBinding give us that a totally by-passed binding
wouldn't?
see below.
Other than the comfort factor of "hey we gotta have a binding, right?"
Isn't this what a binding is for?
Of course there are always different approaches that could achieve a
similar result.
Yup. And usually inside CXF we pick one and standardize on it - provided
that the solution doesn't place any undue burden on users for certain use
cases. This way users don't ask "how do I do X" and get 5 different answers.
If you say that a solution which uses a Conduit and an ObjectBinding will
work, why go and invent another one?
The ObjectBinding gives you a way to address remote services through
properties. Your interceptor can simply select a binding QName and operation
name. We can also add support for invoking service Interfaces. This way any
future improvements we make to the ObjectBinding will flow back to you as
well.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
