In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]

[Dan Diephouse <da...@envoisolutions.com>]

On 4/1/07, Glynn, Eoghan <eoghan.glynn@iona.com > wrote:

> >
> > Overhead in getting the Conduit happens only once at Client creation.
>
> > And in the case of a local invocation it really results in just a call
>
> > to new LocalConduit(), which I'm sure is not a bottleneck.
> >
> > marshalling the message
> >
> >
> > A Conduit doesn't imply marshalling. For instance, I've outlined how
> > we could use an ObjectBinding (which we'd want to write for either
> > case) with the local transport. Currently the local transport requires
>
> > you write to the output stream, but this doesn't have to be so. I at
> > least fixed the input side so we can directly invoke a service, but
> > more changes are needed.
> >
> > payload & headers,
> >
> >
> > These are interceptors, and would be configured as part of the
> > binding. And hence in the local dispatch scenario they would not be
> > part of the Binding, and therefore would not be part of the
> > interceptor chain.
> >
> > and possibly applying transformations such as
> > > encryption or compression.
> >
> >
> > These are up to the user to enable on their endpoint. I don't see why
> > these would be enabled if you're invoking a local endpoint.
> >
> > This "overhead" that you're talking about seems completely unrelated
> > to the Conduit/Destination.
>
>
> Sure, I get what the local transport does.
>
> I'm talking about taking a different approach. That's allowed, right?


OK, let's reset here a moment. A different approach is definitely allowed.
Maybe you're right and we need to rearchitect some things. While the idea
may be crystalline clear in your head, I don't think there has been enough
information up to this point to really show that different mechanisms are
needed or how such alternate mechanisms would work. Depending on which
solution we go with, this could require significant changes to CXF, so I
think its good to be careful about this.

The local transport implies, as I understand it, a "static replacement"
> style of approach. So I specify a "local://" URI as the endpoint
> address, or my application explicitly sets a LocalConduit instance on
> the Client. Also I statically change my config or asserted polices to
> exclude interceptors that apply transformations unecessary in the local
> case, or change the interceptor impls to detect this case themselves.
> Also I engage an ObjectBinding in some way.
>
> Now that's all very well. But a different idea would be to go more for
> "adaptive diversion".
>
> Here the binding and interceptor chain would be set up exactly the same
> way, regardless of whether the target is local or remote. Where the
> target really is remote, then everything just works. If the target
> happens to be instantiated within the local process space, then I want
> to detect this and adapt accordingly, *without any static changes* (to
> config, WSDL, policies, code, whatever). Then maybe the target migrates
> to another container instance and everything reverts to work as before.


OK, this clarifies what you're looking to do for me quite a bit. If you're
looking to do an in process dispatch with an existing endpoint that has been
created (i.e. an HTTP endpoint) that is a completely different story. It
isn't very clear to me how the mechanics of such a thing would work. Could
you maybe supply a little more information about how you would see the
following working:

How would we determine if the endpoint is in the local process space? For
instance, if I have a Client talking to an HTTP Server endpoint, how does it
know to shortcut and talk to the server directly?

Would the Binding interceptors would be run?

Would your solution require the modification of the current binding
interceptors to support auto-detection of in process dispatch?

How do we determine which user level interceptors to run? Say I enable
WS-Security - what mechanisms would there be to determine that it should not
be run for the local invocation case?  Or what if a user writes a
transformation interceptor. How would the transformation be performed or
would it not be?

If a server requires HTTP security, will we just bypass it? For instance,
lets say that we have a website which communicates with its backend via a
soap service. The client uses the website's username/password to
authenticate against the server. If we just bypass that authentication, that
would be a security hole.

What if the server & the client use different databindings?

On the client side, when do we make the decision about whether or not the
endpoint is "in process"? During a client creation? Or during each
invocation? Can the decision happen mid invocation?

[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. Obviously we
don't want to go invoking soap interceptors for a local dispatch.
b) Will have some major affects on how their service is invoked and possibly
some security issues. It sounds like the user should make a conscious
decision about whether or not to use it.
c) Will have to make the decision about whether or not the Client is
invoking a local service or a remote service before the interceptor chain is
invoked. In other words, we will have to add logic to the Client to detect
this. If this is done during the interceptor chain we may already have
invoked binding interceptors.
d) Does not implicitly require that we ditch Conduits/Destinations for in
this type of in process dispatching (if you agree to b, I think this follows
relatively easily. Proposed solution below.)

[A proposed solution]
The client side is trickier. Its not clear to me that "detecting" that we
can use in process invocation is feasible or ultimately a good thing. Such a
thing makes me highly nervous. If we try to find a candidate for local
invocation based on the endpoint name, this could fail because there are
often multiple endpoints with the same name around. If we use the URL, this
may not work because we might be doing service routing and the URL may be
different. If we let the user do it, then this violates one of your stated
goals. There are also the tricky of issues as to whether or not the various
interceptors on the Client should be invoked (for instance ws-security) and
whether or not it was the user wants or intended. Are these all things we
want to occur by default? I will try to reserve judgment until I know more
about how you envision this selection logic working.

I like James's proposal of using a URI to invoke a service. This would imply
the creation of a ServiceConduit/ServiceDestination which understood URIs
such as started with endpoint:, interface:, etc. When the ServiceConduit
sends a message it would
- Find the appropriate service based on the URI (this has the limitation
that I mentioned above, namely you need to be careful about having services
with the same endpoint/service/interface name)
- Add the necessary interceptors to a chain (these would include the object
binding, endpoint, service, and bus interceptors)
- Set a ServiceDestination on the Exchange so the service can find the back
channel
- invoke the chain

These is completely transparent for the server side. However it does imply
that the user selects a different URI on the Client side. This seems like a
good thing so the user is conscious of there being an in process dispatch.
If this is ok, then it is just a hop-skip & jump since the user can just
select a different port or request a different URI.

So how could this work? I think we have two primary cases in which clients
are built: *ClientFactoryBeans and JAX-WS generated clients. The
ClientFactoryBean can auto-select the appropriate transport based on the
URI, so that is simple enough. Or in code form:
cf = new ClientFactoryBean()
cf.setAddress("endpoint:{namespace}FooService");
cf.setServiceClass(MyServiceInterface.class);
cf.create();

Inside ClientFactoryBean there would need to be detection logic for these
types of URLs to automatically load the appropriate binding or the user
would need to specify the binding.

With JAX-WS it is easier, we can just hide this logic and auto create a
local port for clients to talk to. The user could call
clientService.getPort(new
QName("MyServiceLocal"), MyServiceInterface.class); Generated stubs could
also include a handy clientService.getLocalPort() method (if this isn't
allowed by the TCK by default, this could be a flag in the wsdl2java).

CXF is intended to be a flexible framework. The user community is, or
> hopefully will be, a broad church. So CXF will accommodate a diversity
> of user-level approaches. Right?


User level approaches, yes. However, these are core architecture changes
which would potentially have a large affect on our code, so I think there
deserve a fair amount of scrutiny.

Regards,
- Dan

-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]

[Dan Diephouse <da...@envoisolutions.com>]

>
> > 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

RE: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]

["Glynn, Eoghan" <eo...@iona.com>]

I shall make it so :) 


> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: 03 April 2007 17:10
> To: cxf-dev@incubator.apache.org
> Subject: Re: In Process Dispatch [was Re: [PROPOSAL] Client 
> and Conduit changes]
> 
> OK, yeah I think so. A couple minor suggestions:
> - Pass in a Message to the class instead of an exchange. This 
> way its clear which message you're selecting a conduit for.
> - I am thinking that it might be better to name the 
> class/method something along the lines of 
> ConduitSelector.selectConduit - as the Conduit might alright 
> be instantiated (as in the case of a cluster of Conduits), 
> but I'll leave that up to you.
> 
> Glad we're making progress now! :)
> 
> Thanks Eoghan,
> - Dan
> 
> On 4/3/07, Glynn, Eoghan <eo...@iona.com> wrote:
> >
> >
> >
> > Hi Dan[D],
> >
> > Are my responses to your final two questions acceptable to you?
> >
> > Cheers,
> > Eoghan
> >
> > > -----Original Message-----
> > > From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com]
> > > Sent: 02 April 2007 22:41
> > > To: cxf-dev@incubator.apache.org
> > > Subject: RE: In Process Dispatch [was Re: [PROPOSAL] Client and 
> > > Conduit changes]
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > > > Sent: 02 April 2007 17:41
> > > > To: cxf-dev@incubator.apache.org
> > > > Subject: Re: In Process Dispatch [was Re: [PROPOSAL] Client and 
> > > > Conduit changes]
> > > >
> > > >
> > > > 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?
> > >
> > >
> > > Well a flag, being boolean, gives just two options.
> > >
> > > A pluggable strategy on the other hand would give more 
> flexibility 
> > > to take any number of approaches ... use a preexisting 
> conduit, or 
> > > create one upfront in ClientImpl.invoke(), or defer creating it 
> > > until the MessageSenderInterceptor, or retrieve it via some 
> > > discovery/config mechanism, or select one of a cluster of 
> endpoints, 
> > > or any other approach we care to dream up.
> > >
> > > In addition to the flexibility, the strategy approach has 
> conceptual 
> > > benefits - its much easier to digest the logic if 
> concentrated in a 
> > > single class as opposed to being buried in code spread across 
> > > multiple classes. Standard justification for this design pattern.
> > >
> > >
> > > > 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.
> > >
> > > *Both* are motivations, depending on the use case.
> > >
> > > In certain scenarios, the late Conduit retrieval would 
> allow us to 
> > > avoid needlessly creating a Conduit which would lie 
> unused if we end 
> > > up completely by-passing the transport.
> > >
> > > In other scenarios, the late Conduit retrieval would allow us to 
> > > ensure the correct Conduit has been selected before initing it.
> > >
> > >
> > > > It seems like it is mostly the later, which is what all 
> my hubbub 
> > > > is
> > > about.
> > >
> > >
> > > No, its definitely a multiple use-case idea.
> > >
> > > /Eoghan
> > >
> >
> 
> 
> 
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
> 

Re: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]

[Dan Diephouse <da...@envoisolutions.com>]

OK, yeah I think so. A couple minor suggestions:
- Pass in a Message to the class instead of an exchange. This way its clear
which message you're selecting a conduit for.
- I am thinking that it might be better to name the class/method something
along the lines of ConduitSelector.selectConduit - as the Conduit might
alright be instantiated (as in the case of a cluster of Conduits), but I'll
leave that up to you.

Glad we're making progress now! :)

Thanks Eoghan,
- Dan

On 4/3/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
>
> Hi Dan[D],
>
> Are my responses to your final two questions acceptable to you?
>
> Cheers,
> Eoghan
>
> > -----Original Message-----
> > From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com]
> > Sent: 02 April 2007 22:41
> > To: cxf-dev@incubator.apache.org
> > Subject: RE: In Process Dispatch [was Re: [PROPOSAL] Client
> > and Conduit changes]
> >
> >
> >
> > > -----Original Message-----
> > > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > > Sent: 02 April 2007 17:41
> > > To: cxf-dev@incubator.apache.org
> > > Subject: Re: In Process Dispatch [was Re: [PROPOSAL] Client and
> > > Conduit changes]
> > >
> > >
> > > 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?
> >
> >
> > Well a flag, being boolean, gives just two options.
> >
> > A pluggable strategy on the other hand would give more
> > flexibility to take any number of approaches ... use a
> > preexisting conduit, or create one upfront in
> > ClientImpl.invoke(), or defer creating it until the
> > MessageSenderInterceptor, or retrieve it via some
> > discovery/config mechanism, or select one of a cluster of
> > endpoints, or any other approach we care to dream up.
> >
> > In addition to the flexibility, the strategy approach has
> > conceptual benefits - its much easier to digest the logic if
> > concentrated in a single class as opposed to being buried in
> > code spread across multiple classes. Standard justification
> > for this design pattern.
> >
> >
> > > 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.
> >
> > *Both* are motivations, depending on the use case.
> >
> > In certain scenarios, the late Conduit retrieval would allow
> > us to avoid needlessly creating a Conduit which would lie
> > unused if we end up completely by-passing the transport.
> >
> > In other scenarios, the late Conduit retrieval would allow us
> > to ensure the correct Conduit has been selected before initing it.
> >
> >
> > > It seems like it is mostly the later, which is what all my hubbub is
> > about.
> >
> >
> > No, its definitely a multiple use-case idea.
> >
> > /Eoghan
> >
>



-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

RE: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]

["Glynn, Eoghan" <eo...@iona.com>]

Hi Dan[D],

