Paul,
On 8/6/07, Paul Fremantle <[EMAIL PROTECTED]> wrote:
>
> On 8/6/07, Ruwan Linton <[EMAIL PROTECTED]> 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.
This is what I meant actually. +1 for this.
> 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.
This seems cleaner, +1 to this. Shall I go ahead and do the implementation
of the POJO/Command implementation as well? If so what is the best fitting
name *pojo* or *command*?
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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:
> > [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > >
> > > --
> > > Paul Fremantle
> > > Co-Founder and VP of Technical Sales, WSO2
> > > OASIS WS-RX TC Co-chair
> > >
> > > blog: http://pzf.fremantle.org
> > > [EMAIL PROTECTED]
> > >
> > > "Oxygenating the Web Service Platform", www.wso2.com
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> >
> > --
> > 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
> [EMAIL PROTECTED]
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"
