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 Tue, 21 Mar 2006 07:39:29 GMT
Simple and Short answer : XMLBeans does not support rpc/encoded and
adding MTOM is a hack as well..

Long answer : too long :) see for example [1]

-- dims

[1] http://marc.theaimsgroup.com/?l=axis-dev&m=112827752019498&w=2

On 3/21/06, Hariharasudhan.D <hari@infravio.com> wrote:
>  Hey Soumadeep,
>
>  Thanks for your reply. Good that at least someone notices my email.But i
> still didn't get any answers for " why ADB is being used when XML Bean is
> already there and that too as an Apache Project ?"
>
>
>
>  Soumadeep wrote:
>
>
>
>  Hi Hari,
>
>  Interesting observation I must say. Please see my comments inline.
>
>
>
>  -----Original Message-----
>  From: Hariharasudhan.D [mailto:hari@infravio.com]
>  Sent: Monday, March 20, 2006 8:56 PM
>  To: synapse-dev@ws.apache.org
>  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?
>  You are right, the suggestion was more of a flip-flop, meaning if a user
> wants to use ADB then they will generate the classes then write the logic to
> do search (just like XMLBeans). On the other hand if they want to use XML
> directly for configuration then they would use xpath to do search. Both can
> be used in conjunction but handled separately. This is one of the reasons
> the use case was provided. Using SynapseObject you don't need handle it
> separately everything is inbuilt. And if you have read the latest thread
> SynapseObject would now operate on simple XML and not the way it was earlier
> represented (Paul's initial concern about the XML format)
>
>
>
>  The other obvious question is if we already have xmlBeans for data binding
> then what's the need for ADB?
>  I don't think I can comment on that!
>
>
>
>  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> 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
>
>
>
>
>
>
>
>  --
>  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 For additional
> commands, e-mail: 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 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