Are my responses to your final two questions acceptable to you?

Cheers,
Eoghan 

> -----Original Message-----
> From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com] 
> Sent: 02 April 2007 22:41
> To: cxf-dev@incubator.apache.org
> Subject: RE: In Process Dispatch [was Re: [PROPOSAL] Client 
> and Conduit changes]
> 
>  
> 
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: 02 April 2007 17:41
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: In Process Dispatch [was Re: [PROPOSAL] Client and 
> > Conduit changes]
> >
> > 
> > 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?
> 
> 
> Well a flag, being boolean, gives just two options. 
> 
> A pluggable strategy on the other hand would give more 
> flexibility to take any number of approaches ... use a 
> preexisting conduit, or create one upfront in 
> ClientImpl.invoke(), or defer creating it until the 
> MessageSenderInterceptor, or retrieve it via some 
> discovery/config mechanism, or select one of a cluster of 
> endpoints, or any other approach we care to dream up. 
> 
> In addition to the flexibility, the strategy approach has 
> conceptual benefits - its much easier to digest the logic if 
> concentrated in a single class as opposed to being buried in 
> code spread across multiple classes. Standard justification 
> for this design pattern.
> 
> 
> > 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.
> 
> *Both* are motivations, depending on the use case. 
> 
> In certain scenarios, the late Conduit retrieval would allow 
> us to avoid needlessly creating a Conduit which would lie 
> unused if we end up completely by-passing the transport. 
> 
> In other scenarios, the late Conduit retrieval would allow us 
> to ensure the correct Conduit has been selected before initing it.
> 
> 
> > It seems like it is mostly the later, which is what all my hubbub is
> about.
> 
> 
> No, its definitely a multiple use-case idea.
> 
> /Eoghan
> 

RE: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]

["Glynn, Eoghan" <eo...@iona.com>]

 

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: 02 April 2007 17:41
> To: cxf-dev@incubator.apache.org
> Subject: Re: In Process Dispatch [was Re: [PROPOSAL] Client 
> and Conduit changes]
>
> 
> 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?


Well a flag, being boolean, gives just two options. 

A pluggable strategy on the other hand would give more flexibility to
take any number of approaches ... use a preexisting conduit, or create
one upfront in ClientImpl.invoke(), or defer creating it until the
MessageSenderInterceptor, or retrieve it via some discovery/config
mechanism, or select one of a cluster of endpoints, or any other
approach we care to dream up. 

In addition to the flexibility, the strategy approach has conceptual
benefits - its much easier to digest the logic if concentrated in a
single class as opposed to being buried in code spread across multiple
classes. Standard justification for this design pattern.


> 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. 

*Both* are motivations, depending on the use case. 

In certain scenarios, the late Conduit retrieval would allow us to avoid
needlessly creating a Conduit which would lie unused if we end up
completely by-passing the transport. 

In other scenarios, the late Conduit retrieval would allow us to ensure
the correct Conduit has been selected before initing it.


> It seems like it is mostly the later, which is what all my hubbub is
about.


No, its definitely a multiple use-case idea.

/Eoghan

Re: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]

[Polar Humenn <ph...@iona.com>]

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
>

Re: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]

[Dan Diephouse <da...@envoisolutions.com>]

>
>
> 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

-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: Backdoors

[Polar Humenn <ph...@iona.com>]

Just to follow up, I should have included a sample Server config file. 
It is attached.

Re: Backdoors

[Polar Humenn <ph...@iona.com>]

Dan Diephouse wrote:
> On 4/2/07, Polar Humenn <ph...@iona.com> wrote:
>>
>> Dan Diephouse wrote:
>> > The problem is this line:
>> >
>> >        EndpointImpl ep =
>> >            new EndpointImpl(
>> >                    getBus(),
>> >                    implementor1,
>> >                    "http://apache.org/hello_world",
>> >
>> > this.getClass().getResource("resources/greeting.wsdl"));
>> >
>> > Before we were ignoring the 3rd paramter - which is supposed to be the
>> > Binding URI. It has nothing to do with the target namespace. You don't
>> > want
>> > to be passing anything in there I'm guessing :-) So just make it null.
>> >
>> I guess, I was only guessing?
>>
>> You think, maybe problems like this might be alleviated by 
>> documentation?
>>
>> Oh, I forgot about "Comment rot"!
>>
>> How about naming the parameter "bindingURI"?
>
>
> :-) I will fix this in my copy and commit it with my next commit.
>
> I'd still like to know how I figure out the "configuration" name of the
>> Http-destination from this call.
>>
>
> <http:destination id="{
> http://apache.org/hello_world}Mortimer.http-destination">
>
> </http:destination>
>
> id = {targetNamespace}PortName.http-destination
>
I should have explained myself better.

If you noticed the WSDL file contains about multiple ports with 
localhost addresses from 9000-9009.

It is ep.publish(address) that actually selects the port name, not the 
constructor, right? which is of course, is just luck that it's defined 
in the WSDL, correct?

If you look at the WSDL and I then give this call

   ep.publish("http://localhost:12000/");

It seems to work -- the endpoint goes up at port 12000. Yet, I have no 
idea what the port name or the target namespace is, and subsequently the 
http-destination is also unknown (to me) at this point.

How do I figure this out? What target namespace and what port name got 
assigned?

Cheers,
-Polar

> Cheers,
> - Dan

Re: Backdoors

[Dan Diephouse <da...@envoisolutions.com>]

On 4/2/07, Polar Humenn <ph...@iona.com> wrote:
>
> Dan Diephouse wrote:
> > The problem is this line:
> >
> >        EndpointImpl ep =
> >            new EndpointImpl(
> >                    getBus(),
> >                    implementor1,
> >                    "http://apache.org/hello_world",
> >
> > this.getClass().getResource("resources/greeting.wsdl"));
> >
> > Before we were ignoring the 3rd paramter - which is supposed to be the
> > Binding URI. It has nothing to do with the target namespace. You don't
> > want
> > to be passing anything in there I'm guessing :-) So just make it null.
> >
> I guess, I was only guessing?
>
> You think, maybe problems like this might be alleviated by documentation?
>
> Oh, I forgot about "Comment rot"!
>
> How about naming the parameter "bindingURI"?


:-) I will fix this in my copy and commit it with my next commit.

I'd still like to know how I figure out the "configuration" name of the
> Http-destination from this call.
>

<http:destination id="{
http://apache.org/hello_world}Mortimer.http-destination">

</http:destination>

id = {targetNamespace}PortName.http-destination

Cheers,
- Dan
-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: Backdoors

[Polar Humenn <ph...@iona.com>]

Dan Diephouse wrote:
> The problem is this line:
>
>        EndpointImpl ep =
>            new EndpointImpl(
>                    getBus(),
>                    implementor1,
>                    "http://apache.org/hello_world",
>                    
> this.getClass().getResource("resources/greeting.wsdl"));
>
> Before we were ignoring the 3rd paramter - which is supposed to be the
> Binding URI. It has nothing to do with the target namespace. You don't 
> want
> to be passing anything in there I'm guessing :-) So just make it null.
>
I guess, I was only guessing?

You think, maybe problems like this might be alleviated by documentation?

Oh, I forgot about "Comment rot"!

How about naming the parameter "bindingURI"?

I'd still like to know how I figure out the "configuration" name of the 
Http-destination from this call.

Cheers,
-Polar

