synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepal jayasinghe <deep...@gmail.com>
Subject Re: SynapseObject - Reminder...
Date Mon, 20 Mar 2006 06:22:44 GMT
hmmmm,

I think can achieve the same thing by juts using OM since it has the
ability go Xpath navigation. And you do not need to re-implement that I
mean for me SynapseObjcet is just to navigation freamwork for XML file
(I know it have some pre-defined structure). So my idea is just use OM
and write a better navigation wrapper if you really want.

Just using pure OM you can achieve each of the following use cases :)

pls correct me if am doing wrong.



Soumadeep wrote:

>Comments inline... please read the use case
>
>-----Original Message-----
>From: Deepal jayasinghe [mailto:deepalk@gmail.com]
>Sent: Monday, March 20, 2006 9:34 AM
>To: synapse-dev@ws.apache.org
>Subject: Re: SynapseObject - Reminder...
>
>Hi Soumadeep
>
>pls see my in line comments
>
>Soumadeep 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:
>>
>>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.
>>    
>>
>
>Why do you want to use java properties ?
>That's the point, we don't want to use properties for name-value config
>details within mediators. If you want to know what kind of  name-value that
>could be required please read  use case below
>Java property can handle both simple and complex type ,
>System.getProperties().put(Objcet key , Object value)
>so the value can be anything.
>The problem is about "Anything" , you need to know which object to cast to
>at runtime.
>
>  
>
>>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)
>>    
>>
>
>if the schema going to be change I think we have to anyway change the
>code base , no matter if you use common model.
>Yes, I agree but if we use Synapse Object only the underlying logic in the
>mediator changes but the data handling remains the same all across the
>mediators.
>
>  
>
>>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
>>    
>>
>
>yes , if you use BeanUtill then you wont be have these feature :(
>Each mediator will have different beans which represent it's config details.
>If any other mediator wants to use the beans then it needs to be shared
>(generated classes jars) - I think you are aware the mediators are packed in
>MARs ! We need a commons util to handle data across mediators.
>
>  
>
>>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.
>>
>>    
>>
>using Java property you still can do that, may be it wrong but no one is
>stopping doing that.
>My suggestion is you should read the use case given below. If you have any
>doubts just meail. :)
>  
>
>>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>
>>
>>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>
>>
>>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)
>>
>>//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");
>>
>>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
>>    <http://192.9.2.11></attribute>
>>         </SynapseObject>
>>    </SynapseObject>
>>
>>    which is similar to,
>>
>>    <sla>
>>         <service> http://myhost:myport/Service </service>
>>         <consumer>
>>              <ip>192.9.2.11 <http://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
>>    <mailto: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/sy
>napse-SO
>  
>
><http://svn.apache.org/repos/asf/incubator/synapse/trunk/scratch/infravio/sy
>napse-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
>>        <mailto:synapse-dev-unsubscribe@ws.apache.org>
>>        For additional commands, e-mail:
>>        synapse-dev-help@ws.apache.org
>>        <mailto:synapse-dev-help@ws.apache.org>
>>
>>
>>    
>>
>
>
>--
>Thanks,
>Deepal
>................................................................
>~Future is Open~
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
>For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
>For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
>  
>


-- 
Thanks,
Deepal
................................................................
~Future is Open~ 


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