Hi James,
The idea looks nice. I'm just a bit concerned about whether the concept
steps on the toes of the interceptSendToEndpoint DSL to some extent?
The interceptSTE DSL only triggers at the dispatch stage, not at the
response, so it doesn't _fully wrap_ it. Perhaps we could extend the
interceptSTE to provide a syntax like this:
<interceptSendToEndpoint uri="seda:issueTicket">
<before>
<log message="Intercepted: ${body}" />
<bean ref="abc" method="def" />
</before>
<after>
<!-- only trigger if condition is true -->
<xpath>/airline = 'Camel Airlines'</xpath>
<log message="Intercepted response: ${body}" />
</after>
</interceptSendToEndpoint>
If I'm not mistaken, this shortcoming exists ever since the AOP DSL was
deprecated [1]?
Anyway, back to Bindings. The concept is top notch, but it may confuse
users to find so many ways in Camel of doing similar stuff (Binding,
Intercept, EventNotifiers, etc.).
IMHO, the benefits of Bindings against interceptSTE are the following:
- Definition is local to the endpoint => with bindings, the
before/after logic is defined closer to the endpoint; interceptors are
defined "further away" from the endpoint: in the Camel Context.
- Due to above, code readability and clarity may be better with Bindings
in some cases, as the user doesn't have to dot back and forth to get the
full picture.
- Before / after semantics => interceptSTE cannot define actions after
the endpoint dispatch returns
- With Bindings, full interception logic (before, after) can be
encapsulated inside a single Java class. With interceptSTE it's not
possible. Maybe we can provide a syntax like
<interceptSendToEndpoint uri="..." interceptorRef="myInterceptor" />
Where myInterceptor implements an Interceptor interface with before() and
after() methods.
[1] http://camel.apache.org/aop.html
Regards,
*Raúl Kripalani*
Apache Camel Committer
Enterprise Architect, Program Manager, Open Source Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk <http://twitter.com/raulvk>
On Fri, Oct 19, 2012 at 12:13 PM, James Strachan
<james.strac...@gmail.com>wrote:
> Inspired by the SwitchYard project and how it uses contracts in SCA, I
> thought I'd take a stab at adding something vaguely similar to Camel;
> to allow us to add bindings to an endpoint (e.g. ensuring a particular
> Data Format is used in or out of the endpoint, to add a validation
> step , add transactions or whatnot).
>
> It turned out to be really simple ;) there's not really much in the
> way of code; its more a new concept (rather like the introduction of
> Data Format a long time ago). I've tried to document what Bindings are
> and how they can be used - and when to use them or not...
> https://cwiki.apache.org/confluence/display/CAMEL/Binding
>
> I'm not sure how big a deal they are in general to Camel folks; if you
> only use an endpoint once inside a route and the route isn't used or
> shared by anything else, they are not that useful really. But I can
> see them being useful when folks have lots of endpoints; or wish to
> pass endpoints into and out of composite routes etc.
>
> So far there's only one Binding implementation ;) the
> DataFormatBinding which was pretty trivial to implement.
>
> http://svn.apache.org/viewvc/camel/trunk/camel-core/src/main/java/org/apache/camel/processor/binding/DataFormatBinding.java?revision=1400019&view=markup
>
> Am sure we could hack up others for Java type conversion, XSD
> validation or WSDL contract enforcement or whatnot.
>
> We could also add a little bit of syntax sugar in the Java/XML DSLs to
> make them a little more DRY to use.
>
> Thoughts?
>
> --
> James
> -------
> Red Hat
>
> Email: jstra...@redhat.com
> Web: http://fusesource.com
> Twitter: jstrachan, fusenews
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration
>
