[prev in list] [next in list] [prev in thread] [next in thread] 

List:       esb-java-dev
Subject:    Re: [Carbon-dev] [Architecture] Revamping Message Routing Mediators
From:       Amila Suriarachchi <amila () wso2 ! com>
Date:       2011-09-30 10:15:44
Message-ID: CAOVorbFxisMeNjO4mu4DQEMg6qzqyAhCHfD2YgTL-GYLt6acsA () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Fri, Sep 30, 2011 at 3:03 PM, Kasun Indrasiri <kasun@wso2.com> wrote:

> Hi all,
>
> In the current ESB implementation we have couple of mediators for message
> routing. While 'Filter' and 'Switch' mediators provide basic level of
> message filtering, router mediator is also doing very similar to what
> filter/switch mediators do. The usage of Router mediator is rare and often
> got replaced by filter/switch mediators. So, IMO, Router Mediator is
> redundant, unless it provides some advance/complex routing logic support.
>
> In the ESB 4.0.0 release, we introduces 'Conditional Router', which is
> intended to route messages based on HTTP headers, query parameters and url.
> However, this doesn't support routing based on message payload. But unlike
> 'Router', the 'Conditional Router' introduces uses the concepts of
> 'Evaluators' (And, Or, Match, Equal, Not) that can be utilize to construct
> complex routing logics.
>
> eg:
>  <conditionalRouter continueAfter="false">
>                     <conditionalRoute breakRoute="false">
>                         <condition>
>                             <and xmlns="">
>                                 <match type="header"
> source="my_custom_header1" regex="foo.*"/>
>                                 <match type="url"
> regex="/services/StockQuoteProxy.*"/>
>                             </and>
>                         </condition>
>                         <target sequence="cnd2_seq"/>
>                     </conditionalRoute>
>
>                     <conditionalRoute breakRoute="false">
>                         <condition>
>                             <and xmlns="">
>                                 <match type="header"
> source="my_custom_header2" regex="bar.*"/>
>                                 <equal type="param" source="qparam1"
> value="qpv_foo"/>
>                                 <or>
>                                     <match type="url"
> regex="/services/StockQuoteProxy.*"/>
>                                     <match type="header"
> source="my_custom_header3" regex="foo.*"/>
>                                 </or>
>                                 <not>
>                                     <equal type="param" source="qparam2"
> value="qpv_bar"/>
>                                 </not>
>                             </and>
>                         </condition>
>                         <target sequence="cnd3_seq"/>
>                     </conditionalRoute>
> </conditionalRouter>
>
> So, we can easily add message level routing capability(so that we can drop
> Router mediator) to Conditional Router and with that we'll get the power of
> using evaluators for message level routing as well. Having bunch of
> mediators that's doing the similar thing, cause a negative effect on ESB's
> usability.
>
> (Most of the pointed listed here, were discussed during last code-review of
> Group-D.)
>

Another thing we saw was in consistency of naming. Lets take the following
two mediators

 <router>
      <route  expression="//ns1:foo/ns1:bar" match="test">
         <target />
      </route>
   </router>
   <filter source="//ns1:foo/ns1:bar" regex="test">
      <then />
      <else />
   </filter>

Both say the same thing but different attribute names are used at different
mediators. This can be seen in other places as well. Therefore I think it is
better to follow one set of naming convention in each mediators.

thanks,
Amila.


>
>
> *
> *
> [1] http://wso2.org/project/esb/java/4.0.0/docs/mediator_guide.html
>
>
> Thanks,
> --
> Kasun Indrasiri
> Associate Technical Lead
> WSO2, Inc.; http://wso2.com
> lean.enterprise.middleware
>
> cell: +94 71 536 4128
> Blog : http://kasunpanorama.blogspot.com/
>

