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:[EMAIL PROTECTED]
Sent: Thursday, March 02, 2006
5:30 PM
To: [email protected]
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 <[EMAIL PROTECTED]>
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:[EMAIL PROTECTED]]
Sent: Thursday, March 02, 2006
4:36 PM
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>
--
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
|
