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 Thu, 02 Mar 2006 14:41:35 GMT
Mukund Balasubramanian wrote:
>
> The distinction is that I don’t believe most people will AUTHOR these
> RAW XML configurations and I believe that most people shall GENERATE
> them from a tool of choice. Given that the schema is mediator specific
> and is pluggable, it is _/more/_ likely that a single authoring tool
> can be created for any mediator if they all follow the same schema
> than if each mediator invented its own schema.
>
> I hope this SIMPLE example demonstrates the difference in perspective.
>
XML is already a meta language and SO is a meta language built on top of
meta language (it seems SO can be trivially converted to XML as example
XML.1 -> XML.2 demonstrates) and will require new tooling whereas XML
has already plenty of tooling (XPath, XML Schemas, RelaxNG, XQuery, and
myriads of other APIs and tools including plenty of authoring tools). it
looks to me that SO capabilities are subset of XML so it may be good to
have a simpler subset but it may be also very limiting ... that reminds
me of SOAP 1.1 Encoding - it was also simple and pretty neat software
engineering as it allowed automatic generation of XML for an object
graph in any programming language (main difference was that elements
were used to encapsulate NV properties and it did not require wrapper
elements for for nested structs and it had also arrays no need for
"consumer0","consumer1" hash maps) but soapenc was reflecting too much
programming language design and not enough XML - i think there is a
lesson here ... the kernel of disagreement may be that whether XML is
too be hidden behind XML generation tools or RAW XML.2 is SIMPLE for
automatic tooling (it is definitely powerful enough and arguably may be
too powerful ...)

my .02c

best,

alek
>
> Mukund Balasubramanian
>
> ------------------------------------------------------------------------
>
> *From:* Paul Fremantle [mailto:pzfreo@gmail.com]
> *Sent:* Thursday, March 02, 2006 5:30 PM
> *To:* synapse-dev@ws.apache.org
> *Subject:* Re: SynapseObject - Reminder...
>
> 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
> <mailto: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
> <mailto:pzfreo@gmail.com>]
> *Sent:* Thursday, March 02, 2006 4:36 PM
>
>
> *To:* synapse-dev@ws.apache.org <mailto: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 <mailto:paul@wso2.com>
>
> "Oxygenating the Web Service Platform", www.wso2.com <http://www.wso2.com>
>
>
>
>
> -- 
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> <http://bloglines.com/blog/paulfremantle>
> paul@wso2.com <mailto:paul@wso2.com>
>
> "Oxygenating the Web Service Platform", www.wso2.com <http://www.wso2.com>
>


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


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