Please see my comments inline.

Thanks,
Raymond

----- Original Message ----- From: "Venkata Krishnan" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, January 31, 2008 1:37 AM
Subject: Re: Adding phase-based ordering support for invokers/interceptors in the InvocationChain


+1 for mechanism to facilitate ordering of interceptors. Also am wondering
if it would be good for each interceptor to know the ones that have been
invoked ahead of it and the ones that would be invoke after it.  This will
help us with some optimizations in cases such as when there is
PassByValueInterceptor and DataTransformationInterceptor in a chain where
I'd assume that the PassByValueInterceptor could be skipped is the data is
to undergo some transformation.

Actaully, I'm trying to avoid exposing the list of interceptors to interceptors. Most of the interceptors will be independent of each other. If there is correlation between two interceptors, I would like they share some context in the Message.


As for your proposal it seems a little complicated to me... but am going to
spend some more time to gather it.  Meanwhile a couple of questions...
- is this ordering going to be available to applications i.e. can two
different applications have different orderings of phases

No. The interceptor is not part of the application programming model. Ordering of the interceptors should be neutral to applications.

Do you have any use case in mind that different applications require different ordering of phases?

- how about a file that directly lists the various interceptors by name and
the order in which they are to be positioned

No :-). That will breaks the extensibility. The key idea here is that interceptors only have partial knowledge about its position in the invocation chain. And the Tuscany runtime will determine the ordering of phases based on these partial order.


Thanks

- Venkat

On Jan 31, 2008 12:03 AM, Raymond Feng <[EMAIL PROTECTED]> wrote:

Hi,

As of today, we can add multiple interceptors to the invocation chain, but
we cannot control their ordering. When more policies are supported, I see
a
need to provide some simple ordering mechnisim for interceptors.

SCA invocation may have three stages: reference, service and
implementation.
For example, a typical invocation chain for the reference side can be:

reference: (SourceComponent) --> DataTransformation -->
Suspend/PropagateTransaction --> ReferenceBindingInvoker --> ...
service: (ServiceBindingListener) --> DataTransformation -->
PropagateTransaction
implementation: ManagedTransaction --> ImplementationInvoker -->
(TargetComponent)

Here is my proposal:

We introduce a phase concept which groups a collection of interceptors to
a
relative position in the invocation chain for each stage. There are a list
of system defined phases (such as reference.invoker or
implementation.invoker) and it can be extended by Tuscany extensions.

Each phase is uniquely identied by the name. Each phase can define its
relative ordering using the 'before' and/or 'after' attributes. When an
interceptor is added to the InvocationChain, we can specify a phase name.
The Tuscany runtime will sort the phases by the partial order. SCA
invocations will be dispatched in the order of phases. There is no
ordering
between interceptors in the same phase.

To define a phase, we use the following simple syntax in the service
provider file named as
"META-INF/services/org.apache.tuscany.sca.core.invocation.Phase".

name=PhaseName, stage=stageName, before=PhaseName4 PhaseName5,
after=PhaseName3

name: The name of the phase
stage: The stage of the phase, it can be one of the values: reference,
service, or implemention
before: A list of phase names separated by spaces to denote this phase
should be placed before
after: A list of phase names separated by spaces to denote this phase
should
be placed after

A special phase name '*' can be used for 'before' and 'after' attribute to
represent all phases.

For example,

name=reference.invoker, stage=reference, after=*
name=reference.databinding, stage=reference, before=reference.invoker
name=reference.transaction, stage=reference, after=reference.databinding

I already have a prototype under development. Your opinions are welcome.

Thanks,
Raymond


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to