[Attachment #5 (text/html)]

<br><br><div class="gmail_quote">On Fri, Sep 30, 2011 at 3:03 PM, Kasun Indrasiri \
<span dir="ltr">&lt;<a href="mailto:kasun@wso2.com">kasun@wso2.com</a>&gt;</span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> Hi all,<div><br></div><div>In the current ESB \
implementation we have couple of mediators for message routing. While \
&#39;Filter&#39; and &#39;Switch&#39; mediators provide basic level of message \
filtering, router mediator is also doing very similar to what filter/switch mediators \
do. The usage of Router mediator is rare and often got replaced by filter/switch \
mediators. So, IMO, Router Mediator is redundant, unless it provides some \
advance/complex routing logic support. </div>

<div><br></div><div>In the ESB 4.0.0 release, we introduces &#39;Conditional \
Router&#39;, which is intended to route messages based on HTTP headers, query \
parameters and url. However, this doesn&#39;t support routing based on message \
payload. But unlike &#39;Router&#39;, the &#39;Conditional Router&#39; introduces \
uses the concepts of &#39;Evaluators&#39; (And, Or, Match, Equal, Not) that can be \
utilize to construct complex routing logics. </div>

<div><br></div><div><div>eg:</div><div><div> &lt;conditionalRouter \
continueAfter=&quot;false&quot;&gt;</div><div>                    \
&lt;conditionalRoute breakRoute=&quot;false&quot;&gt;</div><div>                      \
&lt;condition&gt;</div>

<div>                            &lt;and xmlns=&quot;&quot;&gt;</div><div>            \
&lt;match type=&quot;header&quot; source=&quot;my_custom_header1&quot; \
regex=&quot;foo.*&quot;/&gt;</div><div>                                &lt;match \
type=&quot;url&quot; regex=&quot;/services/StockQuoteProxy.*&quot;/&gt;</div>

<div>                            &lt;/and&gt;</div><div>                        \
&lt;/condition&gt;</div><div>                        &lt;target \
sequence=&quot;cnd2_seq&quot;/&gt;</div><div>                    \
&lt;/conditionalRoute&gt;</div>

<div><br></div><div>                    &lt;conditionalRoute \
breakRoute=&quot;false&quot;&gt;</div><div>                        \
&lt;condition&gt;</div><div>                            &lt;and \
xmlns=&quot;&quot;&gt;</div> <div>
                                &lt;match type=&quot;header&quot; \
source=&quot;my_custom_header2&quot; regex=&quot;bar.*&quot;/&gt;</div><div>          \
&lt;equal type=&quot;param&quot; source=&quot;qparam1&quot; \
value=&quot;qpv_foo&quot;/&gt;</div>

<div>                                &lt;or&gt;</div><div>                            \
&lt;match type=&quot;url&quot; \
regex=&quot;/services/StockQuoteProxy.*&quot;/&gt;</div><div>                         \
&lt;match type=&quot;header&quot; source=&quot;my_custom_header3&quot; \
regex=&quot;foo.*&quot;/&gt;</div>

<div>                                &lt;/or&gt;</div><div>                           \
&lt;not&gt;</div><div>                                    &lt;equal \
type=&quot;param&quot; source=&quot;qparam2&quot; \
value=&quot;qpv_bar&quot;/&gt;</div>

<div>                                &lt;/not&gt;</div><div>                          \
&lt;/and&gt;</div><div>                        &lt;/condition&gt;</div><div>          \
&lt;target sequence=&quot;cnd3_seq&quot;/&gt;</div>

<div>                    \
&lt;/conditionalRoute&gt;</div><div>&lt;/conditionalRouter&gt;</div></div></div><div><br></div><div>So, \
we can easily add message level routing capability(so that we can drop Router \
mediator) to Conditional Router and with that we&#39;ll get the power of using \
evaluators for message level routing as well. Having bunch of mediators that&#39;s \
doing the similar thing, cause a negative effect on ESB&#39;s usability. </div>

<div><br></div><div>(Most of the pointed listed here, were discussed during last \
code-review of Group-D.)</div></blockquote><div><br>Another thing we saw was in \
consistency of naming. Lets take the following two mediators<br> <br> \
&lt;router&gt;<br>      &lt;route  expression=&quot;//ns1:foo/ns1:bar&quot; \
match=&quot;test&quot;&gt;<br>         &lt;target /&gt;<br>      &lt;/route&gt;<br>   \
&lt;/router&gt;<br>   &lt;filter source=&quot;//ns1:foo/ns1:bar&quot; \
regex=&quot;test&quot;&gt;<br>  &lt;then /&gt;<br>      &lt;else /&gt;<br>   \
&lt;/filter&gt;<br><br>Both say the same thing but different attribute names are used \
at different mediators. This can be seen in other places as well. Therefore I think \
it is better to follow one set of naming convention in each mediators. <br> \
<br>thanks,<br>Amila.<br> </div><blockquote class="gmail_quote" style="margin: 0pt \
0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: \
1ex;"><div><br></div><div><br></div><div><b><br></b></div><div>[1] <a \
href="http://wso2.org/project/esb/java/4.0.0/docs/mediator_guide.html" \
target="_blank">http://wso2.org/project/esb/java/4.0.0/docs/mediator_guide.html</a></div>


<div><br clear="all"><div><br></div><div>Thanks, </div>-- <br><font \
color="#888888">Kasun Indrasiri<br><span style="font-family:arial, \
sans-serif;font-size:13px;border-collapse:collapse">Associate Technical \
Lead</span><br>

WSO2, Inc.; <a href="http://wso2.com" \
target="_blank">http://wso2.com</a><br>lean.enterprise.middleware<br><br>cell: <a \
href="tel:%2B94%2071%20536%204128" value="+94715364128" target="_blank">+94 71 536 \
4128</a><br>Blog : <a href="http://kasunpanorama.blogspot.com/" \
target="_blank">http://kasunpanorama.blogspot.com/</a><br>


</font></div>
</blockquote></div><br>



_______________________________________________
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic