[swordfish-dev] Chat transcript 20/10/2008

[Oliver Wolf <oliver.wolf@xxxxxxxxx>]

Title: Chat transcript 20/10/2008

[START Transcript 20/10/2008]

Andreas Mattes
Here a proposal for API interfaces for interceptor chain planning: - First interfaces to be implemented by the "user" - then interfaces to be provided by Swordfish:
 
public interface InterceptorChainPlanner<T> {
void setInterceptorRegistry(InterceptorInfoRegistry registry);
List<InterceptorInfo> planInterceptorChain(T qosInfo);
Class<T> getQOSInfoClass();
}

public interface QOSInfoProvider<T> {
T createQOSInfo(MessageExchange me);
Class<T> getQOSInfoClass();
}
 
Interfaces implemented by Swordfish:
 
public interface InterceptorInfo {
String getServiceName();
String getInterceptorInstanceName();
Map<String, ?> getProperties();
}

public interface InterceptorInfoRegistry {
List<InterceptorInfo> getInterceptorInfos();
List<InterceptorInfo> getInterceptorInfosForService(String name);
}

Explanation: The InterceptorInfoRegistry holds Meta-Data for the Interceptors currently registered as OSGI-Service. It provides them as InterceptorInfo
The InterceptorInfo has two "defined" attributes, a service name which identifies what kind of processing the interceptor provides
Interceptors with the same service name are supposed to be interchangeable
 
The instance name has to be unique for interceptors with the same service name, it is just a key to distinguish between different interceptors for the same purpose

Volodymyr Zhabiuk
Let's suppose I need to implement a custom interceptor, why do I need to provide  InterceptorChainPlanner and QOSInfoProvider implementations?
Wouldn't it be sufficient to implement just org.eclipse.swordfish.Interceptor interface and to provide some metadata like ordering, etc?
Or there is something I've missed?


Andreas Mattes
No, Interceptor chain planner and interceptor implementation are completely separate. The implementor of an interceptor, as you write, has only to provide Interceptor and metadata
On the other hand, the QOSInfoProvider and InterceptorChainPlanner work together.
The QOSInfoProvider uses the current message exchange and further arbitrary information (configuration, etc.) and creates an info object which the planner must understand.
The planner then takes this info and the list of metadata of the currently registered interceptors and creates an interceptor chain. The interface returns the result of the planning as list, but I'm not sure if this is sufficient. Suggestions are welcome.

Volodymyr Zhabiuk
Why do we need a method Class<T> getQOSInfoClass(); in  InterceptorChainPlanner and  QOSInfoProvide interfaces?

Andreas Mattes
I could even imagine that the return type is left to the planner implementation and a corresponding converter interface is added which converts the result to a Camel route
These methods Class<T> get...Class(); shall be used by the Swordfish core to ensure that the collaborating components understand each other, i.e. use the same type.

Volodymyr Zhabiuk
Would it be better to have something like
public interface QOSInfoProvider<T extends QOSInfo> {
T createQOSInfo(MessageExchange me)
}
 
Where QOSInfo is the swordfish api interface?
Anyway the proposal sounds complicated

Andreas Mattes
This doesn't resolve the problem. The problem is that it is unimportant to Swordfish what the QOSInfo is, but both components must have the same understanding of it.
I'm thinking of a situation in the future where there are different implementations of planners and QOSInfoProviders in the system, and Swordfish has to decide which can work together

Volodymyr Zhabiuk
What if we change it in the following way
public interface InterceptorChainPlanner {
void setInterceptorRegistry(InterceptorInfoRegistry registry);
List<InterceptorInfo> planInterceptorChain(MessageExchange me); 
}
As for me the QOSInfoProvider is odd

Andreas Mattes
means that getting any further information is problem of the planner itself

Volodymyr Zhabiuk
yes

Andreas Mattes
ok, all message exchange related information should really be in there. - Remains the return value: What's your proposal?
Camel allows branching on conditions, do we need such feature in the plan?

Volodymyr Zhabiuk
As I understand the return value will be somehow converted to the camel context, right?

Andreas Mattes
yes

Volodymyr Zhabiuk
So if we are not taking caching into consideration, one camel context per one messageExchange?

Andreas Mattes
We may indeed consider caching - the question is if and how to support it on Planner level...
...just an idea:
 
public interface InterceptorChainPlanner<T> {
void setInterceptorRegistry(InterceptorInfoRegistry registry);
String planInterceptorChain(MessageExchange me);
List<InterceptorInfo> getPlan(String key)
}
 
now planInterceptorChain returns a key - for the same plan it's the same key
...and the plan itself is retrieved by the key

Volodymyr Zhabiuk
There is another possibility: 
The swordfish plugin developer may provide just an Interceptor interface implementation, some metadata like ordering and optionally something like http://activemq.apache.org/camel/maven/camel-core/apidocs/org/apache/camel/Predicate.html
This means that the camel context will be reconstructed only when there is an interceptor added or removed
The predicate evaluates true only if the messageExchange should be processed by the supplied interceptor
In general we should constantly fight against complexity

Oliver Wolf
@Vlad, Andreas: What do you think about the following assumptions:
1. The order of interceptor execution depends solely on the metadata (priority, pre and postcoditions, whatever) supplied by the Interceptor implementor and/or INVARIABLE external conditions.
2. Whether an interceptor needs to be executed in order to process a given message exchange depends solely on the metadata carried inside the message exchange (policy or whatever) and/or VARIABLE external conditions.
Does that sound reasonable?

