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 <
[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=""
type="String|float|double|boolean|..."/>
> > <property name="Symbol" _expression_="//Symbol"
action="" type="String"/>
> > <property name="Symbol"
_expression_="/getQuoteResponse/Price[0]"
> > action="" 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"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
|
