synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Fremantle" <pzf...@gmail.com>
Subject Re: Class mediator
Date Mon, 06 Aug 2007 07:41:40 GMT
Asankha

The POJO mediator MUST be instantiated new for each message. Otherwise
you need to implement some reset() pattern, and I think that makes it
too complex. Therefore, the model is slightly different to how you
describe.

CLASS:
When Synapse calls ClassMediator.init():
ClassMediator calls
* m.setX(),
* m.setY(),
* optionally init(SynEnv);

When Synapse calls ClassMediator.mediate()
* ClassMediator calls m.mediate();

POJO
When Synapse calls PojoMediator.init()
* PojoMediator can lookup and store Method fields to make invocation
more efficient.
[Suppose we define properties X in, Y inout, Z out]
Synapse calls  PojoMediator.mediate():
pojoMediator calls:
*  Mediator.class.newInstance()
* p.setX(),
* p.setY(),
* [optionally init(SynapseEnv)]
* p.execute(),
* p.getY(),
* p.getZ(),
* [optionally destroy()]

Paul

On 8/6/07, Asankha C. Perera <asankha@wso2.com> wrote:
>
>  Ruwan
>
>  Basically this means that the ClassMediator and PojoMediator have almost
> the same semantics. i.e. all static name/value properties are set on init()
> by the factory, and all dynamic attributes set before each invocation of the
> mediate() or the POJO execute method (this name should be configurable via
> an attribute on the Pojo mediator)
>
>  Im +1 for this.. the factories and serializers would handle the persistence
> appropriately
>
>  asankha
>
>
>  Ruwan Linton wrote:
> Hi Paul,
>
>  In order to achieve the serialization we will need to keep the setter
> informations with both Class and Command (Pojo). That is because, we may set
> only a set of attributes in those objects rather than setting all of them in
> the configuration; in which case we must only serialize with the properties
> that we have set only.
>
>  For example if we have a ClassMediator with attributes x, y and z but we
> set only x and y in the configuration and the CMF (ClassMediatorFactory)
> will pick these correctly and to serialize the exact behavior we need to
> know what attributes has been set and what not. So we need to keep this in a
> list.
>
>  Apart from that if we want the expression behavior (that is to set some
> attributes at the runtime from the message using XPATH) we will have to
> iterate through the expression set and evaluate those before calling the
> mediate method (same with the pojo case). If a particular mediator doesn't
> set any expressions then the behavior is exactly same as the static property
> case.
>
>  If this is OK to proceed, I will go ahead and implement this.
>
>  Thanks,
>  Ruwan.
>
>
> On 8/1/07, Paul Fremantle < pzfreo@gmail.com> wrote:
> > Also I think its clearer. I didn't really understand the point of the
> > dynamic properties before (Doh!).
> >
> > It might be better to call this the <pojo> instead of <command>
> > because the objects really would be POJOs (i.e. they would not need to
> > implement any synapse-specific interface.
> >
> > For that reason I suggest we use reflection to implement this. (I
> > looked for a javax....Command interface but couldn't find one). That
> > means you can write one of these objects without needing any Synapse
> > JARs in your build path which I think is a good thing.
> >
> > Paul
> >
> > On 8/1/07, Asankha C. Perera <asankha@wso2.com> wrote:
> > > Paul
> > >
> > > Yep.. this is certainly good! It would leave the best of both worlds
> > >
> > > asankha
> > >
> > > Paul Fremantle wrote:
> > > > I changed the class mediator to only use static properties so that
> > > > they would be set before the class.init() was called.
> > > >
> > > > However, Asankha has pointed out to me that there is another model
> > > > that the dynamic properties had, which is to use XPath properties to
> > > > set data on the mediator before it is called, thereby meaning that
> > > > there is no need for user to need to understand OMElement or
> > > > MessageContext to write a mediator.
> > > >
> > > > I guess I see these as two completely separate ways to write a
> > > > mediator. In fact I see three potential approaches:
> > > >
> > > > 1) mediate(MessageContext mc)
> > > > 2) set/get XPath data in/out of the message
> > > > 3) Use ADB or Databinding and write Java based on the message type
> > > >
> > > > I'm not sure about the third option - it not very "loosely-coupled"
> > > > but I can see how it would appeal to Java developers. I'd be happy to
> > > > leave that till later.
> > > >
> > > > However, I think 1 and 2 are really distinct cases.
> > > >
> > > > The second model is really something called the Command Pattern. You
> > > > can read about it here:
> > > > http://en.wikipedia.org/wiki/Command_pattern
> > > >
> http://www.javaworld.com/javaworld/javatips/jw-javatip68.html?page=1
> > > >
> > > > Basically this model is where you call:
> > > >
> > > > obj.setX(y);
> > > > obj.setQ(z);
> > > > obj.setF (e);
> > > > obj.execute();
> > > > obj.getX()
> > > > obj.getQ()
> > > > obj.getF();
> > > >
> > > > It seems like we could define a nice model for this in Synapse:
> > > > <command class=" org.fremantle.Command"> <!-- class must implement
> > > > "void execute();" -->
> > > >    <property name="Name" expression="xpath expression"
> > > > action="set|get|setAndGet"
> type="String|float|double|boolean|..."/>
> > > >    <property name="Symbol" expression="//Symbol" action="get"
> type="String"/>
> > > >    <property name="Symbol"
> expression="/getQuoteResponse/Price[0]"
> > > > action="set" type="Double"/>
> > > > </command>
> > > >
> > > > Basically what this will do is allow the user to write a real POJO
> > > > that implements getters and setters as well as the execute(); method.
> > > > We then call XPaths and set data into the object, then call execute();
> > > > then we update the message based on data from the getters.
> > > >
> > > > Thoughts?
> > > >
> > > > Paul
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> synapse-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > Paul Fremantle
> > Co-Founder and VP of Technical Sales, WSO2
> > OASIS WS-RX TC Co-chair
> >
> > blog: http://pzf.fremantle.org
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
>
>
>
>  --
>  Ruwan Linton
>  http://www.wso2.org - "Oxygenating the Web Services Platform"
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> synapse-dev-unsubscribe@ws.apache.org For additional
> commands, e-mail: synapse-dev-help@ws.apache.org


-- 
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair

blog: http://pzf.fremantle.org
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org


Mime
View raw message