> - Dan
>
> On 4/2/07, Polar Humenn <ph...@iona.com> wrote:
>>
>> Dan Diephouse wrote:
>> > Hi Polar,
>> >
>> > On 4/2/07, Polar Humenn <ph...@iona.com> wrote:
>> >>
>> >> Hi Dan,
>> >>
>> >> I was wondering if you could answer me a question. I'm writing a
>> systest
>> >> for HTTP/S. Setting up servers always is a problem, because I never
>> know
>> >> where things are coming from. So, maybe you can straighten me out 
>> where
>> >> things have to be.
>> >>
>> >> I have placed a "greeting.wsdl" file in
>> >> test-classes/org/apache/cxf/transport/http/resources/ and use that in
>> >> the client side in new
>> SOAPService(getResource("resources/greeting.wsdl,
>> >> serviceName).
>> >>
>> >> However, setting up the servers I now keep getting something that 
>> isn't
>> >> working (i did an svn update). Now, my wsdl which has a target
>> namespace
>> >> of "http://apace.org/hello_world/" cant seem to be found from the
>> >> JaxWsServerFactoryBean.createBindingInfo() call.
>> >
>> >
>> > Any chance you can attach your test case and/or wsdl?
>> >
>> > It appears to me that there is an elaborate namespace search going on
>> >> somewhere, but I haven't a clue what backdoor it's going through.
>> >> insight?
>> >
>> >
>> > createBindingInfo attempts to look up a BindingFactory based on the
>> > namespace of the binding in the wsdl. It then uses this to create a
>> > Binding
>> > object.
>> >
>> > Also, something gets generated, but I don't know when, and merely that
>> >> this was working before, means I did something unconventional and
>> forgot
>> >> about it, and/or that they are generated in a standard place I don't
>> >> know about and perhaps it was just conincidental and now
>> changed.  Could
>> >> this be in "testutils"?
>> >
>> >
>> > I'm lost... are you wondering where your client is being generated?
>>
>> You're not the only one! :)
>>
>> I'm not really talking about the client. I'm talking about the
>> server/Endpoint side.
>> I though I had to pay attention to the  annotations in the
>> GreeterImpl.java, which is also attached. My server is brought up by the
>> code in Server.java, also attached.
>>
>> > you added the wsdl to testutils, then yes thats where its being
>> > generated.
>> > Although you seem to have your wsdl in the http module itself?
>> >
>>
>> Well, I do, because that's the only place I am under the impression I
>> can definitively find it in the code using a
>> getClass().getResource("resources/greeting.wsdl").
>>
>> I imagine, if I have things with different namespaces, I might have to
>> get Maven to generate these things with a wsdl2java tool.
>>
>> My question is, what are the locations are these things picked up at,
>> and how do I get any assurance that I'm not picking up somebody elses
>> definitions? Or that I'm overriding, stepping on, some other important
>> definitions?
>>
>> > I have a specific greeting.wsdl, because I only wanted to implement a
>> >> minimal "Greeter", and I have addressing information in the wsdl 
>> file,
>> >> which seems like the only way I can get the right thing configured 
>> with
>> >> a service.getPort(QName,class);
>> >>
>> >
>> > What were you doing before?
>> >
>>
>> It just worked. I was mystified.
>>
>> > - Dan
>>
>>
>>
>
>

Re: Backdoors

[Dan Diephouse <da...@envoisolutions.com>]

The problem is this line:

        EndpointImpl ep =
            new EndpointImpl(
                    getBus(),
                    implementor1,
                    "http://apache.org/hello_world",
                    this.getClass().getResource("resources/greeting.wsdl"));

Before we were ignoring the 3rd paramter - which is supposed to be the
Binding URI. It has nothing to do with the target namespace. You don't want
to be passing anything in there I'm guessing :-) So just make it null.

- Dan

On 4/2/07, Polar Humenn <ph...@iona.com> wrote:
>
> Dan Diephouse wrote:
> > Hi Polar,
> >
> > On 4/2/07, Polar Humenn <ph...@iona.com> wrote:
> >>
> >> Hi Dan,
> >>
> >> I was wondering if you could answer me a question. I'm writing a
> systest
> >> for HTTP/S. Setting up servers always is a problem, because I never
> know
> >> where things are coming from. So, maybe you can straighten me out where
> >> things have to be.
> >>
> >> I have placed a "greeting.wsdl" file in
> >> test-classes/org/apache/cxf/transport/http/resources/ and use that in
> >> the client side in new
> SOAPService(getResource("resources/greeting.wsdl,
> >> serviceName).
> >>
> >> However, setting up the servers I now keep getting something that isn't
> >> working (i did an svn update). Now, my wsdl which has a target
> namespace
> >> of "http://apace.org/hello_world/" cant seem to be found from the
> >> JaxWsServerFactoryBean.createBindingInfo() call.
> >
> >
> > Any chance you can attach your test case and/or wsdl?
> >
> > It appears to me that there is an elaborate namespace search going on
> >> somewhere, but I haven't a clue what backdoor it's going through.
> >> insight?
> >
> >
> > createBindingInfo attempts to look up a BindingFactory based on the
> > namespace of the binding in the wsdl. It then uses this to create a
> > Binding
> > object.
> >
> > Also, something gets generated, but I don't know when, and merely that
> >> this was working before, means I did something unconventional and
> forgot
> >> about it, and/or that they are generated in a standard place I don't
> >> know about and perhaps it was just conincidental and now
> changed.  Could
> >> this be in "testutils"?
> >
> >
> > I'm lost... are you wondering where your client is being generated?
>
> You're not the only one! :)
>
> I'm not really talking about the client. I'm talking about the
> server/Endpoint side.
> I though I had to pay attention to the  annotations in the
> GreeterImpl.java, which is also attached. My server is brought up by the
> code in Server.java, also attached.
>
> > you added the wsdl to testutils, then yes thats where its being
> > generated.
> > Although you seem to have your wsdl in the http module itself?
> >
>
> Well, I do, because that's the only place I am under the impression I
> can definitively find it in the code using a
> getClass().getResource("resources/greeting.wsdl").
>
> I imagine, if I have things with different namespaces, I might have to
> get Maven to generate these things with a wsdl2java tool.
>
> My question is, what are the locations are these things picked up at,
> and how do I get any assurance that I'm not picking up somebody elses
> definitions? Or that I'm overriding, stepping on, some other important
> definitions?
>
> > I have a specific greeting.wsdl, because I only wanted to implement a
> >> minimal "Greeter", and I have addressing information in the wsdl file,
> >> which seems like the only way I can get the right thing configured with
> >> a service.getPort(QName,class);
> >>
> >
> > What were you doing before?
> >
>
> It just worked. I was mystified.
>
> > - Dan
>
>
>


-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: Backdoors

[Polar Humenn <ph...@iona.com>]

Dan Diephouse wrote:
> Hi Polar,
>
> On 4/2/07, Polar Humenn <ph...@iona.com> wrote:
>>
>> Hi Dan,
>>
>> I was wondering if you could answer me a question. I'm writing a systest
>> for HTTP/S. Setting up servers always is a problem, because I never know
>> where things are coming from. So, maybe you can straighten me out where
>> things have to be.
>>
>> I have placed a "greeting.wsdl" file in
>> test-classes/org/apache/cxf/transport/http/resources/ and use that in
>> the client side in new SOAPService(getResource("resources/greeting.wsdl,
>> serviceName).
>>
>> However, setting up the servers I now keep getting something that isn't
>> working (i did an svn update). Now, my wsdl which has a target namespace
>> of "http://apace.org/hello_world/" cant seem to be found from the
>> JaxWsServerFactoryBean.createBindingInfo() call.
>
>
> Any chance you can attach your test case and/or wsdl?
>
> It appears to me that there is an elaborate namespace search going on
>> somewhere, but I haven't a clue what backdoor it's going through. 
>> insight?
>
>
> createBindingInfo attempts to look up a BindingFactory based on the
> namespace of the binding in the wsdl. It then uses this to create a 
> Binding
> object.
>
> Also, something gets generated, but I don't know when, and merely that
>> this was working before, means I did something unconventional and forgot
>> about it, and/or that they are generated in a standard place I don't
>> know about and perhaps it was just conincidental and now changed.  Could
>> this be in "testutils"?
>
>
> I'm lost... are you wondering where your client is being generated? 

You're not the only one! :)

I'm not really talking about the client. I'm talking about the 
server/Endpoint side.
I though I had to pay attention to the  annotations in the 
GreeterImpl.java, which is also attached. My server is brought up by the 
code in Server.java, also attached.

> you added the wsdl to testutils, then yes thats where its being 
> generated.
> Although you seem to have your wsdl in the http module itself?
>

Well, I do, because that's the only place I am under the impression I 
can definitively find it in the code using a 
getClass().getResource("resources/greeting.wsdl").

I imagine, if I have things with different namespaces, I might have to 
get Maven to generate these things with a wsdl2java tool.

My question is, what are the locations are these things picked up at, 
and how do I get any assurance that I'm not picking up somebody elses 
definitions? Or that I'm overriding, stepping on, some other important 
definitions?

> I have a specific greeting.wsdl, because I only wanted to implement a
>> minimal "Greeter", and I have addressing information in the wsdl file,
>> which seems like the only way I can get the right thing configured with
>> a service.getPort(QName,class);
>>
>
> What were you doing before?
>

It just worked. I was mystified.

> - Dan

Re: Backdoors

[Dan Diephouse <da...@envoisolutions.com>]

Hi Polar,

On 4/2/07, Polar Humenn <ph...@iona.com> wrote:
>
> Hi Dan,
>
> I was wondering if you could answer me a question. I'm writing a systest
> for HTTP/S. Setting up servers always is a problem, because I never know
> where things are coming from. So, maybe you can straighten me out where
> things have to be.
>
> I have placed a "greeting.wsdl" file in
> test-classes/org/apache/cxf/transport/http/resources/ and use that in
> the client side in new SOAPService(getResource("resources/greeting.wsdl,
> serviceName).
>
> However, setting up the servers I now keep getting something that isn't
> working (i did an svn update). Now, my wsdl which has a target namespace
> of "http://apace.org/hello_world/" cant seem to be found from the
> JaxWsServerFactoryBean.createBindingInfo() call.


Any chance you can attach your test case and/or wsdl?

It appears to me that there is an elaborate namespace search going on
> somewhere, but I haven't a clue what backdoor it's going through. insight?


createBindingInfo attempts to look up a BindingFactory based on the
namespace of the binding in the wsdl. It then uses this to create a Binding
object.

Also, something gets generated, but I don't know when, and merely that
> this was working before, means I did something unconventional and forgot
> about it, and/or that they are generated in a standard place I don't
> know about and perhaps it was just conincidental and now changed.  Could
> this be in "testutils"?


I'm lost... are you wondering where your client is being generated? Well if
you added the wsdl to testutils, then yes thats where its being generated.
Although you seem to have your wsdl in the http module itself?

I have a specific greeting.wsdl, because I only wanted to implement a
> minimal "Greeter", and I have addressing information in the wsdl file,
> which seems like the only way I can get the right thing configured with
> a service.getPort(QName,class);
>

What were you doing before?

- Dan
-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Backdoors

[Polar Humenn <ph...@iona.com>]

Hi Dan,

I was wondering if you could answer me a question. I'm writing a systest 
for HTTP/S. Setting up servers always is a problem, because I never know 
where things are coming from. So, maybe you can straighten me out where 
things have to be.

I have placed a "greeting.wsdl" file in 
test-classes/org/apache/cxf/transport/http/resources/ and use that in 
the client side in new SOAPService(getResource("resources/greeting.wsdl, 
serviceName).

However, setting up the servers I now keep getting something that isn't 
working (i did an svn update). Now, my wsdl which has a target namespace 
of "http://apace.org/hello_world/" cant seem to be found from the 
JaxWsServerFactoryBean.createBindingInfo() call.

It appears to me that there is an elaborate namespace search going on 
somewhere, but I haven't a clue what backdoor it's going through. insight?

Also, something gets generated, but I don't know when, and merely that 
this was working before, means I did something unconventional and forgot 
about it, and/or that they are generated in a standard place I don't 
know about and perhaps it was just conincidental and now changed.  Could 
this be in "testutils"?

I have a specific greeting.wsdl, because I only wanted to implement a 
minimal "Greeter", and I have addressing information in the wsdl file, 
which seems like the only way I can get the right thing configured with 
a service.getPort(QName,class);

Cheers,
-Polar

Re: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]

[Dan Diephouse <da...@envoisolutions.com>]

On 4/2/07, Polar Humenn <ph...@iona.com> wrote:
>
> Dan Diephouse wrote:
>
> > So now all the users need to check to see if this flag is enabled?
> >
> > We already have isGET which seriously gets on my nerves. Why should
> > people
> > be checking these flags all the time?
>
>
> yeah, what's that about? in AbstractPhaseInterceptor? Right?
> Why is HTTP functionality in an interceptor at all?


I totally agree. There is a long thread here about it if you have spare
time:

http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200611.mbox/%3c7b774c950611291103y68c2fa70qe05c88d2865d5e71@mail.gmail.com%3e

I may try to see if I can get rid of this sometime before our release yet.


- Dan

-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]

[Polar Humenn <ph...@iona.com>]

Dan Diephouse wrote:
> On 4/2/07, Glynn, Eoghan <eo...@iona.com> wrote:
>>
>>
>>
>> OK I'm going to take one last shot at clarifying this use-case ... deep
>> breath :)
>>
>> You've set me a *lot* of questions (nobody expects the spanish
>> inquisition :), so please excuse the brevity of my answers as I've
>> already burned a lot of time on this, and I don't have much more to
>> spare ...
>
>
> You and me both. Its not fun, but its part of the Apache process.
>
>> Say I enable WS-Security - what mechanisms would there be to
>> > determine that it should not be run for the local invocation
>> > case?
>>
>>
>> The interceptors are simply by-passed. We can do this without
>> introducing a security hole as its all happening with the local process
>> space. So trust is implied.
>>
>> However we can mark the Message via a property as originating from
>> within the local process space. So that logical-level security
>> interceptors on the receiving side can make decisions on that basis.
>>
>> But we wouldn't force the intensely paranoid to use this mechanism if
>> they find the by-passing of security to be objectionable ... i.e. the
>> application developer/deployer would have to make a conscious decision
>> to enable this adaptive behavior.
>
>
> So now all the users need to check to see if this flag is enabled?
>
> We already have isGET which seriously gets on my nerves. Why should 
> people
> be checking these flags all the time?


yeah, what's that about? in AbstractPhaseInterceptor? Right? 
Why is HTTP functionality in an interceptor at all?

  

>
>> If a server requires HTTP security, will we just bypass it?
>>
>>
>> Yes. Trust is implied.
>
>
> I don't agree. Here is a better scenario. Acme industries has an a 
> service
> which gives detailed financial information of users. Due to security
> restrictions only certain applications & developers have access to this
> financial information. Trust is authenticated on the basis of  
> pub/private
> keys. If we have a client application running in the local process space
> which is not authenticated, then your scenario would implicitly grant 
> it. (I
> have seen such a scenario BTW)

These boundaries are all artificial.  One can make the same argument 
that since all processes run on the same machine that trust *is* be 
implied. Sure trust "can" be implied, but it's not a definite.

And it's not always the "trust" that is important, but more lower level 
details, like the proof of the validity of certificates, keys, and their 
use.


Cheers,
-Polar

>> 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.
>
>
>> =
>> > [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??? 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?
>
>> b) Will have some major affects on how their service is
>> > invoked and possibly some security issues. It sounds like the
>> > user should make a conscious decision about whether or not to use it.
>>
>>
>> Yep, of course they should. And they would do so by configuring an extra
>> interceptor into the chain to drive this. Which would have the effect of
>> using an optimized form of dispatch *if and only if* the target happens
>> to currently exist in the local process space. If, on the other hand,
>> the target really is remote, then the normal route is followed.
>
>
> Doesn't this violate your goal of not having the user make any static
> changes at all?
>
>
>> > d) Does not implicitly require that we ditch
>> > Conduits/Destinations for in this type of in process
>> > dispatching (if you agree to b, I think this follows
>> > relatively easily. Proposed solution below.)
>>
>>
>> It doesn't *require* that we "ditch Conduits/Destinations". Its just a
>> different way of doing it. It might not be the way you would have chosen
>> to implement it, but remember ... broad church, diversity of ideas and
>> all that ...
>
>
>
> 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.
>
> - Dan
>

RE: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]

["Glynn, Eoghan" <eo...@iona.com>]

> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org] 
> Sent: 03 April 2007 00:44
> To: cxf-dev@incubator.apache.org
> Subject: Re: In Process Dispatch [was Re: [PROPOSAL] Client 
> and Conduit changes]
> 
> 
> I just want to chime in hear and say I completely agree with 
> most of what Dan is saying.
>
> First off, I don't see any way in which we can reliably 
> detect whether we 
> can "automatically" wire up the co-located case.   We have multiple 
> frontends (jaxws, simple, javascript, more to come) and multiple 
> databindings (aegis, jaxb, e4x, more to come).   Not only 
> that, but the 
> ones we do support have several customization options that can easily 
> make it that code generated for the client won't work against 
> a server.    
> One example is the mime bindings.   A server that just deals with a 
> database or files or something may prefer to just keep the byte[] for 
> the mime types.   The client, on the other hand, may prefer Source 
> objects or something.   The customizations allow that. 
> 
> With JAX-WS, pretty much everything is customizable.   The 
> package names, 
> the classnames, the method names, the classnames for the 
> faults, etc...    
> Anyway, trying to detect all that will NOT be fun.   Having the user 
> specify that that know it will work is, IMO, the better way to go.


Sure, there are lots of degrees of freedom. But I'd wager that it would
be a *very common* case that not only is the same data binding used on
both sides, but also this common data binding is customized in the same
way. For the other cases, i.e. a data binding mismatch, then obviously
all bets are off for just passing the raw Java objects.


> Second, in JSEE/Java world, you DON'T generally secure the 
> boundary of 
> the VM.  You Secure the boundary of the Service.   Each 
> service in the 
> VM can/may have it's own security settings and such.    By 
> bypassing the 
> security stuff, one service automatically would inherit the 
> security of 
> a different service.   I am DEFINITELY not comfortable with that.   
> Again, if the user specifically says "I want it to do that", maybe.   
> But definitely not automatically.


I've pointed out several times on the preceding threads that this is
DEFINITELY not an automatic thing. Rather its an adaptive thing.

You've read the preceding threads, right?

The interceptor that drives it must be explicitly engaged. So if you
don't want this feature, you don't have to have it. Period.

That being said, I would also question your assertion that the
boundaries of the VM need not be secured. Sure, the process space can be
partitioned so that different security polices are applied to be to
different components. But that is *not* that same thing as allowing any
old (possibly subversive) code run in the VM. Otherwise the most
simple-minded DenialofService attack ... while(true)
myMemoryWastingList.add(new byte[1024*1024]); ... could render the
entire VM a useless bag of OutOfMemoryErrors.


> In regards to the "up front" or "delayed" Conduit creation... 
>   I really 
> don't care.   That said, a user definitely needs to be able to call 
> something akin to client.getConduit().configure(...) to 
> configure things.  XML based config is definitely not for everyone.


Again, I pointed several times in the preceding threads that this
mechanism can easily accommodate the "programmatically access the
Conduit from the Client" use-case. There's a big difference between
allowing application access to the Conduit and mandating that Conduits
*must always* be created up front in order to support that. 


> Eoghan: question for you: If you DO want an "Automatic" 
> thing, could the 
> EndpointReferenceType resolution pluginny thing you added accomplish 
> that? 


Well, that's not the intention of EPR resolution. The touch-point being
used for the co-located detection is an interceptor. That interceptor
has all the info it needs available to it. And the flexibility to modify
the trailing interceptor chain on the fly.


> Couldn't it detect if it's co-located and return a ERT 
> that sets 
> up an "ObjectBinding" and "LocalConduit" combination?  Yes, that's 
> an "upfront" resolution, not per-invocation, but with how 
> expensive that 
> detection is going to be (see the above databinding 
> discussion), I don't 
> think we want it per-invocation anyway.


The result of the detection could be cached so that it doesn't
necessarily have to be fully repeated for subsequent invocations.

/Eoghan

 
> Anyway, that's my quick thoughts.
> 
> Dan

Re: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]

[Daniel Kulp <dk...@apache.org>]

I just want to chime in hear and say I completely agree with most of what 
Dan is saying.

First off, I don't see any way in which we can reliably detect whether we 
can "automatically" wire up the co-located case.   We have multiple 
frontends (jaxws, simple, javascript, more to come) and multiple 
databindings (aegis, jaxb, e4x, more to come).   Not only that, but the 
ones we do support have several customization options that can easily 
make it that code generated for the client won't work against a server.    
One example is the mime bindings.   A server that just deals with a 
database or files or something may prefer to just keep the byte[] for 
the mime types.   The client, on the other hand, may prefer Source 
objects or something.   The customizations allow that. 

With JAX-WS, pretty much everything is customizable.   The package names, 
the classnames, the method names, the classnames for the faults, etc...    
Anyway, trying to detect all that will NOT be fun.   Having the user 
specify that that know it will work is, IMO, the better way to go.


Second, in JSEE/Java world, you DON'T generally secure the boundary of 
the VM.  You Secure the boundary of the Service.   Each service in the 
VM can/may have it's own security settings and such.    By bypassing the 
security stuff, one service automatically would inherit the security of 
a different service.   I am DEFINITELY not comfortable with that.   
Again, if the user specifically says "I want it to do that", maybe.   
But definitely not automatically.


In regards to the "up front" or "delayed" Conduit creation...   I really 
don't care.   That said, a user definitely needs to be able to call 
something akin to client.getConduit().configure(...) to configure 
things.  XML based config is definitely not for everyone.


Eoghan: question for you: If you DO want an "Automatic" thing, could the 
EndpointReferenceType resolution pluginny thing you added accomplish 
that?  Couldn't it detect if it's co-located and return a ERT that sets 
up an "ObjectBinding" and "LocalConduit" combination?  Yes, that's 
an "upfront" resolution, not per-invocation, but with how expensive that 
detection is going to be (see the above databinding discussion), I don't 
think we want it per-invocation anyway.

Anyway, that's my quick thoughts.

Dan



On Monday 02 April 2007 12:10, Dan Diephouse wrote:
> On 4/2/07, Glynn, Eoghan <eo...@iona.com> wrote:
> > OK I'm going to take one last shot at clarifying this use-case ...
> > deep breath :)
> >
> > You've set me a *lot* of questions (nobody expects the spanish
> > inquisition :), so please excuse the brevity of my answers as I've
> > already burned a lot of time on this, and I don't have much more to
> > spare ...
>
> You and me both. Its not fun, but its part of the Apache process.
>
> > Say I enable WS-Security - what mechanisms would there be to
> >
> > > determine that it should not be run for the local invocation
> > > case?
> >
> > The interceptors are simply by-passed. We can do this without
> > introducing a security hole as its all happening with the local
> > process space. So trust is implied.
> >
> > However we can mark the Message via a property as originating from
> > within the local process space. So that logical-level security
> > interceptors on the receiving side can make decisions on that basis.
> >
> > But we wouldn't force the intensely paranoid to use this mechanism
> > if they find the by-passing of security to be objectionable ... i.e.
> > the application developer/deployer would have to make a conscious
> > decision to enable this adaptive behavior.
>
> So now all the users need to check to see if this flag is enabled?
>
> We already have isGET which seriously gets on my nerves. Why should
> people be checking these flags all the time?
>
> > If a server requires HTTP security, will we just bypass it?
> >
> >
> > Yes. Trust is implied.
>
> I don't agree. Here is a better scenario. Acme industries has an a
> service which gives detailed financial information of users. Due to
> security restrictions only certain applications & developers have
> access to this financial information. Trust is authenticated on the
> basis of  pub/private keys. If we have a client application running in
> the local process space which is not authenticated, then your scenario
> would implicitly grant it. (I have seen such a scenario BTW)
>
> > 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.
>
> > =
> >
> > > [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??? 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?
>
> > b) Will have some major affects on how their service is
> >
> > > invoked and possibly some security issues. It sounds like the
> > > user should make a conscious decision about whether or not to use
> > > it.
> >
> > Yep, of course they should. And they would do so by configuring an
> > extra interceptor into the chain to drive this. Which would have the
> > effect of using an optimized form of dispatch *if and only if* the
> > target happens to currently exist in the local process space. If, on
> > the other hand, the target really is remote, then the normal route
> > is followed.
>
> Doesn't this violate your goal of not having the user make any static
> changes at all?
>
> > > d) Does not implicitly require that we ditch
> > > Conduits/Destinations for in this type of in process
> > > dispatching (if you agree to b, I think this follows
> > > relatively easily. Proposed solution below.)
> >
> > It doesn't *require* that we "ditch Conduits/Destinations". Its just
> > a different way of doing it. It might not be the way you would have
> > chosen to implement it, but remember ... broad church, diversity of
> > ideas and all that ...
>
> 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.
>
> - 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: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]

["Glynn, Eoghan" <eo...@iona.com>]

 

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: 02 April 2007 17:11
> To: cxf-dev@incubator.apache.org
> Subject: Re: In Process Dispatch [was Re: [PROPOSAL] Client 
> and Conduit changes]
> 
> On 4/2/07, Glynn, Eoghan <eo...@iona.com> wrote:
> >
> >
> >
> > OK I'm going to take one last shot at clarifying this use-case ... 
> > deep breath :)
> >
> > You've set me a *lot* of questions (nobody expects the spanish 
> > inquisition :), so please excuse the brevity of my answers as I've 
> > already burned a lot of time on this, and I don't have much more to 
> > spare ...
> 
> 
> You and me both. Its not fun, but its part of the Apache process.
>
> > Say I enable WS-Security - what mechanisms would there be to
> > > determine that it should not be run for the local invocation case?
> >
> >
> > The interceptors are simply by-passed. We can do this without 
> > introducing a security hole as its all happening with the local 
> > process space. So trust is implied.
> >
> > However we can mark the Message via a property as originating from 
> > within the local process space. So that logical-level security 
> > interceptors on the receiving side can make decisions on that basis.
> >
> > But we wouldn't force the intensely paranoid to use this 
> mechanism if 
> > they find the by-passing of security to be objectionable 
> ... i.e. the 
> > application developer/deployer would have to make a 
> conscious decision 
> > to enable this adaptive behavior.
> 
> 
> So now all the users need to check to see if this flag is enabled?


All users do not need to check if this is enabled. Just the interceptor
that does the adaptive diversion. The existance of this interceptor in
the chain is the "flag" in that sense.

 
> 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.


> > If a server requires HTTP security, will we just bypass it?
> >
> >
> > Yes. Trust is implied.
> 
> 
> I don't agree. Here is a better scenario. Acme industries has 
> an a service which gives detailed financial information of 
> users. Due to security restrictions only certain applications 
> & developers have access to this financial information. Trust 
> is authenticated on the basis of  pub/private keys. If we 
> have a client application running in the local process space 
> which is not authenticated, then your scenario would 
> implicitly grant it. (I have seen such a scenario BTW)


Exactly. Trust is implied. So the unauthenticated client application
running in the local process space is implicitly authenticated. That's
exactly the intention. And this has been run by the in-house security
experts, so I'm not just speaking as a layman here.

Obviously only to be used where the boundaries of the process are
secure. Which I'd imagine is a sortta basic prereq for a secure
application, no? 

I mean you wouldn't call a tomcat deployment "secure" if any old Tom,
Dick or Harry could just cp anything they liked to the webapps dir, or?

You could think of it like a regional airport. No need for passport
control as only domestic flights are arriving and leaving. So we assume
the passengers are either native to the country, or underwent passport
control earlier when they entered the country at an international
airport. Of course this assumes the country's borders are secure.

Anyway just a dumb analogy. Lets not get bogged down on how airport
security really works in these days of shoe-checking :)

If the "secure process borders" condition doesn't hold, then this
mechanism shouldn't be used.


> > 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.


> > > [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.

 
> > b) Will have some major affects on how their service is
> > > invoked and possibly some security issues. It sounds like 
> the user 
> > > should make a conscious decision about whether or not to use it.
> >
> >
> > Yep, of course they should. And they would do so by configuring an 
> > extra interceptor into the chain to drive this. Which would 
> have the 
> > effect of using an optimized form of dispatch *if and only if* the 
> > target happens to currently exist in the local process 
> space. If, on 
> > the other hand, the target really is remote, then the 
> normal route is followed.
> 
> 
> Doesn't this violate your goal of not having the user make 
> any static changes at all?


No.

The extra config simply enables the adaptive smarts.

The goal is to avoid having to make a static change to reflect the
endpoint being in the local process space, and then statically undo the
change if the endpoint migrates elsewhere.



> > > d) Does not implicitly require that we ditch 
> Conduits/Destinations 
> > > for in this type of in process dispatching (if you agree to b, I 
> > > think this follows relatively easily. Proposed solution below.)
> >
> >
> > It doesn't *require* that we "ditch Conduits/Destinations". 
> Its just a
> > different way of doing it. It might not be the way you 
> would have chosen
> > to implement it, but remember ... broad church, diversity 
> of ideas and
> > all that ...
> 
> 
> 
> 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?


> 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?

 
> 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? 

Other than the comfort factor of "hey we gotta have a binding, right?"

Of course there are always different approaches that could achieve a
similar result.

/Eoghan

Re: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]

[Dan Diephouse <da...@envoisolutions.com>]

On 4/2/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
>
> OK I'm going to take one last shot at clarifying this use-case ... deep
> breath :)
>
> You've set me a *lot* of questions (nobody expects the spanish
> inquisition :), so please excuse the brevity of my answers as I've
> already burned a lot of time on this, and I don't have much more to
> spare ...


You and me both. Its not fun, but its part of the Apache process.

> Say I enable WS-Security - what mechanisms would there be to
> > determine that it should not be run for the local invocation
> > case?
>
>
> The interceptors are simply by-passed. We can do this without
> introducing a security hole as its all happening with the local process
> space. So trust is implied.
>
> However we can mark the Message via a property as originating from
> within the local process space. So that logical-level security
> interceptors on the receiving side can make decisions on that basis.
>
> But we wouldn't force the intensely paranoid to use this mechanism if
> they find the by-passing of security to be objectionable ... i.e. the
> application developer/deployer would have to make a conscious decision
> to enable this adaptive behavior.


So now all the users need to check to see if this flag is enabled?

We already have isGET which seriously gets on my nerves. Why should people
be checking these flags all the time?

> If a server requires HTTP security, will we just bypass it?
>
>
> Yes. Trust is implied.


I don't agree. Here is a better scenario. Acme industries has an a service
which gives detailed financial information of users. Due to security
restrictions only certain applications & developers have access to this
financial information. Trust is authenticated on the basis of  pub/private
keys. If we have a client application running in the local process space
which is not authenticated, then your scenario would implicitly grant it. (I
have seen such a scenario BTW)

> 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.


> =
> > [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??? 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?

> b) Will have some major affects on how their service is
> > invoked and possibly some security issues. It sounds like the
> > user should make a conscious decision about whether or not to use it.
>
>
> Yep, of course they should. And they would do so by configuring an extra
> interceptor into the chain to drive this. Which would have the effect of
> using an optimized form of dispatch *if and only if* the target happens
> to currently exist in the local process space. If, on the other hand,
> the target really is remote, then the normal route is followed.


Doesn't this violate your goal of not having the user make any static
changes at all?


> > d) Does not implicitly require that we ditch
> > Conduits/Destinations for in this type of in process
> > dispatching (if you agree to b, I think this follows
> > relatively easily. Proposed solution below.)
>
>
> It doesn't *require* that we "ditch Conduits/Destinations". Its just a
> different way of doing it. It might not be the way you would have chosen
> to implement it, but remember ... broad church, diversity of ideas and
> all that ...



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.

- Dan

-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

RE: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]

["Glynn, Eoghan" <eo...@iona.com>]

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: 02 April 2007 18:01
> To: cxf-dev@incubator.apache.org
> Subject: Re: In Process Dispatch [was Re: [PROPOSAL] Client 
> and Conduit changes]
> 
> HI Polar,
> 
> I think for what Eoghan is proposing the Conduit retreived in 
> MessageSenderInterceptor wouldn't pick up the configuration 
> set on the Client.getConduit(). 


No, that's not the intention. 

If the Client.getConduit() API is called upfront from the application,
then this would cause the strategy to create the Conduit at that point.
A later call to strategy.getConduit() from the MessageSenderInterceptor
would generally just return that same Conduit instance. 

There would be no distinction between the calling
ConduitInitiatorStrategy.getConduit() from Client.getConduit() or from
MessageSenderInterceptor.handleMessage().

The whole point is to defer the creation the Conduit *until we know we
need it*. If the application calls Client.getConduit() upfront,
obviously we need it at that point. In the more usual case, we don't
need it until the first invocation gets as far as the
MessageSenderInterceptor.


> This would be a completely 
> new Conduit. It could need to be picked up from XML. 
> Otherwise if the user wanted to configure the Conduit itself, 
> they would need to add an interceptor to do so.
> 
> It is not clear to me what should happen from a security & 
> configuration perspective if someone overrides the endpoint, 
> a la BindingProvider.ENDPOINT_ADDRESS. It would seem to me 
> that they're telling us to use a new Conduit entirely and 
> that they will ensure that this Conduitis configured 
> correctly. Our policy mechanisms should of course still 
> enforce their checks, it just seems that the user is 
> responsible for meeting those checks. i.e. they need to still 
> set up security.


Exactly the same issue applies currently if a handler overrides the
target endpoint via BindingProvider.ENDPOINT_ADDRESS_PROPERTY in such a
way as to invalidate the effective policy set computation already done
in an earlier interceptor.

We discussed this earlier on the "Why does ClientImpl.invoke() override
the EndpointInfo address?" thread. I don't know the solution to this
issue (maybe we'd need to unwind the dispatch to allow a second round of
policy reconciliation to occur). But I don't think the problem is new,
nor particular to the current proposal.

/Eoghan

 
> I suppose a ConduitInitiatorStrategy or similar class could 
> be used for configuring any Conduit that is selected, and 
> this seems like an ok motivation for such a class - although 
> complex for API configuration. I'm not sure why this would be 
> more ideal or simple than writing an interceptor to select a 
> Conduit and configure it though. Both would need to look for 
> the endpoint address and create the Conduit and configure it, 
> so it seems rather redundant.
> 
> - Dan
> 
> On 4/2/07, Polar Humenn <ph...@iona.com> wrote:
> >
> > This is all too daunting to understand. I see some things 
> that would 
> > have to be done if the Conduit is selected at the 
> > MessageSenderInterceptor.
> >
> > Currently the client can configure the Conduit to set 
> certain contracts.
> > For instance,
> >
> > (HTTPConduit) Conduit con =
> >        (HTTPConduit) ClientProxy.getClient(proxy).getConduit();
> > con.setAuthorizationPolicy( .... );
> > con.setSslClient(.....);
> > proxy.sayHi();
> >
> > You have incurred some setup time at the creation of the client to 
> > select a conduit, then take some time to configure it (or 
> *check* its 
> > configuration), then make the invocation with some hope 
> (assurance?) 
> > that the underlying system will follow through with your 
> requirements.
> >
> > To do it another way, you would have to "invent" a policy 
> language to 
> > give the invoker some assurance that the correct Conduit will be 
> > selected/created down the road. Okay, so it looks like the 
> same thing.
> > It's about about what you want to call a conduit or a 
> "conduit policy"
> > in this case.
> >
> > However, if you go the "delayed" route then you would really need a 
> > callback mechanism to the client so that it can *check* the conduit 
> > configuration before the invocation went out.
> >
> > I'm coming from an security and assurance point of view.
> >
> > So, that's extra overhead as well.
> >
> > Cheers,
> > -Polar
> >
> > Glynn, Eoghan wrote:
> > > OK I'm going to take one last shot at clarifying this 
> use-case ... 
> > > deep breath :)
> > >
> > > You've set me a *lot* of questions (nobody expects the spanish 
> > > inquisition :), so please excuse the brevity of my 
> answers as I've 
> > > already burned a lot of time on this, and I don't have 
> much more to 
> > > spare ...
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > >> Sent: 02 April 2007 05:41
> > >> To: cxf-dev@incubator.apache.org
> > >> Subject: Re: In Process Dispatch [was Re: [PROPOSAL] Client and 
> > >> Conduit changes]
> > >>
> > >> To follow up with my own email... (feel free to cut and 
> paste into 
> > >> another message so you don't have to reply to two emails)
> > >>
> > >
> > >
> > > First I've pasted in your set of questions for your 
> previous mail ...
> > >
> > >
> > >
> > >>> Here the binding and interceptor chain would be set up 
> exactly the 
> > >>> same way, regardless of whether the target is local or
> > >>>
> > >> remote. Where
> > >>
> > >>> the target really is remote, then everything just works. If
> > >>>
> > >> the target
> > >>
> > >>> happens to be instantiated within the local process space,
> > >>>
> > >> then I want
> > >>
> > >>> to detect this and adapt accordingly, *without any static
> > >>>
> > >> changes* (to
> > >>
> > >>> config, WSDL, policies, code, whatever). Then maybe the target 
> > >>> migrates to another container instance and everything
> > >>>
> > >> reverts to work as before.
> > >>
> > >>
> > >> OK, this clarifies what you're looking to do for me 
> quite a bit. If 
> > >> you're looking to do an in process dispatch with an existing 
> > >> endpoint that has been created ( i.e. an HTTP
> > >> endpoint) that is a completely different story.
> > >>
> > >
> > >
> > > It doesn't matter if it's a HTTP endpoint, or any other transport 
> > > for that matter. We'd short-circuit the dispatch so that 
> a transport 
> > > is not involved in any capacity.
> > >
> > >
> > >
> > >> It isn't very
> > >> clear to me how the mechanics of such a thing would work.
> > >> Could you maybe supply a little more information about how you 
> > >> would see the following working:
> > >>
> > >> How would we determine if the endpoint is in the local process 
> > >> space? For instance, if I have a Client talking to an 
> HTTP Server 
> > >> endpoint, how does it know to shortcut and talk to the server 
> > >> directly?
> > >>
> > >
> > >
> > > If the endpoint has been publish()ed in the local process space, 
> > > then an interceptor can detect this via the ServerRegistry.
> > >
> > >
> > >
> > >> Would the Binding interceptors would be run?
> > >>
> > >
> > >
> > > Nope.
> > >
> > >
> > >
> > >> Would your solution require the modification of the 
> current binding 
> > >> interceptors to support auto-detection of in process dispatch?
> > >>
> > >
> > >
> > > Nope.
> > >
> > >
> > >
> > >> How do we determine which user level interceptors to run?
> > >>
> > >
> > >
> > > We'd only run "logical" interceptors, and by-pass everything from 
> > > the protocol layer on down thru' the chain.
> > >
> > >
> > >
> > >> Say I enable WS-Security - what mechanisms would there be to 
> > >> determine that it should not be run for the local 
> invocation case?
> > >>
> > >
> > >
> > > The interceptors are simply by-passed. We can do this without
> > > introducing a security hole as its all happening with the 
> local process
> > > space. So trust is implied.
> > >
> > > However we can mark the Message via a property as originating from
> > > within the local process space. So that logical-level security
> > > interceptors on the receiving side can make decisions on 
> that basis.
> > >
> > > But we wouldn't force the intensely paranoid to use this 
> mechanism if
> > > they find the by-passing of security to be objectionable 
> ... i.e. the
> > > application developer/deployer would have to make a 
> conscious decision
> > > to enable this adaptive behavior.
> > >
> > >
> > >
> > >> Or what if a user writes a transformation interceptor.
> > >> How would the transformation be performed or would it not be?
> > >>
> > >
> > >
> > > It wouldn't.
> > >
> > >
> > >
> > >> If a server requires HTTP security, will we just bypass it?
> > >>
> > >
> > >
> > > Yes. Trust is implied.
> > >
> > >
> > >
> > >> For instance, lets say that we have a website which
> > >> communicates with its backend via a soap service. The client
> > >> uses the website's username/password to authenticate against
> > >> the server. If we just bypass that authentication, that would
> > >> be a security hole.
> > >>
> > >
> > >
> > > Are you talking about a delegation of credentials 
> scenario? i.e. client
> > > -invokes-> mid-tier -invokes-> backend, where the 
> username/passwd for
> > > the first invocation are delegated onto the second leg?
> > >
> > > If so, then this can still be achieved, by passing the 
> creds via the
> > > BindingProvider.USERNAME/PASSWORD_PROPERTY or the 
> AuthorizationPolicy
> > > set on the Message.
> > >
> > > Also, if the mid-tier->backend leg is protected by HTTP 
> basic auth, then
> > > even if the creds weren't available to the mid-tier, this 
> wouldn't open
> > > a security hole. The backend should reject the forwarded 
> message with
> > > 401 or 403 or some-such.
> > >
> > >
> > >
> > >> What if the server & the client use different databindings?
> > >>
> > >
> > >
> > > Data-bindings don't come into the picture.
> > >
> > >
> > >
> > >> On the client side, when do we make the decision about
> > >> whether or not the endpoint is "in process"? During a client
> > >> creation?
> > >>
> > >
> > >
> > > No.
> > >
> > >
> > >
> > >> Or during each invocation?
> > >>
> > >
> > >
> > > Yes.
> > >
> > >
> > >
> > >> Can the decision happen mid invocation?
> > >>
> > >
> > >
> > > Well the decision would be made in an interceptor, if 
> that's what you
> > > mean by mid-invocation.
> > >
> > >
> > >
> > >> [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.
> > >
> > >
> > >
> > >> Obviously we don't want to go invoking soap interceptors for
> > >> a local dispatch.
> > >>
> > >
> > >
> > > Obviously.
> > >
> > >
> > >
> > >> b) Will have some major affects on how their service is
> > >> invoked and possibly some security issues. It sounds like the
> > >> user should make a conscious decision about whether or 
> not to use it.
> > >>
> > >
> > >
> > > Yep, of course they should. And they would do so by 
> configuring an extra
> >
> > > interceptor into the chain to drive this. Which would 
> have the effect of
> > > using an optimized form of dispatch *if and only if* the 
> target happens
> > > to currently exist in the local process space. If, on the 
> other hand,
> > > the target really is remote, then the normal route is followed.
> > >
> > > So this wouldn't be foisted on anyone. But neither does 
> the user have to
> > > *statically* choose either a local or remote style of 
> dispatch. Once
> > > they've enabled the adaptive selection mechanism, then it 
> just works.
> > >
> > >
> > >
> > >> c) Will have to make the decision about whether or not the
> > >> Client is invoking a local service or a remote service before
> > >> the interceptor chain is invoked.
> > >>
> > >
> > >
> > > I disagree.
> > >
> > >
> > >
> > >> In other words, we will
> > >> have to add logic to the Client to detect this.
> > >>
> > >
> > >
> > > Disagree, it can be done in an interceptor.
> > >
> > >
> > >
> > >> If this is
> > >> done during the interceptor chain we may already have invoked
> > >> binding interceptors.
> > >>
> > >
> > >
> > > Isn't that phases are for?
> > >
> > > We could just ensure this extra interceptor is run before any
> > > binding-level interceptors.
> > >
> > >
> > >
> > >> d) Does not implicitly require that we ditch
> > >> Conduits/Destinations for in this type of in process
> > >> dispatching (if you agree to b, I think this follows
> > >> relatively easily. Proposed solution below.)
> > >>
> > >
> > >
> > > It doesn't *require* that we "ditch 
> Conduits/Destinations". Its just a
> > > different way of doing it. It might not be the way you 
> would have chosen
> > > to implement it, but remember ... broad church, diversity 
> of ideas and
> > > all that ...
> > >
> > >
> > >
> > >> After re-reading your emails, it seems that you want to
> > >> select this at invocation time, not at client creation time.
> > >>
> > >
> > >
> > > Yes.
> > >
> > >
> > >
> > >> I don't think we can do this after the chain has been
> > >> dispatched. If we did so this would mean we change our
> > >> Bindings pretty extensively to support detection.
> > >>
> > >
> > >
> > > I don't think the bindings need to change at all.
> > >
> > >
> > >
> > >> This would
> > >> complicate binding creation and seems pretty unnecessary
> > >> since this is what bindings are for - to control how a
> > >> service is bound to a protocol. It also could be disastrous
> > >> as we might have already written part of the message.
> > >>
> > >
> > >
> > > Not if the interceptor traversal phases are used correctly.
> > >
> > >
> > >
> > >> So it seems to imply that a per invocation approach would
> > >> require changes to the ClientImpl class. If we selected that
> > >> we want to use in process dispatch via a URI or flag or some
> > >> other mechanism then we would need to find a different
> > >> binding and use that instead.
> > >>
> > >
> > >
> > > I don't think the Client needs to be involved in the 
> decision making.
> > >
> > >
> > >
> > >> I'm not sure why we wouldn't want to use a
> > >> Conduit/Destination still. They seem like a perfectly good
> > >> way to dispatch a message from a client to a service. Why
> > >> should we invent another one?
> > >>
> > >
> > >
> > > Getting as far the Conduit on the outbound chain implies 
> that we've
> > > traversed a bunch of other unnecessary stuff, the whole 
> point of the
> > > exercise being to avoid this.
> > >
> > >
> > >
> > >> Also, on the Conduit auto-init issue, if we have logic inside
> > >> ClientImpl.invoke to detect whether or not we're doing an
> > >> in-process dispatch, can't we use that same logic to
> > >> determine whether or not we should auto-create the Conduit?
> > >>
> > >
> > >
> > > Because, I don't think we need the inprocess-dispatch 
> detection logic in
> > > the Client. The whole point of an interceptor 
> architecture is to allow
> > > arbitrary "processing units" to swapped in and out of the dispatch
> > > chain.
> > >
> > >
> > >
> > >> I'm envisioning that a user sets an endpoint address of
> > >> "endpoint:fooEndpoint". We can detect that this property has
> > >> been set inside the ClientImpl and not create the Conduit. We
> > >> can create that Conduit in MessageSenderInterceptor.  The
> > >> same applies if they're using a different remote 
> endpoint as well.
> > >>
> > >
> > >
> > > The whole point is to allow apps take advantage of this 
> without any
> > > static changes (like requiring the app to set a 
> "endpoint:fooEndpoint"
> > > property).
> > >
> > >
> > >
> > >> Can you detail more about how you see the logic inside
> > >> ClientImpl chainging?
> > >>
> > >
> > >
> > > IMO the Client doesn't need to be involved in the 
> in-process dispatch
> > > detection.
> > >
> > > The only Client change required is in the conduit 
> retrieval as outlined
> > > in my "Pluggable Conduit Initiation Strategy" mail.
> > >
> > > Cheers,
> > > Eoghan
> > >
> > >
> > >
> > >> - Dan
> > >>
> > >> --
> > >> Dan Diephouse
> > >> Envoi Solutions
> > >> http://envoisolutions.com | http://netzooid.com/blog
> > >>
> > >>
> >
> >
> 
> 
> -- 
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
> 

