RE: SynapseObject - Reminder...

Soumadeep Thu, 02 Mar 2006 02:49:28 -0800

Hi Paul,

Comments in-lined

Soumadeep

-----Original Message-----
From: Paul Fremantle [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 02, 2006 3:13 PM
To: [email protected]
Subject: Re: SynapseObject - Reminder...

Mukund

I agree that name value pairs are not good enough. But compare these two XMLs:

---------------------------------------------------------------------------------------------------------

<SynapseObject name="ConsumerIdentification">
<SynapseObject name="consumer0">
    <Attribute name="CONSUMER_TYPE" type="String">GOLD</Attribute>
    <Attribute name="IP_ADDRESS_FROM" type="String"> 192.167.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>

---------------------------------------------------------------------------------------------------------

<ConsumerIdentification>
   <Consumer type="GOLD" http_auth_username="john" ws_sec_username="paul"/>
        <ipaddress from="192.167.6.0" to=" 192.167.6.255"/>
        <assignedService id ="StockQuote1"/>
    </Consumer>
    <Consumer type="SILVER" http_auth_username="mary" ws_sec_username="mary"/>
        <ipaddress from="192.167.6.0" to="192.167.6.255"/>
        <assignedService id ="StockQuote1" ip="192"/>
    </Consumer>
</ConsumerIdentification>

---------------------------------------------------------------------------------------------------------

The second is more readable, simpler and easier to modify. I'm certainly not suggesting that we HAVE to use Schema, but the fact is that you CAN validate with Schema whereas XML1 you cannot validate that the CI data is correct, only that generic format is right. This is equivalent to XML well-formedness checking which is much weaker.
[Soumadeep] Correction, we can validate XML1: we haven't put the validate method yet ... the xsd is at the end of the email. It will validate whether it conforms to the SO structure. It also gives you the facility to have a secondary xsd which will validate if the SO instance is of type "ConsumerIdentification" or any other mediators specific xml.

From a readability point of view, I think XML1 gives you more visibility in terms of containment and attribution.

As per XML2 the validation has to go through an XSD, whereas in case SOs the attributes are type conscious.

Regarding point 2, I wasn't suggeting that every mediator writer had to make an effort. There is no effort in doing reflection, because the code already exists in our Axis2 framework. Please look at
org.apache.axis2.databinding.ADBBean
and
org.apache.axis2.databinding.util.BeanUtil

This simple code will automatically write a bean out as XML:

        QName q = new QName("http://fremantle.org", "SimpleBean" );
        StAXOMBuilder b = new StAXOMBuilder((XMLStreamReader)BeanUtil.getPullParser(sb,q));
        OMElement el = b.getDocumentElement();
        System.out.println(el);

and this even simpler code will automatically read in a bean from XML using ADB:

SimpleBean sb2 = (SimpleBean)BeanUtil.deserialize(SimpleBean.class, omelement);

I urge you to take a look at the ADB framework.
[Soumadeep] Same can be achieved by SOs , plus the search functionality that it already has. Secondly, SOs are interchangeable meaning you can still use the xml representation (the conversion function is available in SO getXMLFragment) and also have XSD based validation as suggested by you.

[Soumadeep] Another thing that you mentioned earlier was using xpath for search. Well, true you can use it but the problem is then the xpath expressions have to be generated/written by users and maintained by them in case the xml changes, whereas this overhead is not there with the SOs.

[Soumadeep] Another advantage you get out of SO is that it's got a generic data structure so mediators developers will at least have a notion of how to handle it. The use of this structure will be very helpful when others add mediators in an existing chain of mediators.

[Soumadeep] SOs also have generic setters and getters such as, getString("Foo") as against getFoo();

Paul

The XSD for SynapseObject validation:

-------------------------------------------------------

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ibo="http://host.com/ws/2006/01/policy"
elementFormDefault="qualified" targetNamespace="http://host.com/ws/2006/01/synapseobject" id="ibo">
    <xs:element name="AttributeType" type="ibo:AttributeType"/>
    <xs:simpleType name="AttributeType">
        <xs:restriction base="NMTOKEN">
            <xs:enumeration value="String"/>
            <xs:enumeration value="Date"/>
            <xs:enumeration value="Boolean"/>
            <xs:enumeration value="Float"/>
            <xs:enumeration value="Integer"/>
            <xs:enumeration value="Long"/>
        </xs:restriction>
    </xs:simpleType>
    <xs:element name="StringOfLength255" type="ibo:StringOfLength255"/>
    <xs:simpleType name="StringOfLength255">
        <xs:restriction base="string">
            <xs:maxLength value="255"/>
        </xs:restriction>
    </xs:simpleType>
<xs:element name="SynapseObject">
    <xs:complexType>
      <xs:choice minOccurs="0" maxOccurs="unbounded">
        <xs:element ref="SynapseObject"/>
        <xs:element ref="attribute"/>
      </xs:choice>
      <xs:attribute name="name" use="required" type="ibo:StringOfLength255">
      </xs:attribute>
    </xs:complexType>
</xs:element>
<xs:element name="attribute">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="xs:anyURI">
          <xs:attribute name="name" use="required" type="ibo:StringOfLength255"/>
          <xs:attribute name="type" use="required" type="ibo:AttributeType"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
</xs:element>
</xs:schema>

On 3/2/06, Mukund Balasubramanian <[EMAIL PROTECTED]> wrote:

Paul:

I don't believe this proposal is in any way in conflict with usage of true XML. It is merely to provide structure to an otherwise flat list of name value pairs.

If you look at an average WSDD document (which supports only name value pairs) for the X-Broker, it looks phenomenally complex just because of the need to nest objects into one another.

Also, the name-value pair concept has its uses – most importantly that as a simple meta-model, it is supported by a wide variety of platforms such as registries (tModels) and also property files.

Please see my comments below in response to your specific queries:

From: Paul Fremantle [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 02, 2006 5:27 AM

To: [email protected]

Subject: Re: SynapseObject - Reminder...

I still have problems with the SynapseObject proposal.

1) I think it is much simpler for administrators to use what I call "real" XML. In other words, if there is a ClientIdentification mediator, then we either use simpler type properties to configure it, or we create a new schema that defines the configuration of the ClientIdentification metadata. This has the benefit that you can use Schema validators to validate the XML as well as Schema aware editors to generate a GUI for editing the data.

ClientIdentification can still be a structured object and not necessarily a flat list. Just analyze the use case for a multi-object array of Clients with more than one identification scheme. I agree with the schema validation argument but the onus of creating XML Schema's for property formats, configuring the namespace and schemaLocation to validate and taking on the responsibility of Object Marshalling and Mapping is just too high.

2) To make it easier for Mediator developers the schema can be converted into a Java object using ADB and XSD2Java. We can probably do this automatically using reflection if the bean is not a simple type but implements the ADB interface.

