Hi
IMO, I still could't separate the drastic different between using POJO
vs ClassMediator (forget about performance aspects), if think in a
developer perspective I am more comfortable with Classmediator btw (just a
thought)
for e.g let look at twitter search...
serialization view
<twitter.search>
<search>hotel</search>
</twitter.search>
synapse temple configuration correspond twitter search
<template xmlns="http://ws.apache.org/ns/synapse"; name="search">
<parameter name="oauth.consumerKey"/>
<parameter name="oauth.consumerSecret"/>
<parameter name="oauth.accessToken"/>
<parameter name="oauth.accessTokenSecret"/>
<parameter name="search"/>
<parameter name="lang"/>
<parameter name="locale"/>
<parameter name="maxId"/>
<parameter name="since"/>
<parameter name="sinceId"/>
<parameter name="geocode"/>
<parameter name="radius"/>
<parameter name="unit"/>
<parameter name="until"/>
<sequence>
<class name="org.wso2.carbon.connector.twitter.TwitterSearch"/>
</sequence>
</template>
in case let assume same template to be written in POJO...
<template xmlns="http://ws.apache.org/ns/synapse"; name="search">
<parameter name="oauth.consumerKey"/>
<parameter name="oauth.consumerSecret"/>
<parameter name="oauth.accessToken"/>
<parameter name="oauth.accessTokenSecret"/>
<parameter name="search"/>
<parameter name="lang"/>
<parameter name="locale"/>
<parameter name="maxId"/>
<parameter name="since"/>
<parameter name="sinceId"/>
<parameter name="geocode"/>
<parameter name="radius"/>
<parameter name="unit"/>
<parameter name="until"/>
<sequence>
<pojoCommand
name="org.wso2.carbon.connector.twitter.TwitterSearch">
<axis2ns1:property xmlns:axis2ns1="
http://ws.apache.org/ns/synapse";
name="xxx"
expression="$ctx:xxx"
action="ReadMessage"/>
<axis2ns1:property xmlns:axis2ns1="
http://ws.apache.org/ns/synapse";
name="yyy"
context-name="xxxxx"
action="UpdateContext"/>
<axis2ns1:property xmlns:axis2ns1="
http://ws.apache.org/ns/synapse";
name="yyy"
context-name="updatedID"
action="UpdateContext"/>
<axis2ns1:property xmlns:axis2ns1="
http://ws.apache.org/ns/synapse";
name="yyy"
context-name="updatedID"
action="UpdateContext"/>
.............
............
............
</pojoCommand>
</sequence>
</template>
for me above seems to be a lengthy and ugly and added unwanted overhead in
developer time...
Cheers
Dushan
On Thu, Aug 1, 2013 at 11:45 AM, Kasun Indrasiri <[email protected]> wrote:
>
>
>
> On Thu, Aug 1, 2013 at 9:49 AM, Miyuru Wanninayaka <[email protected]>wrote:
>
>> Hi Kasun,
>>
>> Main drawback of the pojo mediator is, it does not have access to message
>> context, so everything it need to access need to pass as parameters in
>> sequence. Also in most custom mediator cases, it is required to modify
>> contents of message context which is not possible with pojo mediator.
>>
>> We can modify the API of the POJO mediator to make msgCtx available
> inside the mediator. OTOH, if we are changing too many things in ctx, then
> again its not very different from a class mediator.
> One major concern we have in POJO mediator is, its usability. We need to
> do several improvements to get it right.
>
>> IMO using class mediator vs pojo is purely a decision of connector
>> developer. There can be situations where for pojo mediator will be better
>> suite than class mediator and it's totally fine to use pojo mediator in
>> such cases.
>>
>> Since connector is kind of a meta synapse artifact, it can use any other
>> synapse artifacts based on usecase to implement connector library.
>>
>> Please note that connector work should not blocked on whether we are
> going to use class mediators or pojo mediators.
>
>> On Wed, Jul 31, 2013 at 2:20 PM, Kasun Indrasiri <[email protected]> wrote:
>>
>>> We are in the process of implementing several components which involves
>>> java sdks (twitter), although the class mediator approach works fine, it
>>> seems to introduce some usability issues.
>>>
>>> - Basically, a given class mediator simply get all the required
>>> properties from the message context where property names are hard coded in
>>> both template and class mediator. [1]
>>>
>>> - One possible approach that we can use is to use POJO mediator, so that
>>> we can dynamically resolve the incoming parameters and we could have
>>> minimal java code when implementing our connector.
>>> - We can even get more flexibility with spring mediator as well[2].
>>> - However, class mediator approach is better when it comes to
>>> performance (since we use reflection in other two approaches).
>>>
>>> - We will do a PoC on these approaches and see how it goes.
>>>
>>> This is a sample config with POJO Mediator
>>> eg:
>>>
>>> package org.apache.twitter;
>>>
>>> import org.apache.synapse.Command;
>>>
>>> public class TwitterInvokeMediator implements Command {
>>>
>>> private String twitterSecrect;
>>>
>>> private String twitterId;
>>>
>>> private String message;
>>>
>>> public void execute() {
>>>
>>> System.out.println("TwitterID :" + twitterId);
>>>
>>> twitterId = "CDE";
>>>
>>> }
>>>
>>>
>>> public String getTwitterSecrect() {
>>>
>>> return twitterSecrect;
>>>
>>> }
>>>
>>> public void setTwitterSecrect(String twitterSecrect) {
>>>
>>> this.twitterSecrect = twitterSecrect;
>>>
>>> }
>>>
>>> public String getTwitterId() {
>>>
>>> return twitterId;
>>>
>>> }
>>>
>>> public void setTwitterId(String twitterId) {
>>>
>>> this.twitterId = twitterId;
>>>
>>> }
>>>
>>> public String getMessage() {
>>>
>>> return message;
>>>
>>> }
>>>
>>> public void setMessage(String message) {
>>>
>>> this.message = message;
>>>
>>> }
>>>
>>> }
>>>
>>>
>>> Invocation :
>>>
>>>
>>> <pojoCommand name="org.apache.twitter.TwitterInvokeMediator">
>>>
>>> <axis2ns1:property xmlns:axis2ns1="
>>> http://ws.apache.org/ns/synapse";
>>>
>>> name="twitterId"
>>>
>>> expression="$ctx:TWID"
>>>
>>> action="ReadMessage"/>
>>>
>>> <axis2ns1:property xmlns:axis2ns1="
>>> http://ws.apache.org/ns/synapse";
>>>
>>> name="twitterId"
>>>
>>> context-name="updatedID"
>>>
>>>
>>> action="UpdateContext"/>
>>>
>>> </pojoCommand>
>>>
>>>
>>>
>>> [1]
>>> https://svn.wso2.org/repos/wso2/carbon/platform/branches/4.1.0/components/mediation/mediation-library/connectors/org.wso2.carbon.mediation.library.connectors.twitter/4.1.0/src/main/java/org/wso2/carbon/mediation/library/connectors/twitter/TwitterUpdateStatusMediator.java
>>>
>>> [2]
>>> https://svn.wso2.org/repos/wso2/carbon/platform/branches/4.1.0/dependencies/synapse/2.1.1-wso2v3/modules/samples/src/main/java/samples/mediators/extensions/SpringCustomLogger.java
>>> --
>>> Kasun Indrasiri
>>> Software Architect
>>> WSO2, Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> cell: +94 71 536 4128
>>> Blog : http://kasunpanorama.blogspot.com/
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Miyuru Wanninayaka
>> Technical Lead
>> WSO2 Inc. : http://wso2.com
>>
>> Mobile : +94 77 209 9788
>> Blog : http://miyurudw.blogspot.com
>> Flickr : http://www.flickr.com/photos/miyuru_daminda
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Kasun Indrasiri
> Software Architect
> WSO2, Inc.; http://wso2.com
> lean.enterprise.middleware
>
> cell: +94 71 536 4128
> Blog : http://kasunpanorama.blogspot.com/
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Dushan Abeyruwan
Associate Tech Lead
*Integration Technologies Team*
*WSO2 Inc. http://wso2.com/*
*Mobile:(+94)714408632*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