Re: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]

[Dan Diephouse <da...@envoisolutions.com>]

HI Polar,

I think for what Eoghan is proposing the Conduit retreived in
MessageSenderInterceptor wouldn't pick up the configuration set on the
Client.getConduit(). This would be a completely new Conduit. It could need
to be picked up from XML. Otherwise if the user wanted to configure the
Conduit itself, they would need to add an interceptor to do so.

It is not clear to me what should happen from a security & configuration
perspective if someone overrides the endpoint, a la
BindingProvider.ENDPOINT_ADDRESS. It would seem to me that they're telling
us to use a new Conduit entirely and that they will ensure that this
Conduitis configured correctly. Our policy mechanisms should of course still
enforce their checks, it just seems that the user is responsible for meeting
those checks. i.e. they need to still set up security.

I suppose a ConduitInitiatorStrategy or similar class could be used for
configuring any Conduit that is selected, and this seems like an ok
motivation for such a class - although complex for API configuration. I'm
not sure why this would be more ideal or simple than writing an interceptor
to select a Conduit and configure it though. Both would need to look for the
endpoint address and create the Conduit and configure it, so it seems rather
redundant.

- Dan

On 4/2/07, Polar Humenn <ph...@iona.com> wrote:
>
> This is all too daunting to understand. I see some things that would
> have to be done if the Conduit is selected at the
> MessageSenderInterceptor.
>
> Currently the client can configure the Conduit to set certain contracts.
> For instance,
>
> (HTTPConduit) Conduit con =
>        (HTTPConduit) ClientProxy.getClient(proxy).getConduit();
> con.setAuthorizationPolicy( .... );
> con.setSslClient(.....);
> proxy.sayHi();
>
> You have incurred some setup time at the creation of the client to
> select a conduit, then take some time to configure it (or *check* its
> configuration), then make the invocation with some hope (assurance?)
> that the underlying system will follow through with your requirements.
>
> To do it another way, you would have to "invent" a policy language to
> give the invoker some assurance that the correct Conduit will be
> selected/created down the road. Okay, so it looks like the same thing.
> It's about about what you want to call a conduit or a "conduit policy"
> in this case.
>
> However, if you go the "delayed" route then you would really need a
> callback mechanism to the client so that it can *check* the conduit
> configuration before the invocation went out.
>
> I'm coming from an security and assurance point of view.
>
> So, that's extra overhead as well.
>
> Cheers,
> -Polar
>
> Glynn, Eoghan wrote:
> > OK I'm going to take one last shot at clarifying this use-case ... deep
> > breath :)
> >
> > You've set me a *lot* of questions (nobody expects the spanish
> > inquisition :), so please excuse the brevity of my answers as I've
> > already burned a lot of time on this, and I don't have much more to
> > spare ...
> >
> >
> >
> >> -----Original Message-----
> >> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> >> Sent: 02 April 2007 05:41
> >> To: cxf-dev@incubator.apache.org
> >> Subject: Re: In Process Dispatch [was Re: [PROPOSAL] Client
> >> and Conduit changes]
> >>
> >> To follow up with my own email... (feel free to cut and paste
> >> into another message so you don't have to reply to two emails)
> >>
> >
> >
> > First I've pasted in your set of questions for your previous mail ...
> >
> >
> >
> >>> Here the binding and interceptor chain would be set up exactly the
> >>> same way, regardless of whether the target is local or
> >>>
> >> remote. Where
> >>
> >>> the target really is remote, then everything just works. If
> >>>
> >> the target
> >>
> >>> happens to be instantiated within the local process space,
> >>>
> >> then I want
> >>
> >>> to detect this and adapt accordingly, *without any static
> >>>
> >> changes* (to
> >>
> >>> config, WSDL, policies, code, whatever). Then maybe the target
> >>> migrates to another container instance and everything
> >>>
> >> reverts to work as before.
> >>
> >>
> >> OK, this clarifies what you're looking to do for me quite a
> >> bit. If you're looking to do an in process dispatch with an
> >> existing endpoint that has been created ( i.e. an HTTP
> >> endpoint) that is a completely different story.
> >>
> >
> >
> > It doesn't matter if it's a HTTP endpoint, or any other transport for
> > that matter. We'd short-circuit the dispatch so that a transport is not
> > involved in any capacity.
> >
> >
> >
> >> It isn't very
> >> clear to me how the mechanics of such a thing would work.
> >> Could you maybe supply a little more information about how
> >> you would see the following working:
> >>
> >> How would we determine if the endpoint is in the local
> >> process space? For instance, if I have a Client talking to an
> >> HTTP Server endpoint, how does it know to shortcut and talk
> >> to the server directly?
> >>
> >
> >
> > If the endpoint has been publish()ed in the local process space, then an
> > interceptor can detect this via the ServerRegistry.
> >
> >
> >
> >> Would the Binding interceptors would be run?
> >>
> >
> >
> > Nope.
> >
> >
> >
> >> Would your solution require the modification of the current
> >> binding interceptors to support auto-detection of in process dispatch?
> >>
> >
> >
> > Nope.
> >
> >
> >
> >> How do we determine which user level interceptors to run?
> >>
> >
> >
> > We'd only run "logical" interceptors, and by-pass everything from the
> > protocol layer on down thru' the chain.
> >
> >
> >
> >> Say I enable WS-Security - what mechanisms would there be to
> >> determine that it should not be run for the local invocation
> >> case?
> >>
> >
> >
> > The interceptors are simply by-passed. We can do this without
> > introducing a security hole as its all happening with the local process
> > space. So trust is implied.
> >
> > However we can mark the Message via a property as originating from
> > within the local process space. So that logical-level security
> > interceptors on the receiving side can make decisions on that basis.
> >
> > But we wouldn't force the intensely paranoid to use this mechanism if
> > they find the by-passing of security to be objectionable ... i.e. the
> > application developer/deployer would have to make a conscious decision
> > to enable this adaptive behavior.
> >
> >
> >
> >> Or what if a user writes a transformation interceptor.
> >> How would the transformation be performed or would it not be?
> >>
> >
> >
> > It wouldn't.
> >
> >
> >
> >> If a server requires HTTP security, will we just bypass it?
> >>
> >
> >
> > Yes. Trust is implied.
> >
> >
> >
> >> For instance, lets say that we have a website which
> >> communicates with its backend via a soap service. The client
> >> uses the website's username/password to authenticate against
> >> the server. If we just bypass that authentication, that would
> >> be a security hole.
> >>
> >
> >
> > Are you talking about a delegation of credentials scenario? i.e. client
> > -invokes-> mid-tier -invokes-> backend, where the username/passwd for
> > the first invocation are delegated onto the second leg?
> >
> > If so, then this can still be achieved, by passing the creds via the
> > BindingProvider.USERNAME/PASSWORD_PROPERTY or the AuthorizationPolicy
> > set on the Message.
> >
> > Also, if the mid-tier->backend leg is protected by HTTP basic auth, then
> > even if the creds weren't available to the mid-tier, this wouldn't open
> > a security hole. The backend should reject the forwarded message with
> > 401 or 403 or some-such.
> >
> >
> >
> >> What if the server & the client use different databindings?
> >>
> >
> >
> > Data-bindings don't come into the picture.
> >
> >
> >
> >> On the client side, when do we make the decision about
> >> whether or not the endpoint is "in process"? During a client
> >> creation?
> >>
> >
> >
> > No.
> >
> >
> >
> >> Or during each invocation?
> >>
> >
> >
> > Yes.
> >
> >
> >
> >> Can the decision happen mid invocation?
> >>
> >
> >
> > Well the decision would be made in an interceptor, if that's what you
> > mean by mid-invocation.
> >
> >
> >
> >> [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.
> >
> >
> >
> >> Obviously we don't want to go invoking soap interceptors for
> >> a local dispatch.
> >>
> >
> >
> > Obviously.
> >
> >
> >
> >> b) Will have some major affects on how their service is
> >> invoked and possibly some security issues. It sounds like the
> >> user should make a conscious decision about whether or not to use it.
> >>
> >
> >
> > Yep, of course they should. And they would do so by configuring an extra
>
> > interceptor into the chain to drive this. Which would have the effect of
> > using an optimized form of dispatch *if and only if* the target happens
> > to currently exist in the local process space. If, on the other hand,
> > the target really is remote, then the normal route is followed.
> >
> > So this wouldn't be foisted on anyone. But neither does the user have to
> > *statically* choose either a local or remote style of dispatch. Once
> > they've enabled the adaptive selection mechanism, then it just works.
> >
> >
> >
> >> c) Will have to make the decision about whether or not the
> >> Client is invoking a local service or a remote service before
> >> the interceptor chain is invoked.
> >>
> >
> >
> > I disagree.
> >
> >
> >
> >> In other words, we will
> >> have to add logic to the Client to detect this.
> >>
> >
> >
> > Disagree, it can be done in an interceptor.
> >
> >
> >
> >> If this is
> >> done during the interceptor chain we may already have invoked
> >> binding interceptors.
> >>
> >
> >
> > Isn't that phases are for?
> >
> > We could just ensure this extra interceptor is run before any
> > binding-level interceptors.
> >
> >
> >
> >> d) Does not implicitly require that we ditch
> >> Conduits/Destinations for in this type of in process
> >> dispatching (if you agree to b, I think this follows
> >> relatively easily. Proposed solution below.)
> >>
> >
> >
> > It doesn't *require* that we "ditch Conduits/Destinations". Its just a
> > different way of doing it. It might not be the way you would have chosen
> > to implement it, but remember ... broad church, diversity of ideas and
> > all that ...
> >
> >
> >
> >> After re-reading your emails, it seems that you want to
> >> select this at invocation time, not at client creation time.
> >>
> >
> >
> > Yes.
> >
> >
> >
> >> I don't think we can do this after the chain has been
> >> dispatched. If we did so this would mean we change our
> >> Bindings pretty extensively to support detection.
> >>
> >
> >
> > I don't think the bindings need to change at all.
> >
> >
> >
> >> This would
> >> complicate binding creation and seems pretty unnecessary
> >> since this is what bindings are for - to control how a
> >> service is bound to a protocol. It also could be disastrous
> >> as we might have already written part of the message.
> >>
> >
> >
> > Not if the interceptor traversal phases are used correctly.
> >
> >
> >
> >> So it seems to imply that a per invocation approach would
> >> require changes to the ClientImpl class. If we selected that
> >> we want to use in process dispatch via a URI or flag or some
> >> other mechanism then we would need to find a different
> >> binding and use that instead.
> >>
> >
> >
> > I don't think the Client needs to be involved in the decision making.
> >
> >
> >
> >> I'm not sure why we wouldn't want to use a
> >> Conduit/Destination still. They seem like a perfectly good
> >> way to dispatch a message from a client to a service. Why
> >> should we invent another one?
> >>
> >
> >
> > Getting as far the Conduit on the outbound chain implies that we've
> > traversed a bunch of other unnecessary stuff, the whole point of the
> > exercise being to avoid this.
> >
> >
> >
> >> Also, on the Conduit auto-init issue, if we have logic inside
> >> ClientImpl.invoke to detect whether or not we're doing an
> >> in-process dispatch, can't we use that same logic to
> >> determine whether or not we should auto-create the Conduit?
> >>
> >
> >
> > Because, I don't think we need the inprocess-dispatch detection logic in
> > the Client. The whole point of an interceptor architecture is to allow
> > arbitrary "processing units" to swapped in and out of the dispatch
> > chain.
> >
> >
> >
> >> I'm envisioning that a user sets an endpoint address of
> >> "endpoint:fooEndpoint". We can detect that this property has
> >> been set inside the ClientImpl and not create the Conduit. We
> >> can create that Conduit in MessageSenderInterceptor.  The
> >> same applies if they're using a different remote endpoint as well.
> >>
> >
> >
> > The whole point is to allow apps take advantage of this without any
> > static changes (like requiring the app to set a "endpoint:fooEndpoint"
> > property).
> >
> >
> >
> >> Can you detail more about how you see the logic inside
> >> ClientImpl chainging?
> >>
> >
> >
> > IMO the Client doesn't need to be involved in the in-process dispatch
> > detection.
> >
> > The only Client change required is in the conduit retrieval as outlined
> > in my "Pluggable Conduit Initiation Strategy" mail.
> >
> > Cheers,
> > Eoghan
> >
> >
> >
> >> - Dan
> >>
> >> --
> >> Dan Diephouse
> >> Envoi Solutions
> >> http://envoisolutions.com | http://netzooid.com/blog
> >>
> >>
>
>