Of course they can. It just might not be worth the effort.

3) If this model is not appropriate, you can easily write a MediatorFactory (aka ProcessorConfigurator) that parses the XML and populates the mediators data.

Again, the onus of reading and manipulating the DOM lying on the developer is not something I think is necessary.

4) I personally haven't yet understood the use case for global data, but if there is one, then we should simply have a single model for referencing XML fragments. That way if two mediators want to use the same configuration data, then they can both refer to the same element. In fact, we could do this using the Resource model we already have.

I know that what we have here is two different views on how to use XML. The SO proposal uses a generic XML format to store specific data, and therefore loses out on all the useful stuff that XML provides natively - schema validation, readability, tool support, etc.

The truth is that this is useful only as an EXTENSION to the NV model and NOT as a replacement for XML J

Paul

On 3/1/06, Vikas <[EMAIL PROTECTED]> wrote:

Hi...

1) If main processor comes across an xml fragment of type SynapseObject in synapse.xml it needs to call a processor

    (SynapseObjectProcessor maybe) to convert the xml fragment into a SynapseObject instance.

2) But we need a place holder for this instance, now the question is where to put it for further reference.

From a scoping perspective, we can scope it at two levels

a) specific to a mediator

If it is specific to a mediator then we should extend the current mediator to have a member variable of type hashtable and appropriate getters and setters. We can push the SynapseObject in the hashtable, this also allows the user to use any kind of object if in case they choose not to you SynapseObject.

b) global.

For global usages we can put synapseObject instances in the SynapseEnvironment which can be used by any part of synapse.

The getters and setters might look up the hierarchy... Mediator's hashtable, then environment...

~Vikas.

----- Original Message -----

From: Saminda Abeyruwan

To: [email protected]

Sent: Tuesday, February 28, 2006 11:20 AM

Subject: Re: SynapseObject - Reminder...

Hi,

Please be kind enough clarify the following small questions.

1. As every element <foo/> in the synapse.xml maps to a FooMediator, how does <foo/> gets the info out of <synapseobject/>. ex: does it as follows?
<foo>
    <synapseobject name="xx">
            <synapseobject xx="xx"/> [1..n]
     </synapseobject>
</foo>

2. Does every mediator get a reference to <synapseobject/> or a selected few such as <servicemediator/> or <classmediator/> get the reference to <synapseobject/>.
3. Synapse now has a <define name="some_name"/> mediator and this mediator can reference this by <refdefine ref="some_name"/>
Is it possible to have a scenario as follows

<synapse xmlns="http://ws.apache.org/ns/synapse">

   <servicemediator service="service1">
        <refdefine ref="customer_properties"/>
   </service>

   <classmeditator class="com.service.Service2>
         <refdefine ref="customer_properties"/>
   </classmediator>

   <servicemediator service="service3">
        <synapseobject>
              <attribute name="url" type="STRING">http://%3c</attribute>
              <synapseobject name="consumern">
                  <attribute name="identifier" type="STRING">someID</attribute>
                  <attribute name="priority" type="INTEGER">2</attribute>
            </synapseobject>
        </synapseobject>
   </servicemediator>

    <define name="customer_properties">
         
         <synapseobject name="service1">
              <attribute name="url" type="STRING">http://%3c</attribute>
              <synapseobject name="consumer0">
                  <attribute name="identifier" type="STRING">someID</attribute>
                  <attribute name="priority" type="INTEGER">2</attribute>
            </synapseobject>
           <synapseobject name="consumer1">
                <attribute name="identifier" type="STRING">someID</attribute>
                <attribute name="priority" type="INTEGER">6</attribute>
            </synapseobject>
       </synapseobject>
       
      <synapseobject name="service2">
              <attribute name="url" type="STRING">http://%3c</attribute>
              <synapseobject name="consumer0">
                  <attribute name="identifier" type="STRING">someID</attribute>
                  <attribute name="priority" type="INTEGER">2</attribute>
            </synapseobject>
           <synapseobject name="consumer1">
                <attribute name="identifier" type="STRING">someID</attribute>
                <attribute name="priority" type="INTEGER">6</attribute>
            </synapseobject>
       </synapseobject>
    </define>
</synapse>

4. As we agreed on, <synapseobject/> will be an extension, and what would be the way of integrating this in to Synapse at run time.

Thank you

Saminda

On 3/27/06, Vikas <[EMAIL PROTECTED]> 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]>

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

~Vikas

--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]

"Oxygenating the Web Service Platform", www.wso2.com

--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]

"Oxygenating the Web Service Platform", www.wso2.com

RE: SynapseObject - Reminder...

Reply via email to