Hi Jim, The changes sound reasonable, with a few comments.
1. Target invokers for binding.axis2, specifically on the reference side, invoke an axis2 operation client as non-blocking, and in the case of Axis2AsyncTargetInvoker, also sets up the callback target invoker given to the operation client. It's possible to combine this logic into one class but my first approach was to separate it for clarity. 3. Message ids are used only to indicate an invocation context on behalf of the axis2 binding on the service side. The call paths still manipulate it if it is present in the message but the only place where a message id is instantiated at the moment is the in-out async axis2 message receiver. Since a message id is seen as an object, the receiver could just pull the message id from the axis2 message context and use that instead of instantiating a UUID. What do you think? On 10/31/06, Jim Marino <[EMAIL PROTECTED]> wrote:
Looking into how we are going to persist callback information, I started to think about how we might simply the callback infrastructure itself to make this and dealing with the SPI easier. Here are some of the changes I propose we make: 1. Simplify o.a.t.spi.component.Reference SPI - Eliminate need for o.a.t.spi.component.Reference.createAsyncTargetInvoker(OutboundWire wire, Operation operation) by combining it with createTargetInvoker (ServiceContract contract, Operation operation) since non-blocking can be determined from the Operation. The new method could be something like createTargetInvoker(ServiceContract contract, Operation operation, OutboundWire callbackWire) - Eliminate distinction between non-blocking and blocking TargetInvoker implementations. Now that thread dispatching is done in a bridging interceptor, it may make things simpler by combining what we have split into two subclasses. I think we should look at Axis and some of the other implementations to see if this is the case or keeping the subclasses separate but having one createTargetInvoker (..) returning multiple sub-types is easier. 2. Simplify and optimize AbstractCompositeReferenceTargetInvoker hierarchy - Eliminate the need for AbstractOperationOutboundInvocationHandler.getInvocationHandler() and replace it with a protected invocation method which is overridden by subclasses. This will also eliminate OperationCallbackInvocationHandler and OperationCallbackInvocationHandler. The forward and callback TargetInvokers should obtain a handle to the head interceptor of the invocation chain they need to pass messages to when the target invokers are created (as opposed to during the invocation). In other words, the TargetInvokers should behave like specialized interceptors.This will avoid the overhead of an extra object creation on every invoke and avoid the work performed in the OperationOutboundInvocationHandler constructor, as well as simplify the class hierarchy. I think 3. Use java.util.UUID for message id creation and only create ids for callback invocations. Although a somewhat expensive operation, this will make ids cluster- and time-safe. Assuming people are O.K. with these, I'm happy to make these changes, or if others are interested, please feel free to volunteer. Jim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
