synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <dava...@gmail.com>
Subject Re: SynapseObject - Reminder...
Date Mon, 20 Mar 2006 14:06:08 GMT
i *really* don't see a need for it. Let's make do with standard stuff
like saminda mentioned.

thanks,
dims

On 3/20/06, Vikas <vikas@infravio.com> wrote:
>
>
> Hi...
>
> I am using SynapseObject to handle mediator data, it works as an extension.
> Is there a problem in adding extensions??
> Extensions are not compulsary or imposed on others, just for convenience...
>
> But to make things clear and sum up the points:
>
> The problem is not with using DOM / OM..
> Its the XML structure that gives the meaning, the JAVA/in-memory
> representation is just an enabler for that..
>
> I did try writing the 'utility' methods for OM...
> But based on a generic XML structure, it just doesn't work out...
> The XML representation along with the Utility classes gives SynapseObject
> the actual strength and the users the ease..
>
> SynapseObject is not just about ObjectModel [AXIOM/DOM] or about XML [the
> structure]
> or the data-binding [XMLBeans/ ADB]...
>
> Its a variation in-between, a blend to be more precise...
>
> The very problem with XPath is that they are based on the XML structure,
> change the structure =>change the X-Path...
>
> But SynapseObject has only 2 structural constraints..
> Every object has
> * Attributes as child objects
> * Has other SynapseObjects
> In case I move an attribute from a parent to its child SynapseObject, the
> search utility takes care of it, In case of an X-Path that mplies another
> level of ../.. [hope you are not planning to use x-paths which always search
> throughout i.e [//someName]
>
> ~Vikas..
>
> ----- Original Message -----
> From: Saminda Abeyruwan
>
> To: synapse-dev@ws.apache.org
>
> Sent: Monday, March 20, 2006 2:51 PM
> Subject: Re: SynapseObject - Reminder...
>
> Hi Devs,
>
> My comments are in line,
>
> On 3/19/06, Soumadeep <soumadeep@infravio.com> wrote:
>
> >
> >
> >
> > Hi,
> >
> > One thing I completely agree with Sanjiva is that this has been dragged
> unnecessarily for this long. Let me emphasize here one thing, that the
> intension is not to replace the concepts of data binding as used by XMLBeans
> which is again an Apache project or trying to re-invent what has been
> written. To this effect enough reasons have been provided as to why this
> approach was taken.  For convenience let me give one of the use cases and
> reasons for which SynapseObject was proposed:
>
>
> Following reasons  is addressed by Axis2 's codegen concepts.
>
>
> >
> >
> >
> > Reasons:
> > 1) Java Properties class lets you handle name-value pairs in a very good
> way but when it comes to representing complex objects it becomes very
> difficult.
> > 2) Using the concept of data binding introduces a very rigid and tight
> coupling of data and schema. So if the schema changes the underlying data
> handling mechanism needs to be changed (which includes the beans/classes to
> hold the complex data structure)
>
>
> This is why there are two entities exists in Axis2.  If the xml is  schema
> compliant  i will use XSD2Java, if not i will write my beans and use
> BeanUtil.
>
>
> >
> >
> >
> > 3) Intelligent search features are either driven by xpath/xqueries for
> pure XML or embedded logic if beans are used, SynapseObject has inbuilt
> search features by which you can perform complex searches
> > 4) The reason people use Java Properties class is because name-value pairs
> can be shared by other class without any dependency. SynapseObject is more
> like a Properties Class with added features to handle Complex Objects and
> also allow search features.
>
>
> Synapse is a user of Axis2, so let it be a user of  Axis2's XSD2Java,
> BeanUtil and Jaxen compliant Xpath.
>
>
> >
> >
> >
> > Uses Cases:
> > A) Data-Sharing between mediators: Consumers need to be identified, once
> it's identified the information could be shared by the SLA mediator which
> depending on a consumer will set the priority. Below is the pseudo code  of
> how this can be achieved using SynapseObject and how datasharing would
> become easy.
> >
> > Background Info:
> > -----------------------
> > ConsumerIdentification mediator needs to identify a client by the
> following ways:
> > 1) IP {eg. 192.168.5.*}
> > 2) IP Range {eg. 192.168.5.20- 192.168.5.30}
> > 3) WS-SEC auth token
> > 4) HTTP auth token
> > 5) certificate
> > (Other factors that need to be considered whether the incoming message was
> first encrypted and then signed or was it signed and then encrypted).
> > Let's consider 1) IP
> >
> > Using SynapseObject:
> > ConsumerIdentification
> > --------------------------------
> >
> > xml frag:
> > <?xml version='1.0' encoding='windows-1252'?>
> > <SynapseObject name="ci">
> >
> >  <SynapseObject name="consumer0">
> >    <Attribute name="CONSUMER_TYPE" type="String">GOLD</Attribute>
> >
> >    <Attribute name="IP_ADDRESS_FROM" type="String">192.168.6.0</Attribute>
> >
> >    <Attribute name="IP_ADDRESS_TO" type="String">192.168.6.255</Attribute>
> >    <Attribute name="HTTP_AUTH_USERNAME" type="String">john</Attribute>
> >    <Attribute name="WS_SEC_USERNAME" type="String">john</Attribute>
> >    <SynapseObject name="assignedService">
> >     <Attribute name="serviceid1"
> type="String">stockQuote1</Attribute>
> >    </SynapseObject>
> >  </SynapseObject>
> >  <SynapseObject name="consumer1">
> >    <Attribute name="CONSUMER_TYPE"
> type="String">SILVER</Attribute>
> >    <Attribute name="IP_ADDRESS_FROM"
> type="String">192.168.6.255</Attribute>
> >    <Attribute name="IP_ADDRESS_TO" type="String">192.167.6.255</Attribute>
> >    <Attribute name="HTTP_AUTH_USERNAME" type="String">mary</Attribute>
> >    <Attribute name="WS_SEC_USERNAME" type="String">mary</Attribute>
> >    <SynapseObject name="assignedService">
> >     <Attribute name="serviceid1"
> type="String">stockQuote</Attribute>
> >     <Attribute name="ip" type="String">192</Attribute>
> >    </SynapseObject>
> >  </SynapseObject>
> > </SynapseObject>
>
>
> Back to  square  one,
>
> Above  can be written as,
> <ci>
>      <consumer name="consumer0">
>             <type>GOLD</type>
>             <ip_address_from>192.168.6.0 </ip_address_from>
>             <ip_address_to>192.167.6.255 </ip_address_to>
>             <http_auth_username>Mary</http_auth_username>
>              <ws_sec_username>Mary</ws_sec_username>
>      </consumer>
>      <service name="assingedservice">
>         <!-- other stuff -->
>      </service>
>      <consumer name="consumer1">
>          <!-- related suff -->
>      </consumer>
>         <!-- other services or consumers or related stuff -->
> </ci>
>
> which is much more readable,
>
> If i want intelligent search i use xpath. A lot of users know how to use
> xpath, so it's Zero training. If i write  simple beans, i can populate the
> bean objects using BeanUtil. Now in production the above xml should be
> schema aware. That's the whole point of inventing schema. So i will use
> XSD2Java. Now these technologies are not going to hook into Synapse core.
>
>
> >
> >
> >
> > in the ci mediator  code fragment
> >
> > // the the requester ip
> > ip = {get the remote ip from the messageContext/SynapseContext }
> >
> > //Identify if the consumer is there and get appropriate details and store
> the consumer related details in the messageContext, one more things to note
> is that storing shared data is by the mediator name itself eg. ci
> > SynapseObject obj =
> consumerIdentification.findSynapseObjectByAttributeValueStartingWith(ip);
> > messageContext.setProperty(consumerIdentification.getName(),obj);
> > obj will contain all the required values if identified!
> >
> > SLA
> > ------
> >
> > xml Fragment:
> >
> > <SynapseObject name="SLA">
> >     <SynapseObject name="consumer0">
> >         <SynapseObject name="Service0">
> >             <Attribute name="EPR"
> type="String">http://www.webservicex.net/stockquote.asmx</Atrribute>
> >             <Attribute name="priority" type="Integer">0</Attribute>
> >         </SynapseObject>
> >
> >
> >         <SynapseObject name="Service1">
> >             <Attribute name="EPR"
> type="String">http://www.webservicex.net/findZIPCode.asmx</Atrribute>
> >             <Attribute name="priority" type="Integer">1</Attribute>
> >         </SynapseObject>
> >     </SynapseObject>
> > </SynapseObject>
>
>
> IMHO  above xml fragment would treat as the prior.
>
>
> >
> >
> >
> > in the SLA Mediator code fragment
> >
> > //As there is a dependency between the SLA mediator and CI the SLA
> mediator will pick information for its dependency (Note: we also proposed a
> concept
> > //of MediatorContext which will have dependency and other information for
> a particular mediator)
>
>
> Excuse me btw :)
>
>
> >
> >
> >
> > //Get the identified consumer from the messagecontext
> > SynapseObject consumerIdentification =
> (SynapseObject)messageContext.getProperty("ci");
> >
> > // get the consumer name and consumer type
> > String consumerName = consumerIdentification.getName();
> > String consumerType =
> consumerIdentification.getString("CONSUMER_TYPE");
> >
> > //find the sla details for the identified consumer
> > SynapseObject consumer =
> sla.findSynapseObjectByAttributeValue(consumerName);
> > String fromAddress =
> (String)synapseMessageContext.getTo();
> > SynapseObject service =
> consumer.findSynapseObjectByAttributeValue(fromAddress );
> >
> > // The priority value would be used by the SLA mediator to forward the
> request to the provider depending on the priority.
> > String priority = service.getString("priority");
>
>
> Now as i can understand from the above code fragments, SynaspeObject has to
> have a hook to Synapse core. As we agreed, SO should be  an extension.
> Besides, as technology exists for manipulating the required xml, (xpath,
> XSD2Java, BeanUtil) for mediators without having a hook to Synapse core, why
> on earth we make SO a core feature?
>
> Thank you
>
> Saminda
>
>
> >
> >
> >
> > Regards
> > Soumadeep
> >
> >
> > -----Original Message-----
> > From: Saminda Abeyruwan [mailto:samindaa@gmail.com]
> > Sent: Saturday, March 18, 2006 6:59 PM
> > To: synapse-dev@ws.apache.org
> > Subject: Re: SynapseObject - Reminder...
> >
> >
> > Hi Devs,
> >
> > These are my concern regarding SynapseObject,
> >
> > If the following XML is considered wrt SynapseObject semantics,
> >
> > <SynapseObject name="sla">
> >      <attribute name="service"
> type="STRING">http://myhost:myport/Service</attribute>
> >      <SynapseObject name="consumer">
> >      <attribute name="ip" type="STRING">192.9.2.11</attribute>
> >      </SynapseObject>
> > </SynapseObject>
> >
> > which is similar to,
> >
> > <sla>
> >      <service> http://myhost:myport/Service </service>
> >      <consumer>
> >           <ip>192.9.2.11</ip>
> >      </consumer>
> > </sla>
> >
> > Now if we have Java beans as follows,
> >
> > public class sla {
> >     private String service;
> >     private Consumer consumer;
> >
> >    //getter and setters
> > }
> >
> > public class Consumer {
> >      private String ip;
> >
> >    //getter and setters
> > }
> >
> > and using the Axis2's
> org.apache.axis2.databinding.utils.BeanUtil.getPullParser(Object
> beanObject, QName beanName);
> >
> > i can get a XMLStreamReader and build the OMElement i need. And if i have
> prior XML, using
> > Object []
> org.apache.axis2.databinding.utils.BeanUtil.deserialize(OMElement
> response, Object [] javaTypes); i can fill the bean object.
> >
> > So if I'm a Mediator author, using BeanUtil i can manipulate XML with Zero
> training.
> >
> > Now if my XML is schema complaint, using XSD2Java i can generate Beans and
> using XX.parse() method i can fill the beans.
> >
> > So what is done by SynapseObject is already done by Axis2's BeanUtil and
> XSD2Java and they can do much more. So  IMHO we do not need to reinvent the
> wheel with SynapseObject.
> >
> > Those are my concerns.
> >
> > Thank you
> >
> > Saminda
> >
> >
> >
> >
> > On 3/17/06, Sanjiva Weerawarana <sanjiva@opensource.lk> wrote:
> > > On Mon, 2006-03-27 at 18:44 +0530, Vikas wrote:
> > > > Hi,
> > > >
> > > > This is regarding the Synapse object proposed by me and Soumadeep...
> > > >
> > > > For convenience I am putting below the links for reference:
> > > >
> <http://mail-archives.apache.org/mod_mbox/ws-synapse-dev/200602.mbox/%
> > > > 3cPOEHIPNLJGDMKMMBHILOAECICBAA.soumadeep@infravio.com
> %3e>
> > > > and the source code has been available in the Scratch
> > > > <
> http://svn.apache.org/repos/asf/incubator/synapse/trunk/scratch/infravio/synapse-SO
> >
> > > >
> > > > I feel that it an effective utility and have made use of it in a all
> > > > the mediators that I would like to commit . It sure has made handling
> > > > mediator's config data easier..
> > > > Would be checking in the cleaned up code for SynapseObject as an
> > > > extension...Which I guess is OK.
> > > >
> > > > Please let me know if anyone has any concerns about it??
> > >
> > > I do .. I will write an explanatory reply tomrrow my time .. sorry for
> > > keeping quiet; I've been reading much of this thread but just haven't
> > > had the time to jump in.
> > >
> > > I *will* dive in tomorrow (later today my time really). I'm afraid its
> > > going to have lots of -1s against SynapseObject features :( .. just to
> > > give you a warning of where its going.
> > >
> > > Sanjiva.
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> synapse-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> > >
> > >
> >
> >
> >
>
>


--
Davanum Srinivas : http://wso2.com/blogs/

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