-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]

[Polar Humenn <ph...@iona.com>]

This is all too daunting to understand. I see some things that would 
have to be done if the Conduit is selected at the MessageSenderInterceptor.

Currently the client can configure the Conduit to set certain contracts. 
For instance,

(HTTPConduit) Conduit con =
       (HTTPConduit) ClientProxy.getClient(proxy).getConduit();
con.setAuthorizationPolicy( .... );
con.setSslClient(.....);
proxy.sayHi();

You have incurred some setup time at the creation of the client to 
select a conduit, then take some time to configure it (or *check* its 
configuration), then make the invocation with some hope (assurance?) 
that the underlying system will follow through with your requirements.

To do it another way, you would have to "invent" a policy language to 
give the invoker some assurance that the correct Conduit will be 
selected/created down the road. Okay, so it looks like the same thing. 
It's about about what you want to call a conduit or a "conduit policy" 
in this case.

However, if you go the "delayed" route then you would really need a 
callback mechanism to the client so that it can *check* the conduit 
configuration before the invocation went out.

I'm coming from an security and assurance point of view.

So, that's extra overhead as well.

Cheers,
-Polar

Glynn, Eoghan wrote:
> OK I'm going to take one last shot at clarifying this use-case ... deep
> breath :)
>
> You've set me a *lot* of questions (nobody expects the spanish
> inquisition :), so please excuse the brevity of my answers as I've
> already burned a lot of time on this, and I don't have much more to
> spare ...
>
>
>   
>> -----Original Message-----
>> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
>> Sent: 02 April 2007 05:41
>> To: cxf-dev@incubator.apache.org
>> Subject: Re: In Process Dispatch [was Re: [PROPOSAL] Client 
>> and Conduit changes]
>>
>> To follow up with my own email... (feel free to cut and paste 
>> into another message so you don't have to reply to two emails)
>>     
>
>
> First I've pasted in your set of questions for your previous mail ...
>
>
>   
>>> Here the binding and interceptor chain would be set up exactly the 
>>> same way, regardless of whether the target is local or 
>>>       
>> remote. Where 
>>     
>>> the target really is remote, then everything just works. If 
>>>       
>> the target 
>>     
>>> happens to be instantiated within the local process space, 
>>>       
>> then I want 
>>     
>>> to detect this and adapt accordingly, *without any static 
>>>       
>> changes* (to 
>>     
>>> config, WSDL, policies, code, whatever). Then maybe the target 
>>> migrates to another container instance and everything 
>>>       
>> reverts to work as before.
>>
>>
>> OK, this clarifies what you're looking to do for me quite a 
>> bit. If you're looking to do an in process dispatch with an 
>> existing endpoint that has been created (i.e. an HTTP 
>> endpoint) that is a completely different story. 
>>     
>
>
> It doesn't matter if it's a HTTP endpoint, or any other transport for
> that matter. We'd short-circuit the dispatch so that a transport is not
> involved in any capacity.
>
>
>   
>> It isn't very 
>> clear to me how the mechanics of such a thing would work. 
>> Could you maybe supply a little more information about how 
>> you would see the following working:
>>
>> How would we determine if the endpoint is in the local 
>> process space? For instance, if I have a Client talking to an 
>> HTTP Server endpoint, how does it know to shortcut and talk 
>> to the server directly?
>>     
>
>
> If the endpoint has been publish()ed in the local process space, then an
> interceptor can detect this via the ServerRegistry.
>
>  
>   
>> Would the Binding interceptors would be run?
>>     
>
>
> Nope.
>
>
>   
>> Would your solution require the modification of the current 
>> binding interceptors to support auto-detection of in process dispatch?
>>     
>
>
> Nope.
>  
>
>   
>> How do we determine which user level interceptors to run? 
>>     
>
>
> We'd only run "logical" interceptors, and by-pass everything from the
> protocol layer on down thru' the chain.
>
>
>   
>> Say I enable WS-Security - what mechanisms would there be to 
>> determine that it should not be run for the local invocation 
>> case?  
>>     
>
>
> The interceptors are simply by-passed. We can do this without
> introducing a security hole as its all happening with the local process
> space. So trust is implied.
>
> However we can mark the Message via a property as originating from
> within the local process space. So that logical-level security
> interceptors on the receiving side can make decisions on that basis. 
>
> But we wouldn't force the intensely paranoid to use this mechanism if
> they find the by-passing of security to be objectionable ... i.e. the
> application developer/deployer would have to make a conscious decision
> to enable this adaptive behavior.
>
>
>   
>> Or what if a user writes a transformation interceptor. 
>> How would the transformation be performed or would it not be?
>>     
>
>
> It wouldn't.
>
>  
>   
>> If a server requires HTTP security, will we just bypass it? 
>>     
>
>
> Yes. Trust is implied.
>
>
>   
>> For instance, lets say that we have a website which 
>> communicates with its backend via a soap service. The client 
>> uses the website's username/password to authenticate against 
>> the server. If we just bypass that authentication, that would 
>> be a security hole.
>>     
>
>
> Are you talking about a delegation of credentials scenario? i.e. client
> -invokes-> mid-tier -invokes-> backend, where the username/passwd for
> the first invocation are delegated onto the second leg? 
>
> If so, then this can still be achieved, by passing the creds via the
> BindingProvider.USERNAME/PASSWORD_PROPERTY or the AuthorizationPolicy
> set on the Message.
>
> Also, if the mid-tier->backend leg is protected by HTTP basic auth, then
> even if the creds weren't available to the mid-tier, this wouldn't open
> a security hole. The backend should reject the forwarded message with
> 401 or 403 or some-such.
>
>
>   
>> What if the server & the client use different databindings?
>>     
>
>
> Data-bindings don't come into the picture.
>
>
>   
>> On the client side, when do we make the decision about 
>> whether or not the endpoint is "in process"? During a client 
>> creation? 
>>     
>
>
> No.
>
>
>   
>> Or during each invocation? 
>>     
>
>
> Yes.
>
>
>   
>> Can the decision happen mid invocation?
>>     
>
>
> Well the decision would be made in an interceptor, if that's what you
> mean by mid-invocation.
>
>  
>   
>> [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.
>
>
>   
>> Obviously we don't want to go invoking soap interceptors for 
>> a local dispatch.
>>     
>
>
> Obviously.
>
>
>   
>> b) Will have some major affects on how their service is 
>> invoked and possibly some security issues. It sounds like the 
>> user should make a conscious decision about whether or not to use it.
>>     
>
>
> Yep, of course they should. And they would do so by configuring an extra
> interceptor into the chain to drive this. Which would have the effect of
> using an optimized form of dispatch *if and only if* the target happens
> to currently exist in the local process space. If, on the other hand,
> the target really is remote, then the normal route is followed.
>
> So this wouldn't be foisted on anyone. But neither does the user have to
> *statically* choose either a local or remote style of dispatch. Once
> they've enabled the adaptive selection mechanism, then it just works.
>
>
>   
>> c) Will have to make the decision about whether or not the 
>> Client is invoking a local service or a remote service before 
>> the interceptor chain is invoked. 
>>     
>
>
> I disagree.
>
>
>   
>> In other words, we will 
>> have to add logic to the Client to detect this. 
>>     
>
>
> Disagree, it can be done in an interceptor.
>
>
>   
>> If this is 
>> done during the interceptor chain we may already have invoked 
>> binding interceptors.
>>     
>
>
> Isn't that phases are for?
>
> We could just ensure this extra interceptor is run before any
> binding-level interceptors.
>
>
>   
>> d) Does not implicitly require that we ditch 
>> Conduits/Destinations for in this type of in process 
>> dispatching (if you agree to b, I think this follows 
>> relatively easily. Proposed solution below.)
>>     
>
>
> It doesn't *require* that we "ditch Conduits/Destinations". Its just a
> different way of doing it. It might not be the way you would have chosen
> to implement it, but remember ... broad church, diversity of ideas and
> all that ...
>
>
>   
>> After re-reading your emails, it seems that you want to 
>> select this at invocation time, not at client creation time.
>>     
>
>
> Yes.
>
>
>   
>> I don't think we can do this after the chain has been 
>> dispatched. If we did so this would mean we change our 
>> Bindings pretty extensively to support detection. 
>>     
>
>
> I don't think the bindings need to change at all.
>
>
>   
>> This would 
>> complicate binding creation and seems pretty unnecessary 
>> since this is what bindings are for - to control how a 
>> service is bound to a protocol. It also could be disastrous 
>> as we might have already written part of the message.
>>     
>
>
> Not if the interceptor traversal phases are used correctly. 
>
>  
>   
>> So it seems to imply that a per invocation approach would 
>> require changes to the ClientImpl class. If we selected that 
>> we want to use in process dispatch via a URI or flag or some 
>> other mechanism then we would need to find a different 
>> binding and use that instead.
>>     
>
>
> I don't think the Client needs to be involved in the decision making.
>
>  
>   
>> I'm not sure why we wouldn't want to use a 
>> Conduit/Destination still. They seem like a perfectly good 
>> way to dispatch a message from a client to a service. Why 
>> should we invent another one?
>>     
>
>
> Getting as far the Conduit on the outbound chain implies that we've
> traversed a bunch of other unnecessary stuff, the whole point of the
> exercise being to avoid this.
>
>  
>   
>> Also, on the Conduit auto-init issue, if we have logic inside 
>> ClientImpl.invoke to detect whether or not we're doing an 
>> in-process dispatch, can't we use that same logic to 
>> determine whether or not we should auto-create the Conduit?
>>     
>
>
> Because, I don't think we need the inprocess-dispatch detection logic in
> the Client. The whole point of an interceptor architecture is to allow
> arbitrary "processing units" to swapped in and out of the dispatch
> chain. 
>
>  
>   
>> I'm envisioning that a user sets an endpoint address of 
>> "endpoint:fooEndpoint". We can detect that this property has 
>> been set inside the ClientImpl and not create the Conduit. We 
>> can create that Conduit in MessageSenderInterceptor.  The 
>> same applies if they're using a different remote endpoint as well.
>>     
>
>
> The whole point is to allow apps take advantage of this without any
> static changes (like requiring the app to set a "endpoint:fooEndpoint"
> property).
>
>  
>   
>> Can you detail more about how you see the logic inside 
>> ClientImpl chainging?
>>     
>
>
> IMO the Client doesn't need to be involved in the in-process dispatch
> detection.
>
> The only Client change required is in the conduit retrieval as outlined
> in my "Pluggable Conduit Initiation Strategy" mail.
>
> Cheers,
> Eoghan
>
>  
>   
>> - Dan
>>
>> --
>> Dan Diephouse
>> Envoi Solutions
>> http://envoisolutions.com | http://netzooid.com/blog
>>
>>     

