synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Soumadeep" <>
Subject RE: SynapseObject - Reminder...
Date Sun, 19 Mar 2006 06:30:43 GMT

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:

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

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
1) IP {eg. 192.168.5.*}
2) IP Range {eg.}
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:

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"></Attribute>
   <Attribute name="IP_ADDRESS_TO" type="String"></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 name="consumer1">
   <Attribute name="CONSUMER_TYPE" type="String">SILVER</Attribute>
   <Attribute name="IP_ADDRESS_FROM" type="String"></Attribute>
   <Attribute name="IP_ADDRESS_TO" type="String"></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>

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 =
obj will contain all the required values if identified!


xml Fragment:

<SynapseObject name="SLA">
    <SynapseObject name="consumer0">
        <SynapseObject name="Service0">
            <Attribute name="EPR"
            <Attribute name="priority" type="Integer">0</Attribute>
        <SynapseObject name="Service1">
            <Attribute name="EPR"
            <Attribute name="priority" type="Integer">1</Attribute>

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 =

// 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 =
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");

  -----Original Message-----
  From: Saminda Abeyruwan []
  Sent: Saturday, March 18, 2006 6:59 PM
  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"
       <SynapseObject name="consumer">
       <attribute name="ip" type="STRING"></attribute>

  which is similar to,

       <service> http://myhost:myport/Service </service>

  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

  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


  On 3/17/06, Sanjiva Weerawarana <> 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:
    > <
    > %3e>
    > and the source code has been available in the Scratch
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.


    To unsubscribe, e-mail:
    For additional commands, e-mail:

View raw message