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

[Oliver Wolf <oliver.wolf@xxxxxxxxx>]

Title: Chat transcript 23/10/2008

[START Transcript 23/10/2008]

Volodymyr Zhabiuk
I have commited the refactored version of swordfish projects to the trunk. The changes include adopting modular project structure, using slf4j instead of java.util.logging, package reorganizing
old projects can be found in the branches directory
Speaking about the  planner design I'm a bit concerned in several design desicions
Regarding Hints, if a developer would like to add the Interceptor, that should only be invoked only if the messageExchange contains property SOME_PREDEFINED_PROPERTY. The HintExtractorImpl class has to be modified to extract new hints. So the swordfish-core should be changed each time the interceptor of such kind is added
Moreover we would need to modify the FilterStrategy implementation
Regarding SortingStrategyImpl and FilterRegistryImpl. Could you supply the usecase, that will dictate us to have several sorting or filtering strategies?
This affects the simplicity of our planner implementation
In a general sense, we don't need to forsee future requirements, we may just refactor the implementation when such would appear

Oliver Wolf
@volodymyr I really appeciate your endeavour to keep things simple and fight against complexity. i'm also in favour of the YAGNI principle, but to some extent you HAVE TO foresee future requirements when you try to do something that appeals to  larger community. The situation is definitely differet when yu design a software systems for a customer that serrves a specific purpose. in that case when you try to foresee future requiremets you're almost always lost because things always turn out to be different from what you expected

Volodymyr Zhabiuk
Probably some overengeneering might be reasonable, but we should be extremely careful. And if we add some extra functionality, we need to forsee the usecases that might need such features. That's why I've asked the question

Oliver Wolf
I agree completely, but I feel that all the design decisions we made were sufficiently justified. Nevertheless, I want everyone on the project to be comfortable with what we do.

Volodymyr Zhabiuk
Thanks Oliver. I just feel that sometimes we need to ask a lot of questions to find out the best decision

Dietmar Wolz
Can somone else try to build spring-osgi-1.1.2 using mvn -P equinox,it clean install
? I get the same Missing Constraint error when trying to use spring-osgi-test. Any idea?

Andrey Kopachevsky
yes, I can

Andrey Kopachevsky
can we proceed with some sequence diagram demonstrating use of our interfaces?
I mean, I also don't quite understand pourpose of some interfaces

Volodymyr Zhabiuk
HintExtractor
FilterStrategy

Dietmar Wolz
META-INF/spring/swordfish-planner.xml outlines the structure of the collaborating beans
HintExtractor is used to retrieve strategy hints out of the message exchange
the planner works in 2 phases

Volodymyr Zhabiuk
What is the strategy hint?

Dietmar Wolz
see getInterceptorChain in PlannerImpl

Dietmar Wolz
strategy hint is some Object which gives informations whether a interceptor is active or not

Volodymyr Zhabiuk
Let's suppose, some interceptor shoud be invoked only if the messageExchange contains some property, how the corresponding hint will look like?

Dietmar Wolz
the 2 phases are: 1) sorting of the registered interceptors - here only static information from properties of the interceptor are used
2) filtering of the interceptor based on interceptor properties and hints retrieved from the message exchange
the hintextractor will retrieve this info out of the properties of the exchange. A simple hint could be some flags indicating whether a specific interceptor should be used or not
FilterStrategy is associated with the 2nd phase, SortingStrategy with the 1st phase of the planning of the interceptor chain. Actually there is a 3rd phase, building a camel route out of the final chain
Volodymyr: you are right, FilterStrategy and HintExtractor are plugins which have to be adapted if the properties indicating the use of an interceptor change. How would you express this flexibility?

Volodymyr Zhabiuk
We may incorporate it into the Interceptor itself:

Dietmar Wolz
we wanted to separate this functionality from the intercepter
filter strategies are defined as
<osgi:list id="filterStrategies" interface="org.eclipse.swordfish.api.FilterStrategy"
cardinality="0..N" comparator-ref="strategyComparator">
</osgi:list>
using spring-dm

Volodymyr Zhabiuk
public class CustomInterceptor implements Interceptor, Conditional {
    public void intercept(MessageExchange me) {
   ...
   }

public boolean isApplicable(MessageExchange me) {...}
}
in such way we can easily construct the camel route

Dietmar Wolz
So they are automatically used if they are dynamically registered at the osgi registry

Volodymyr Zhabiuk
Conditional can be easily transformed to camel predicate
Understand

Dietmar Wolz
your design would tightly couple the filtering process with the interceptor implementation which we wanted to avoid
Interceptors should be completely unaware of there usage inside an interceptor chain

Volodymyr Zhabiuk
Why?
If we implement the interceptor, we know under which conditions it would be used
in your implementation the FilterStrategy is not pluggable as only one is picked up for the whole interceptorChain 
public List<Interceptor> filter(List<Interceptor> interceptors,
  ReadOnlyRegistry<Interceptor> registry, List<Hint<?>> hints) {
 List<Interceptor> sorted = null;
 for (FilterStrategy strategy: filterStrategies) {
  try {
   sorted = strategy.filter(interceptors, registry, hints);
   break; // success
  } catch (SwordfishException e) {
   continue; // try next
  }
 }
 return sorted;
}