RE: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]

["Glynn, Eoghan" <eo...@iona.com>]

OK I'm going to take one last shot at clarifying this use-case ... deep
breath :)

You've set me a *lot* of questions (nobody expects the spanish
inquisition :), so please excuse the brevity of my answers as I've
already burned a lot of time on this, and I don't have much more to
spare ...


> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: 02 April 2007 05:41
> To: cxf-dev@incubator.apache.org
> Subject: Re: In Process Dispatch [was Re: [PROPOSAL] Client 
> and Conduit changes]
> 
> To follow up with my own email... (feel free to cut and paste 
> into another message so you don't have to reply to two emails)


First I've pasted in your set of questions for your previous mail ...


> > Here the binding and interceptor chain would be set up exactly the 
> > same way, regardless of whether the target is local or 
> remote. Where 
> > the target really is remote, then everything just works. If 
> the target 
> > happens to be instantiated within the local process space, 
> then I want 
> > to detect this and adapt accordingly, *without any static 
> changes* (to 
> > config, WSDL, policies, code, whatever). Then maybe the target 
> > migrates to another container instance and everything 
> reverts to work as before.
> 
> 
> OK, this clarifies what you're looking to do for me quite a 
> bit. If you're looking to do an in process dispatch with an 
> existing endpoint that has been created (i.e. an HTTP 
> endpoint) that is a completely different story. 


It doesn't matter if it's a HTTP endpoint, or any other transport for
that matter. We'd short-circuit the dispatch so that a transport is not
involved in any capacity.


> It isn't very 
> clear to me how the mechanics of such a thing would work. 
> Could you maybe supply a little more information about how 
> you would see the following working:
> 
> How would we determine if the endpoint is in the local 
> process space? For instance, if I have a Client talking to an 
> HTTP Server endpoint, how does it know to shortcut and talk 
> to the server directly?


If the endpoint has been publish()ed in the local process space, then an
interceptor can detect this via the ServerRegistry.

 
> Would the Binding interceptors would be run?


Nope.


> Would your solution require the modification of the current 
> binding interceptors to support auto-detection of in process dispatch?


Nope.
 

> How do we determine which user level interceptors to run? 


We'd only run "logical" interceptors, and by-pass everything from the
protocol layer on down thru' the chain.


> Say I enable WS-Security - what mechanisms would there be to 
> determine that it should not be run for the local invocation 
> case?  


The interceptors are simply by-passed. We can do this without
introducing a security hole as its all happening with the local process
space. So trust is implied.

However we can mark the Message via a property as originating from
within the local process space. So that logical-level security
interceptors on the receiving side can make decisions on that basis. 

But we wouldn't force the intensely paranoid to use this mechanism if
they find the by-passing of security to be objectionable ... i.e. the
application developer/deployer would have to make a conscious decision
to enable this adaptive behavior.


> Or what if a user writes a transformation interceptor. 
> How would the transformation be performed or would it not be?


It wouldn't.

 
> If a server requires HTTP security, will we just bypass it? 


Yes. Trust is implied.


> For instance, lets say that we have a website which 
> communicates with its backend via a soap service. The client 
> uses the website's username/password to authenticate against 
> the server. If we just bypass that authentication, that would 
> be a security hole.


Are you talking about a delegation of credentials scenario? i.e. client
-invokes-> mid-tier -invokes-> backend, where the username/passwd for
the first invocation are delegated onto the second leg? 

If so, then this can still be achieved, by passing the creds via the
BindingProvider.USERNAME/PASSWORD_PROPERTY or the AuthorizationPolicy
set on the Message.

Also, if the mid-tier->backend leg is protected by HTTP basic auth, then
even if the creds weren't available to the mid-tier, this wouldn't open
a security hole. The backend should reject the forwarded message with
401 or 403 or some-such.


> What if the server & the client use different databindings?


Data-bindings don't come into the picture.


> On the client side, when do we make the decision about 
> whether or not the endpoint is "in process"? During a client 
> creation? 


No.


> Or during each invocation? 


Yes.


> Can the decision happen mid invocation?


Well the decision would be made in an interceptor, if that's what you
mean by mid-invocation.

 
> [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.


> Obviously we don't want to go invoking soap interceptors for 
> a local dispatch.


Obviously.


> b) Will have some major affects on how their service is 
> invoked and possibly some security issues. It sounds like the 
> user should make a conscious decision about whether or not to use it.


Yep, of course they should. And they would do so by configuring an extra
interceptor into the chain to drive this. Which would have the effect of
using an optimized form of dispatch *if and only if* the target happens
to currently exist in the local process space. If, on the other hand,
the target really is remote, then the normal route is followed.

So this wouldn't be foisted on anyone. But neither does the user have to
*statically* choose either a local or remote style of dispatch. Once
they've enabled the adaptive selection mechanism, then it just works.


> c) Will have to make the decision about whether or not the 
> Client is invoking a local service or a remote service before 
> the interceptor chain is invoked. 


I disagree.


> In other words, we will 
> have to add logic to the Client to detect this. 


Disagree, it can be done in an interceptor.


> If this is 
> done during the interceptor chain we may already have invoked 
> binding interceptors.


Isn't that phases are for?

We could just ensure this extra interceptor is run before any
binding-level interceptors.


> d) Does not implicitly require that we ditch 
> Conduits/Destinations for in this type of in process 
> dispatching (if you agree to b, I think this follows 
> relatively easily. Proposed solution below.)


It doesn't *require* that we "ditch Conduits/Destinations". Its just a
different way of doing it. It might not be the way you would have chosen
to implement it, but remember ... broad church, diversity of ideas and
all that ...


> After re-reading your emails, it seems that you want to 
> select this at invocation time, not at client creation time.


Yes.


> I don't think we can do this after the chain has been 
> dispatched. If we did so this would mean we change our 
> Bindings pretty extensively to support detection. 


I don't think the bindings need to change at all.


> This would 
> complicate binding creation and seems pretty unnecessary 
> since this is what bindings are for - to control how a 
> service is bound to a protocol. It also could be disastrous 
> as we might have already written part of the message.


Not if the interceptor traversal phases are used correctly. 

 
> So it seems to imply that a per invocation approach would 
> require changes to the ClientImpl class. If we selected that 
> we want to use in process dispatch via a URI or flag or some 
> other mechanism then we would need to find a different 
> binding and use that instead.


I don't think the Client needs to be involved in the decision making.

 
> I'm not sure why we wouldn't want to use a 
> Conduit/Destination still. They seem like a perfectly good 
> way to dispatch a message from a client to a service. Why 
> should we invent another one?


Getting as far the Conduit on the outbound chain implies that we've
traversed a bunch of other unnecessary stuff, the whole point of the
exercise being to avoid this.

 
> Also, on the Conduit auto-init issue, if we have logic inside 
> ClientImpl.invoke to detect whether or not we're doing an 
> in-process dispatch, can't we use that same logic to 
> determine whether or not we should auto-create the Conduit?


Because, I don't think we need the inprocess-dispatch detection logic in
the Client. The whole point of an interceptor architecture is to allow
arbitrary "processing units" to swapped in and out of the dispatch
chain. 

 
> I'm envisioning that a user sets an endpoint address of 
> "endpoint:fooEndpoint". We can detect that this property has 
> been set inside the ClientImpl and not create the Conduit. We 
> can create that Conduit in MessageSenderInterceptor.  The 
> same applies if they're using a different remote endpoint as well.


The whole point is to allow apps take advantage of this without any
static changes (like requiring the app to set a "endpoint:fooEndpoint"
property).

 
> Can you detail more about how you see the logic inside 
> ClientImpl chainging?


IMO the Client doesn't need to be involved in the in-process dispatch
detection.

The only Client change required is in the conduit retrieval as outlined
in my "Pluggable Conduit Initiation Strategy" mail.

Cheers,
Eoghan

 
> - Dan
> 
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
> 

Re: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]

[Dan Diephouse <da...@envoisolutions.com>]

To follow up with my own email... (feel free to cut and paste into another
message so you don't have to reply to two emails)


> OK, this clarifies what you're looking to do for me quite a bit. If you're
> looking to do an in process dispatch with an existing endpoint that has been
> created (i.e. an HTTP endpoint) that is a completely different story. It
> isn't very clear to me how the mechanics of such a thing would work. Could
> you maybe supply a little more information about how you would see the
> following working:
>
> How would we determine if the endpoint is in the local process space? For
> instance, if I have a Client talking to an HTTP Server endpoint, how does it
> know to shortcut and talk to the server directly?
>


On the client side, when do we make the decision about whether or not the
> endpoint is "in process"? During a client creation? Or during each
> invocation? Can the decision happen mid invocation?
>

After re-reading your emails, it seems that you want to select this at
invocation time, not at client creation time.

I don't think we can do this after the chain has been dispatched. If we did
so this would mean we change our Bindings pretty extensively to support
detection. This would complicate binding creation and seems pretty
unnecessary since this is what bindings are for - to control how a service
is bound to a protocol. It also could be disastrous as we might have already
written part of the message.

So it seems to imply that a per invocation approach would require changes to
the ClientImpl class. If we selected that we want to use in process dispatch
via a URI or flag or some other mechanism then we would need to find a
different binding and use that instead.

I'm not sure why we wouldn't want to use a Conduit/Destination still. They
seem like a perfectly good way to dispatch a message from a client to a
service. Why should we invent another one?

Also, on the Conduit auto-init issue, if we have logic inside
ClientImpl.invoke to detect whether or not we're doing an in-process
dispatch, can't we use that same logic to determine whether or not we should
auto-create the Conduit? I'm envisioning that a user sets an endpoint
address of "endpoint:fooEndpoint". We can detect that this property has been
set inside the ClientImpl and not create the Conduit. We can create that
Conduit in MessageSenderInterceptor.  The same applies if they're using a
different remote endpoint as well.

Can you detail more about how you see the logic inside ClientImpl chainging?

- Dan

-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog