synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mukund Balasubramanian" <muk...@infravio.com>
Subject RE: SynapseObject - Reminder...
Date Thu, 02 Mar 2006 12:35:47 GMT
Paul:

 

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.

 

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

 

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