Dietmar Wolz
this requirement is the result of our experience with the old sbb, here oliver and andreas should provide some comments when they are available again

Volodymyr Zhabiuk
ok

Dietmar Wolz
Construction if the camel route is easy using both approaches, using our approach no additional filtering is necessary -but a separate route has to be constructed for each exchange. We designed it that way under the assumption that the construction of a route is cheap - which we have to check

don't understand your comment about pluggability - Strategies are sorted using the StrategyComparator - so they have ha fixed priority. lower priorized strategies are meant only to be used in case of an exception - as fall back

Volodymyr Zhabiuk
Let's suppose, some interceptor shoud be invoked only if the messageExchange contains some property
In this case we need to inject the new HintExtractor and FilteringStrategy besides the interceptor itself, right?

Oliver Wolf
@vlad: not necessarily. consider the sopera standard case in which a policy conveyed as part of the message defines which interceptors are to be invoked. you would then have to deploy a hintextractor that knows how to extract the policy from the message exchange into a Hint<Policy> and a filtering strategy that knows how to evaluate a Hint<Policy> to figure out which intercetors to invoke

Dietmar Wolz
checked in a new version of org.eclipse.wordfish.planner - using the old structure, will later switch to use the refactored stuff. The bundle constraint problem is solved - I deleted my maven2 repository and built spring-osgi-test-1.1.2 using mvn -P equinox,it install, then I fixed problems with the pom.xml and called mvn eclipse:eclipse for the planner project. Now I am able to start building real test cases.

Volodymyr Zhabiuk
@Oliver and Dietmar: Agree, in the sopera standard case such design makes sense

Oliver Wolf
for other cases, one or the other of these concepts might seem overengineered, but if we provide built-in default strategies and don't REQUIRE people to create their own for simple cases, i think we're onthe right track

Volodymyr Zhabiuk
Allright, don't have any considerable objections

Oliver Wolf
so we can consider the design to have received complexity-police approval? 

Volodymyr Zhabiuk
:-) There is another problem, Me and Andrey have spoken already about.  Why do we need camel in the present planner design? We are instrumenting routes on the fly and they are as simple as possible, containing just a chain of interceptors
Actually we are not using camel dsl capabilities

Oliver Wolf
true..

Dietmar Wolz
I'm here. A question to Andrey: is the exception concept dependent on the use of camel routes now?

Andrey Kopachevsky
yes, but it use very basic camel error handling mechanizm
so, it can be simple replaced with some custom realization
it 2 words we have some global error handling wrapper based on camel that receive exception and send it to corresponding internal osgi service

Dietmar Wolz
Andrey, could you provide a first implementation of a simple custom route executor independent from camel?

Andrey Kopachevsky
Yes, but I need to integrate with refactored sources
or, I can just pack my local version in zip and provide it via exchange

Dietmar Wolz
ok, for us its ok if we currently skip the usage of camel and see how it works. Integration of exception handling / planner should be straigtforward
you have already something?

Andrey Kopachevsky
at the moment, I have camel based realization, I can't commit it because project source is refactored, so I can just provide it as zip
is it ok?
or, I can refactor it according volodimir latest refactor, I didn't do this because I want to do this on your planer realization base
ok, I'll provide what I have and than we can discuss, ok?

Oliver Wolf
@vlad: i looked at the new project structure.... there is one issue, though. In eclipse, project names should be the same as the bundle names, so "api" should be called "org.eclipse.swordfish.api"

Dietmar Wolz
Andrey, please save your current version and put it on the exchange, then start to build an integrated version without camel. The interfaces of the planner will not change (beside the one camel route producing method)

Andrey Kopachevsky
ok

Volodymyr Zhabiuk
@Oliver. Not a problem, the eclipse:eclipse command will create an eclipse project with the same name as the artifactId is

Dietmar Wolz
I will soon provide a first sample of a running spring dm based osgi integration test, and will switch to the refactored version later

Volodymyr Zhabiuk
artifactId for this project is org.eclipse.swordfish.api

Oliver Wolf
but the svn name should be the same

Volodymyr Zhabiuk
why?

Oliver Wolf
because this is the eclipse convention for project names 
and it makes sense IMHO

Andrey Kopachevsky
agree

Volodymyr Zhabiuk
ok. Will change

Andrey Kopachevsky
Oliver: but to start without camel I need working version of interceptor routing without camel, because exception hendling is secondary thing

Oliver Wolf
the planner is working, so the next thing will be something like an interceptor executor that hooks into the nmr

Andrey Kopachevsky
@Oliver: exception handling is something that injecting above working interception chain
yes, that I talked about
and next step it exeption handling above this interseptor

Oliver Wolf
corect.... so what dietmar proposed is that you start by implementing this camel-independent interceptor executor
ok... so everyone knows what's up next?
i'm going to start reworking the website according to marías proposal

[END]