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:00:12 GMT
On 8/6/07, Ruwan Linton <ruwan.linton@gmail.com> 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.

Yes I was thinking about this problem. I think that there are two
things here - the class mediator wrapper object, and the actual class
itself.

I think the Wrapper object (instance of ClassMediator) should contain
the properties as a Map: name->{String | OMElement}. This is what
should be serialized/deserialized into the synapse.xml. The actual
instance of the users class is only set - not read. I don't think I
see any benefit in reading the actual class.

> 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).

I think that the class and POJO should be distinct. In other words,
the class mediator should only have static properties set. After all,
the whole message context is available to it already. Its confusing to
have dynamic properties set on it, and it also reduces performance,
and makes it difficult to init() it correctly.

The POJO/Command model is different, in that it is basically all
dynamic properties --- except of course someone may want static
properties on it as well (e.g. count="3"). So I think we need two
different lifecycles:

Class mediator: At the time of finding a ClassMediator in the XML we
create the class mediator, create a single object instance, set
properties, then init. Then all requests go through this.

POJO/Command - for each message we instantiate a new object, get from
message/set properties, and then call execute, then get
properties/update message.

Paul

 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"


-- 
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