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:[EMAIL PROTECTED] >Sent: Monday, March 20, 2006 9:34 AM >To: [email protected] >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:[EMAIL PROTECTED] >> *Sent:* Saturday, March 18, 2006 6:59 PM >> *To:* [email protected] >> *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* <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> 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/% > > >> > [EMAIL PROTECTED] %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: [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> For additional commands, e-mail: >> [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> >> >> >> > > >-- >Thanks, >Deepal >................................................................ >~Future is Open~ > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- Thanks, Deepal ................................................................ ~Future is Open~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