Volodymyr Zhabiuk
Agree about the first statement, not sure about the second one

Oliver Wolf
what is your concern about the second statement?

Volodymyr Zhabiuk
 agree about the second one, I just didn't read it carefully

Andreas Mattes
ok, the important point of this statement is -> chain planning would be independent of the message exchange based on available interceptors and configuration data

Oliver Wolf
exactly, that's what i wanted to discuss.... if 1. is true, we can revise the plan whenever the set of interceptors changes (as volodymyr suggested). in that case we would only have one plan and no cache would be necessary. if 2. holds true, either the interceptor chain needs a way to trigger an interceptor or the interceptor needs to decide

Volodymyr Zhabiuk
we may use a kind of Predicate for this purpose

Dietmar Wolz
Oliver and I discussed the planner issue last friday and put an first proposal of the structure as org.eclipse.swordfish.planner on our svn. Its simpler than Andreas proposal by not considering interceptor instance related meta data

Andreas Mattes
one example where this may be problematic: Transformation interceptors with different detail capabilities - how would you deal with these?

Dietmar Wolz
Sorry, as I review the code: Its the other way, we have there a simple registry of interceptor instances, so no generic properties which are only dependent of the interceptor name. Do we need such generic properties?

Andreas Mattes
The question is: do we support alternative interceptors for the same task?

Dietmar Wolz
Oliver and my plan was to use Spring DM means to sort the Interceptors using an InterceptorComparator (which uses the registered meta data for the interceptor instance and meta data obtained from the exchange. To exclude specific interceptors we could indeed use some kind of predicates
And we don't need to use exchange data if we agree there is no dependence
Andreas: Do you mean alternative interceptors sharing the same meta data relevant for interceptor planning?

Andreas Mattes
yes - with differences in non-functional aspects
...but anyway this can be separated, and the interceptors are just chained: a possible example: authentication interceptors dealing with different kinds of credentials: they would be just chained, and the one who accepts the credentials performs authentication while the others just noop.

Dietmar Wolz
An instance based interceptor registry could be used together with a "interceptor name" registry, but we would avoid this complexity in the interceptor (instance) API. There could be simple Planner Implementations where a instance registry is sufficient and complex planners using a second registry
 
I propose I continue with org.eclipse.swordfish.planner aiming at a first running prototype

Andreas Mattes
ok

Dietmar Wolz
The current InterceptorRegistry interface is generic, we could use two instances, one mapping interceptor instances to properties, one mapping interceptor names to properties

Andreas Mattes
The issue is that for planning the interceptors themselves are of no use, because any decision is taken on the properties

Dietmar Wolz
public interface InterceptorRegistry<T> {

public void register(T interceptor, Map<String, ?> properties)
throws SwordfishException;

public void unregister(T interceptor, Map<String, ?> properties)
throws SwordfishException;

public Set<T> getInterceptors();

public Map<String, ?> getProperties(T interceptor);

}
As I said, the current interface is generic, we can use whatever we want as keys in the registry (including interceptor names or instances)

Andreas Mattes
However, the InterceptorRegistry is provided by Swordfish, and any planner component has to use this one.

Dietmar Wolz
One or two of them (with different key types). The dependency of planner and registry should perhaps not be part of the planner interface (but could be expressed via Spring DM and could be planner implementation specific)

Andreas Mattes
Do I understand this right: The planner will anyway get the InterceptorInstanceRegistry (with the Interceptors) but can also additionally request to get an InterceptorNameRegistry

Dietmar Wolz
More or less. I would omit the dependency from the Planner interface, but inject them into our sample planner implementation(s) via Spring-DM.

[END]

-- 
Wir bieten Trainings zu SOA:
Jetzt online auf unserer Homepage informieren und schnell buchen!
 
 
Oliver Wolf
Tel.:    +49 228-182 19059
Fax:    +49 228-182 19093
Mobil:  +49 160 98931313
oliver.wolf@xxxxxxxxxx
 
 
SOPERA GmbH - Open Source SOA
Subscription Services, Support & Maintenance, Training,
Technical SOA Consulting & Customized Development
www.sopera.com
 
SOPERA GmbH · Geschäftsführer: Dr. Ricco Deutscher, Harald Weimer, Peter Spiegel
Standort Bonn: Sträßchensweg 10 · 53113 Bonn · Handelsregister: Bonn HRB 15336
Standort München: Hohenlindnerstraße 11b · 85622 München
 
 
Vertraulichkeitshinweis: Diese Nachricht und jeder übermittelte Anhang beinhaltet vertrauliche Informationen und ist nur für die Personen oder das Unternehmen bestimmt, an welche sie tatsächlich gerichtet ist. Sollten Sie nicht der Bestimmungsempfänger sein, weisen wir Sie darauf hin, dass die Verbreitung, das (auch teilweise) Kopieren sowie der Gebrauch der empfangenen E-Mail und der darin enthaltenen Informationen gesetzlich verboten ist und gegebenenfalls Schadensersatzpflichten auslösen kann. Sollten Sie diese Nachricht aufgrund eines Übermittlungsfehlers erhalten haben, bitten wir Sie, den Sender unverzüglich hiervon in Kenntnis zu setzen.