synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Fremantle" <pzf...@gmail.com>
Subject Re: SynapseObject - Reminder...
Date Thu, 02 Mar 2006 11:59:35 GMT
Mukund

Perhaps you need to explain your distinction between a product perspective
and an architecture perspective.

[As you know I was a product architect in the WebSphere development
organisation at IBM for a number of years.]

I am trying to think about this problem from the perspective of both the
administrator (simpler, clearer XML config), the tools author (better
integration with XML tooling, schema etc), and the mediator author (reusing
ADB tooling, building models that align with SOAP and Web Services tooling).
The proposals I am making fit clearly with all three roles.

Paul

On 3/2/06, Mukund Balasubramanian <mukund@infravio.com> wrote:
>
>  Paul:
>
>
>
> You ignore my very basic point about an extension to the NV Pair concept
> as against "supporting" an XML insert with an external schema and an "any*".
> I still believe there is simplicity of integration with the concept of an NV
> Pair and its related extensions.
>
>
>
> So the point is NOT whether XML1 or XML2 is more readable… of course XML2
> is more readable. It is just that from a "product" perspective XML1 solves
> more problems than XML2.
>
>
>
> I urge you to think with a product management hat and not with an
> architecture hat J
>
>
>
> Mukund Balasubramanian
>
>
>  ------------------------------
>
> *From:* Paul Fremantle [mailto:pzfreo@gmail.com]
> *Sent:* Thursday, March 02, 2006 4:36 PM
>
> *To:* synapse-dev@ws.apache.org
> *Subject:* Re: SynapseObject - Reminder...
>
>
>
> More comments inline!
>
>   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
>
> <pzf>Validating XML1 is equivalent to checking well-formedness in XML2.
> Very little value.</pzf>
>
>   : 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.
>
>   <pzf>This validation is MUCH more complex, and probably requires
> non-standard tools.</pzf>
>
>   From a readability point of view, I think XML1 gives you more visibility
> in terms of containment and attribution.
>
>   <pzf>I absolutely do not agree.</pzf>
>
> As per XML2 the validation has to go through an XSD, whereas in case SOs
> the attributes are type conscious.
>
>
> <pzf>You can make XML2 type aware if you like. There is a standard:
>
> <mynumber xsi:type="xs:integer">23</mynumber>.
>
> </pzf>
>
>
>
>  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.
>
>   <pzf>You can use full XPath on the OMElements out of the box on XML1,
> which is as powerful and more</pzf>
>
>   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.
>
>
> <pzf> I don't understand this statement</pzf>
>
>
>
>  [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.
>
>
> <pzf>If you change the structure of the XML you may or may not have to
> change the code. Xpath expressions can be flexible enough to support
> changes</pzf>
>
>
>
>  [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.
>
>
> <pzf>XML is a flexible data structure. You are just reinventing XML
> *INSIDE* XML.</pzf>
>
>
>
>  [Soumadeep] SOs also have generic setters and getters such as,
> getString("Foo") as against getFoo();
>
>   <pzf>ADBs have typed getters and setters, and also have well defined
> Java types. </pzf>
>
>
> Regards,
> Paul
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "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
paul@wso2.com

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

Mime
View raw message