synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: SynapseObject - Reminder...
Date Mon, 20 Mar 2006 17:19:19 GMT
Vikas wrote:
> <Vikas>
>  
> The basic idea why we do not opt for ADB/XMLBeans or any other
> XSD2Java mechanism is that a user should not be made to re-generate
> schemas and the based-classes in case the xml content changes...
> If we opt for SynapseObject, the basic schema remains the same,
> irrespective of the contents defined in the xml..
> As mentioned earlier, SynapseObject has only 2 structural constraints..
>  * Every SO[SynapseObject] can have either an attribute or
> * Another SO as a child..
> The number of attributes or their specific details are not of concern
> to the SynapseObject as such...
i think you can use XML just fine without any XML schemas and in such
case you can write XSynapseObject that has the same functionality as
SynapseObject but works directly with XML

As you mentioned earlier, XSynapseObject represent XML element and has
only 2 structural constraints..
 * Every XSO[SynapseObject] can have either an attribute or (XML element
has XML attributes that are name=value pairs of strings)
* Another SO as a child.. (XML element can have other XML elements as
children naturally ordered)
The number of attributes or their specific details are not of concern to
the XSynapseObject as such... (there is no limits on number attributes
in XML)


XSynapseObject wraps DOM::Element {
   String getName()
   String getAttribute(String name)
   setAttribute(String name, String value);
   Integer getIntAttr(String name)
   setInt Attribute(String name, int value);
   setInt Attribute(String name, Integer value);
   // the same for long and other primitive types
   Iterable<String> attributes();
   Iterable<XSO> elements();
   Iterable<XSO> elementsWtihName(String name);
   Iterable<XSO> search( .... )
   XSO findFirstElementWithName( String elName)
   XSO findFirstElementWithAttribute( String attrName )
   // and son on
}

>  
> So if a user decides to add another attribute, he need not change the
> schema and re-generate the classes...
check
>  
> The search methods in SO, provide the users with powerful search
> mechanisms without the overhead of switching between XML[and using
> X-Path to search] and the Java representation generated using XSD2Java...
check  - XSO.search()
>  
> So we basically provide the create/store/read , generating the
> java code capabilities and manipulate them within a single object..
check
>  
> Since the SO design is not schema or class dependent, any mediator can
> use it and understand it...thus easily allowing mediators to share and
> manipulate data without writing parsers/transformers...
check (this is general property of XML as a _meta_ language)
>  
> The use-case below, demonstrating the dependency between SLA and CI
> mediators do shed light on the scenario...
if XSO was used

        XSynapseObject person = new SynapseObject("Person");
        person.setString("firstName", "Alek");


it would produce following XML

<Person firstName="Alek">

(the only difference is that in this case firstName attribute is not
self types - an alternative would be to encode type in inside attribute
value ex. priority="{int}0" or have attributes as elements <priority
attrType="int">0</priority> but i do not think either is required as
typing is hardcoded in the Java cod anyway when setInt/getInt is called)

>  
> Thus,
> <SynapseObject name="Person">
>     <Attribute name="firstName" type="String">Vikas</Attribute>
> </SynapseObject>
>  
> is similar to(in terms of XSD)
>  
> <SynapseObject name="Person">
>     <Attribute name="firstName" type="String">Vikas</Attribute>
>     <Attribute name="lastName" type="String">Roonwal</Attribute>
> </SynapseObject>
>  
> The mediator writer can always throw an "ATTRIBUTE MISSING" exception
> or switch to using the new Attribute, without the hassles of schema
> writing or class re-generation..
check - there is no error if there are additional attributes in XML and
even if XML schemas is used it is possible to declare that unknown
attributes should be ignored)
>  
> Comments please...
hope you find that other perspective useful

best,

alek
>  
> </Vikas>
> ps: The link to SynapseObject's code
> http://svn.apache.org/repos/asf/incubator/synapse/trunk/scratch/infravio/synapse-SO/
>
> >
> > On 3/20/06, Vikas <vikas@infravio.com <mailto:vikas@infravio.com>>
> wrote:
> >>
> >> Hi..
> >> Maybe i am pushing back the discussion to the first stage..
> >> But throughout this discussion, though people have been commenting on
> >> standard stuff like Axiom/ADB/XMLBeans,etc; I have not seen a single
> >> implementation that covers the full capabilities that SynapseObject
> >> offers...
> >> Maybe I am being naive, but isn't ease of usage that matters for
> Mediator
> >> writers??
> >>
> >> Tried the utility/wrapper class on OMElement, but thought that its
> not going
> >> to work out without the XML structure..
> >> Find the code attached ...
> >>
> >> ~Vikas
> >>
> >>
> >>
> >>
> >> ----- Original Message -----
> >> From: Hariharasudhan.D
> >> To: synapse-dev@ws.apache.org <mailto:synapse-dev@ws.apache.org>
> >>
> >> Sent: Monday, March 20, 2006 8:56 PM
> >> Subject: Re: SynapseObject - Reminder...
> >>
> >> Hi,
> >>
> >> I was out of this for a while but just wanted to know what is the
> >> co-relation between ADB and xpath in this context. ADB is more of 
> a light
> >> weight  schema compiler and xpath works on xml. How are we marrying
> these
> >> two aren't they parallel?
> >>
> >> The other obvious question is if we already have xmlBeans for data
> binding
> >> then what's the need for ADB?
> >>
> >> Would highly appreciate if  someone can enlighten me on this. FYI,
> I could
> >> not make sense of what Saminda tried to explain. From the use case
> described
> >> below I think SynapseObject would be very useful for handling
> mediators.
> >>
> >> Hari
> >>
> >> Davanum Srinivas wrote:
> >> 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 <mailto: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 <mailto: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
> <mailto: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 <mailto: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
> <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
> <mailto: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
> <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>
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Davanum Srinivas : http://wso2.com/blogs/
> >>
> >> ---------------------------------------------------------------------
> >> 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>
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >>  ________________________________
> >>  Regards,
> >> Hariharasudhan.D.
> >>
> >>
> >> When I do good, I feel good; when I do bad, I feel bad.That�s my
> religion .
> >> - Abraham Lincoln
> >>
> >> ---------------------------------------------------------------------
> >> 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>
> >>
> >> ---------------------------------------------------------------------
> >> 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>
> >>
> >>
> >>
> >
> >
> > --
> > Davanum Srinivas : http://wso2.com/blogs/
> >


-- 
The best way to predict the future is to invent it - Alan Kay


Mime
View raw message