Re: Do we still need special handling of callback bindings and wires?
I missed it when it happened, but it appears that this discussion was settled (not sure where or how) in favor of not ever creating static wires for callbacks. Why is that? I have no idea what the performance cost is one way or the other, but I agree with Simon Nash that it seems a bit strange to have static wires in the forward direction and only a dynamic wire in the callback direction. Greg Dritschler On Aug 21, 2007 11:00 AM, Simon Nash <[EMAIL PROTECTED]> wrote: > Comments inline. > > Simon > > Raymond Feng wrote: > > > Comments inline. > > > > Thanks, > > Raymond > > > > - Original Message - From: "Simon Nash" <[EMAIL PROTECTED]> > > To: > > Sent: Monday, August 20, 2007 5:14 PM > > Subject: Re: Do we still need special handling of callback bindings and > > wires? > > > > > >> The short answer is Yes. The long answer follows below :-) > >> > >> I'll describe the design approach used by the code in my patch for > >> TUSCANY-1496. Things are moving rapidly in this area with Raymond's > >> work to support late binding between references and services, so some > >> of this description may need to be updated. > > > > > > It's my turn to update the discription now :-) > > > >> > >> Wires may be reference wires or service wires: > >> 1. Reference wires connect a source reference to a target binding > >> and endpoint. The source reference could be a callback service's > >> pseudo-reference. > >> 2. Service wires connect a binding endpoint to a service > implementation. > >> The service implementation could be a callback reference's > >> pseudo-service. > >> > >> Reference wires may be static or dynamic: > >> 1. A static wire targets a specific binding and endpoint (local or > >> remote). Dispatching a call down an invocation chain for this > >> wire results in a call to the statically configured binding and > >> endpoint for the wire. > >> 2. A dynamic wire targets a specific binding but an unspecified > >> endpoint. The actual target endpoint is provided at invocation > >> time. Depending on the binding type, dynamic wires may perform > >> worse than static wires, or their performance may be the same. > >> Some bindings may only support static wires. Some may only support > >> dynamic wires. Some may support both, with static wires providing > >> better performance. > > > > > > I'm not sure why you think it's the binding's job to support static or > > dynanic wire. To me, the dynamic wire needs to be bound an endpoint > > before it can used for invocations. > > > Maybe the terminology "static" and "dynamic" is confusing here. By > "static" I mean a wire that is bound to a specific target endpoint and > all invocations down that wire will go to this pre-bound endpoint. > By "dynamic" I mean a wire that is not pre-bound to a specific endpoint, > allowing each invocation down the wire to specify its target endpoint. > > Some bindings can optimize if they have have static knowledge of the > target. The local SCA binding is in this category, because static > pre-knowledge allows the source and target invocation chains to be > connected (now by means of the binding invoker), so that each invocation > becomes a direct call through pre-built invocation chains. > > Other bindings perform the same whether or not they have this static > knowledge. The Axis2 Web Service binding is in this category, because > it always creates an Axis2 operation client for each request, and it > passes the target endpoint into Axis2 as a creation parameter for the > operation client. > > Requiring all wires to be be pre-bound to a target endpoint before they > can be used for an invocation would require many more wires to be created > than is necessary. An extreme case of this is callbacks over Web Services > from multiple clients to a single service, where the service's callback > pseudo-reference should not use a separate callback wire for each client > but should have a single dynamic wire that can invoke any client endpoint. > Forcing every callback operation to create and bind a runtime wire first > is unneccessary and will incur both time and space costs. > > >> > >> Service wires are effectively always static since on the service > >> side, the binding and endpoint is known. Every service and binding > >> combination has a single service wire that
Re: Do we still need special handling of callback bindings and wires?
Comments inline. Simon Raymond Feng wrote: Comments inline. Thanks, Raymond - Original Message - From: "Simon Nash" <[EMAIL PROTECTED]> To: Sent: Monday, August 20, 2007 5:14 PM Subject: Re: Do we still need special handling of callback bindings and wires? The short answer is Yes. The long answer follows below :-) I'll describe the design approach used by the code in my patch for TUSCANY-1496. Things are moving rapidly in this area with Raymond's work to support late binding between references and services, so some of this description may need to be updated. It's my turn to update the discription now :-) Wires may be reference wires or service wires: 1. Reference wires connect a source reference to a target binding and endpoint. The source reference could be a callback service's pseudo-reference. 2. Service wires connect a binding endpoint to a service implementation. The service implementation could be a callback reference's pseudo-service. Reference wires may be static or dynamic: 1. A static wire targets a specific binding and endpoint (local or remote). Dispatching a call down an invocation chain for this wire results in a call to the statically configured binding and endpoint for the wire. 2. A dynamic wire targets a specific binding but an unspecified endpoint. The actual target endpoint is provided at invocation time. Depending on the binding type, dynamic wires may perform worse than static wires, or their performance may be the same. Some bindings may only support static wires. Some may only support dynamic wires. Some may support both, with static wires providing better performance. I'm not sure why you think it's the binding's job to support static or dynanic wire. To me, the dynamic wire needs to be bound an endpoint before it can used for invocations. Maybe the terminology "static" and "dynamic" is confusing here. By "static" I mean a wire that is bound to a specific target endpoint and all invocations down that wire will go to this pre-bound endpoint. By "dynamic" I mean a wire that is not pre-bound to a specific endpoint, allowing each invocation down the wire to specify its target endpoint. Some bindings can optimize if they have have static knowledge of the target. The local SCA binding is in this category, because static pre-knowledge allows the source and target invocation chains to be connected (now by means of the binding invoker), so that each invocation becomes a direct call through pre-built invocation chains. Other bindings perform the same whether or not they have this static knowledge. The Axis2 Web Service binding is in this category, because it always creates an Axis2 operation client for each request, and it passes the target endpoint into Axis2 as a creation parameter for the operation client. Requiring all wires to be be pre-bound to a target endpoint before they can be used for an invocation would require many more wires to be created than is necessary. An extreme case of this is callbacks over Web Services from multiple clients to a single service, where the service's callback pseudo-reference should not use a separate callback wire for each client but should have a single dynamic wire that can invoke any client endpoint. Forcing every callback operation to create and bind a runtime wire first is unneccessary and will incur both time and space costs. Service wires are effectively always static since on the service side, the binding and endpoint is known. Every service and binding combination has a single service wire that is used by the binding provider to invoke the service. For statically connected references and services (e.g., wired in SCDL, using an SCA binding, and locally accessible), static forward wires are created. The core can't fully complete the end-to-end invocation chain for the static wire, so the start methods of bindings that support local optimization (like the local SCA binding) can complete these connections using information provided by the core. Now we support the lazy creation of RuntimeWire/Invocation for a reference. I also changed the code to have the RuntimeSCABindingInvoker to delegate the call to the first invoker in the target service chain instead of trying to merge/connect the two chains together. Lazy creation is fine, as long as it does not compromise performance. I looked at some of the code that does this and I am concerned about the impact on performance (see below for more specifics). Having RuntimeSCABindingInvoker delegate to the service's invocation chain instead of linking the invocation chains seems a better approach. If the statically wired reference/service pair defines a callback interface, static wires for callback purposes are created from the pseudo-reference to the pseudo-service (this is wh
Re: Do we still need special handling of callback bindings and wires?
Comments inline. Thanks, Raymond - Original Message - From: "Simon Nash" <[EMAIL PROTECTED]> To: Sent: Monday, August 20, 2007 5:14 PM Subject: Re: Do we still need special handling of callback bindings and wires? The short answer is Yes. The long answer follows below :-) I'll describe the design approach used by the code in my patch for TUSCANY-1496. Things are moving rapidly in this area with Raymond's work to support late binding between references and services, so some of this description may need to be updated. It's my turn to update the discription now :-) Wires may be reference wires or service wires: 1. Reference wires connect a source reference to a target binding and endpoint. The source reference could be a callback service's pseudo-reference. 2. Service wires connect a binding endpoint to a service implementation. The service implementation could be a callback reference's pseudo-service. Reference wires may be static or dynamic: 1. A static wire targets a specific binding and endpoint (local or remote). Dispatching a call down an invocation chain for this wire results in a call to the statically configured binding and endpoint for the wire. 2. A dynamic wire targets a specific binding but an unspecified endpoint. The actual target endpoint is provided at invocation time. Depending on the binding type, dynamic wires may perform worse than static wires, or their performance may be the same. Some bindings may only support static wires. Some may only support dynamic wires. Some may support both, with static wires providing better performance. I'm not sure why you think it's the binding's job to support static or dynanic wire. To me, the dynamic wire needs to be bound an endpoint before it can used for invocations. Service wires are effectively always static since on the service side, the binding and endpoint is known. Every service and binding combination has a single service wire that is used by the binding provider to invoke the service. For statically connected references and services (e.g., wired in SCDL, using an SCA binding, and locally accessible), static forward wires are created. The core can't fully complete the end-to-end invocation chain for the static wire, so the start methods of bindings that support local optimization (like the local SCA binding) can complete these connections using information provided by the core. Now we support the lazy creation of RuntimeWire/Invocation for a reference. I also changed the code to have the RuntimeSCABindingInvoker to delegate the call to the first invoker in the target service chain instead of trying to merge/connect the two chains together. If the statically wired reference/service pair defines a callback interface, static wires for callback purposes are created from the pseudo-reference to the pseudo-service (this is what the code at line 503 is doing). Again, the binding's start method may perform invocation chain optimization. These static wires for use by callbacks provide an optimized callback path for cases where the target of the callback can be predicted in advance based on wiring information. For references where a static target is not always known at wiring time, a dynamic wire is created by the core. All callback pseudo-references fall into this category, as do forward references that have wiredByImpl semantics. Even callbacks that are statically wired will have a single dynamic wire in addition to their static wires. The dynamic wire is needed because there is always the chance of the callback service being called through a service reference that has used a callback object service reference to redirect the callback to a destination that could not be predicted at static wiring time. The static wires are an optimization that is likely to produce better performance when the callback destination corresponds to a static wire. When a callback is made at runtime, the invocation handler attempts to locate a static wire whose destination endpoint matches the callback destination endpoint. If one is found, this wire is used to provide best performance. If one is not found, a dynamic wire can be used if supported by the binding, or a new static wire can be constructed at runtime. Think of the collection of static wires as a cache to optimize calls to known destinations, with this cache either being partially pre-populated by the code at line 503 or built dynamically on demand as callbacks are made. On the service side, I don't think we should create static wires for references corresponding to the service callbacks at all. I updated some of the code to bind the dynamic wire to the callback endpoint in the context of an invocation. Then the dynamic wire (cloned) becomes a static wire after the target endpoint is bound. Simon, did you create the static wire
Re: Do we still need special handling of callback bindings and wires?
The short answer is Yes. The long answer follows below :-)
I'll describe the design approach used by the code in my patch for
TUSCANY-1496. Things are moving rapidly in this area with Raymond's
work to support late binding between references and services, so some
of this description may need to be updated.
Wires may be reference wires or service wires:
1. Reference wires connect a source reference to a target binding
and endpoint. The source reference could be a callback service's
pseudo-reference.
2. Service wires connect a binding endpoint to a service implementation.
The service implementation could be a callback reference's
pseudo-service.
Reference wires may be static or dynamic:
1. A static wire targets a specific binding and endpoint (local or
remote). Dispatching a call down an invocation chain for this
wire results in a call to the statically configured binding and
endpoint for the wire.
2. A dynamic wire targets a specific binding but an unspecified
endpoint. The actual target endpoint is provided at invocation
time. Depending on the binding type, dynamic wires may perform
worse than static wires, or their performance may be the same.
Some bindings may only support static wires. Some may only support
dynamic wires. Some may support both, with static wires providing
better performance.
Service wires are effectively always static since on the service
side, the binding and endpoint is known. Every service and binding
combination has a single service wire that is used by the binding
provider to invoke the service.
For statically connected references and services (e.g., wired in SCDL,
using an SCA binding, and locally accessible), static forward wires
are created. The core can't fully complete the end-to-end invocation
chain for the static wire, so the start methods of bindings that
support local optimization (like the local SCA binding) can complete
these connections using information provided by the core.
If the statically wired reference/service pair defines a callback
interface, static wires for callback purposes are created from the
pseudo-reference to the pseudo-service (this is what the code at
line 503 is doing). Again, the binding's start method may perform
invocation chain optimization. These static wires for use by callbacks
provide an optimized callback path for cases where the target of the
callback can be predicted in advance based on wiring information.
For references where a static target is not always known at wiring time,
a dynamic wire is created by the core. All callback pseudo-references
fall into this category, as do forward references that have wiredByImpl
semantics. Even callbacks that are statically wired will have a single
dynamic wire in addition to their static wires. The dynamic wire is
needed because there is always the chance of the callback service being
called through a service reference that has used a callback object
service reference to redirect the callback to a destination that could
not be predicted at static wiring time. The static wires are an
optimization that is likely to produce better performance when the
callback destination corresponds to a static wire.
When a callback is made at runtime, the invocation handler attempts to
locate a static wire whose destination endpoint matches the callback
destination endpoint. If one is found, this wire is used to provide
best performance. If one is not found, a dynamic wire can be used if
supported by the binding, or a new static wire can be constructed at
runtime. Think of the collection of static wires as a cache to optimize
calls to known destinations, with this cache either being partially
pre-populated by the code at line 503 or built dynamically on demand as
callbacks are made.
The code at line 579 has a different purpose. This is setting the
callback endpoint (pseudo-service) to pass with a forward call, so
that the target service knows where to direct any callbacks that
may occur.
Simon
Jean-Sebastien Delfino wrote:
Now that callbacks are represented as regular services/references, are
the "if (callback.) { }" on lines 503 and 579 of
CompositeActivatorImpl still necessary?
If yes, then the next question is: Why? :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Do we still need special handling of callback bindings and wires?
Now that callbacks are represented as regular services/references, are
the "if (callback.) { }" on lines 503 and 579 of
CompositeActivatorImpl still necessary?
If yes, then the next question is: Why? :)
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
