synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Asankha C. Perera" <asan...@wso2.com>
Subject Re: XSD generation for mediator syntax in Synapse
Date Wed, 12 Jul 2006 12:43:40 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Hadrian<br>
<br>
Could you explain a bit more on how you propose a Mediator writer makes
the schema available to Synapse? Right now we load implementations of
the MediatorFactory interface from the classpath (see
MediatorFactoryFinder:registerExtensions) so I guess the
MediatorFactory would have to have some means (a method) to let Synapse
know which file contains the schema for that mediator..?<br>
<br>
thanks<br>
asankha<br>
<br>
Hadrian Zbarcea wrote:
<blockquote
 cite="midb095cf4f0607111058m2ce5f5ib58fb25483940b5c@mail.gmail.com"
 type="cite">Hi Asankha,<br>
  <br>
I think we agree on all counts except one.&nbsp; Actually I understand it
could be done that way, but I don't necessarily agree that we solve any
problem.<br>
  <br>
What I understand is this.&nbsp; We, and any implementor of a mediator that
can be instantiated using xml will need to:
  <br>
1. Define the semantics of the mediator and its configuration.&nbsp;
Formalize the xml configuration in an xml schema.<br>
2. Implement the factory and the mediator.<br>
  <br>
Now, the xml configuration will look something like:
  <br>
&nbsp; &lt;rules xmlns="<a href="http://ws.apache.org/ns/synapse">http://ws.apache.org/ns/synapse</a>"
xmlns:foo="<a href="http://www.example.com/synapse/extension/foo">http://www.example.com/synapse/extension/foo
  </a>"&gt;<br>
&nbsp; &nbsp;&nbsp;&nbsp; &lt;log level="full"/&gt; &lt;!-- for
instance --&gt;<br>
&nbsp; &nbsp;&nbsp;&nbsp; &lt;foo:mediator attr="value, etc. etc." /&gt;<br>
&nbsp; &lt;/rules&gt;<br>
I think it makes sense to enforce a rule (and it's an assumption I'm
making) that extensions written by third parties MUST be in a target
namespace *other* than the Synapse namespace.&nbsp; Then a namespace mapping
MUST exist in the xml file (the foo namespace prefix above).&nbsp; The
targetNamespace of the custom extension could be an http based url
(usually the case) or not.&nbsp; If it is an http based url the definition
of schema could be available (usually true) at that url or not.&nbsp; We
have two situations now.
  <br>
  <br>
1. The xml schema is available at the http location specified as
targetNamespace.<br>
2. The url is not http based or is not available at the specified url.<br>
  <br>
In the first case the validator will use the schema at the http
location for validation, and that schema should be considered the
authoritative source, in which case the copy of the schema available
from the factory had imho no value.&nbsp; Tools and any interested parties
could access the schema at the http url or make a local copy, etc.
  <br>
In the second case we need to make the schema available to the
validator at a location specified via a url and the api won't help in
this case either.<br>
  <br>
In both cases the schema could (must for 2nd case) be packaged in the
jar anyway and I think this is a better solution which does not require
and api change. <br>
  <br>
Regards<br>
Hadrian<br>
  <br>
  <div><span class="gmail_quote">On 7/11/06, <b
 class="gmail_sendername">Asankha C. Perera</b> &lt;<a
 href="mailto:asankha@wso2.com">asankha@wso2.com</a>&gt; wrote:</span>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:
1ex;">
    <div>
    <div bgcolor="#ffffff" text="#000000">Hi Hadrian<br>
    <br>
Let me try to explain a bit more about my recent changes.. </div>
    <div><span class="q"><br>
    <blockquote
 cite="http://midb095cf4f0607072031j78151788ud6052072edddded6@mail.gmail.com"
 type="cite">What I understand is that you propose a way to generate a
schema from the code and you propose additions to the api that would
make this possible.&nbsp; IMHO this is flawed in at least two ways. <br>
    </blockquote>
    </span></div>
    <div>No. What I propose is to allow a *mediator factory* (not a
medaitor) to
specify the schema that could be used to validate an XML configuration
as well as be used for tooling as you note, or even to generate a UI to
configure such a mediator! Now the MedaitorFactory interface is in
o.a.s.config.xml package, and is totally about the XML configuration of
the mediators. It is one of the ways in which a Mediator writer can
specify how instances of the mediator could be created and configured
through an XML configuration. I think renaming the MediatorFactory
interface as XMLMediatorFactory would help in making things clearer.
Also I am in the process of introducing one method to this interface to
get the element declaration, instead of the getTagSchemaType() and
getTagSchema() pair to make things less complicated (hopefully :-))..
give me a bit of time to do this..</div>
    <div><span class="q"><br>
    <blockquote
 cite="http://midb095cf4f0607072031j78151788ud6052072edddded6@mail.gmail.com"
 type="cite">First, Synapse's design suggests that the construction of
the mediator tree is independent of configuration in general and xml
configuration in particular. <br>
    </blockquote>
    </span></div>
    <div>Yes, now if you generate the SynapseConfiguration by any other
means
than through an XML configuration, you will need to perform your
validation etc accordingly. Right now, the SynapseConfigurationBuilder
is the connection between the XML based configuration and the rest of
Synapse.
    </div>
    <div><span class="q">
    <blockquote
 cite="http://midb095cf4f0607072031j78151788ud6052072edddded6@mail.gmail.com"
 type="cite">So, the feature you are proposing would only make sense,
design-wise, for the current xml configuration mechanism. <br>
    </blockquote>
    </span></div>
    <div>Unfortunately yes.. when someone introduces another mechanism
to create
a Synapse configuration, they will have to solve this problem again to
suit that environment.</div>
    <div><span class="q"><br>
    <blockquote
 cite="http://midb095cf4f0607072031j78151788ud6052072edddded6@mail.gmail.com"
 type="cite">Second reason is that I personally prefer the contract
first approach.&nbsp; This sparked many religious debates, and it is not my
intent to start one here.&nbsp; However, I think that the syntax and it's
semantics should be defined and documented first and not be an artifact
of the build system. <br>
    </blockquote>
    </span></div>
    <div>The generated schema is not an artifact of the build system -
again, we
are *not* generating a schema at build or runtime. The mediaor
factories defines the schema fragments for each mediator, and at
runtime we just collect these to build the overall schema required to
validate a configuration.</div>
    <div><span class="q"><br>
    <br>
    <blockquote
 cite="http://midb095cf4f0607072031j78151788ud6052072edddded6@mail.gmail.com"
 type="cite">I would also gladly volunteer to help with the effort. <br>
    </blockquote>
    </span></div>
    <div>As always, your feedback and help is very much appreciated
:-)..</div>
    <div><span class="q"><br>
    <br>
    <blockquote
 cite="http://midb095cf4f0607072031j78151788ud6052072edddded6@mail.gmail.com"
 type="cite">The second issue you raised about dependencies is a valid
one, but I suspect less so with jdk 1.5.<br>
    </blockquote>
    </span></div>
    <div>Im not sure I understand what you mean here?<br>
    </div>
    <div><span class="sg"><br>
asankha</span></div>
    <div><span class="e" id="q_10c5cb11cc4c386e_14"><br>
    <blockquote
 cite="http://midb095cf4f0607072031j78151788ud6052072edddded6@mail.gmail.com"
 type="cite"><br>
My 2 cents,<br>
Hadrian<br>
      <br>
      <br>
      <div><span class="gmail_quote">On 7/7/06, <b
 class="gmail_sendername">Asankha
C. Perera </b> &lt;<a href="mailto:asankha@wso2.com" target="_blank"
 onclick="return top.js.OpenExtLink(window,event,this)">asankha@wso2.com</a>&gt;
wrote:</span>
      <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:
1ex;">
        <div>
        <div bgcolor="#ffffff" text="#000000">Saminda<br>
        <br>
Yes, I know that the schema's I checked in may have a few issues to
fix..and areas for improvement, as its the initial version.. and
greatly appreciate your feedback to get them fixed :-)<br>
        <br>
thanks<br>
        </div>
        <div><span>asankha</span></div>
        <div><span><br>
        <br>
Saminda Abeyruwan wrote:
        <blockquote
 cite="http://midaa8fdb10607070259v79ce934dqac50a05f6e00fa95@mail.gmail.com"
 type="cite"><br>
          <br>
          <div><span class="gmail_quote">On 7/7/06, <b
 class="gmail_sendername">Asankha
C. Perera</b> &lt;<a href="mailto:asankha@wso2.com" target="_blank"
 onclick="return top.js.OpenExtLink(window,event,this)">asankha@wso2.com</a>&gt;
wrote:</span>
          <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:
1ex;">
            <div>
            <div bgcolor="#ffffff" text="#000000">This is with
reference to
the
chat discussion we had yesterday..<br>
            <br>
This feature allows mediators to expose the XML configuration syntax
for them, through their mediator factories- and thus allows Synapse to
validate a configuration, as well as for additional purposes in future.
How it is achieved is as follows.<br>
            <br>
The MediatorFactoryFinder loads all core mediators, and dynamically
finds any extension mediators from the classpath. Each mediator should
have a MediatorFactory which will expose the schema fragment to define
its element and complex type. Lets look at some examples<br>
            <br>
The LogMediatorFactory exposes the following schema fragment through
its implementation of the <b>public XmlSchema getTagSchema() </b>method<br>
            <br>
&lt;xs:element name="log" type="<b>log_type</b>"/&gt;<br>
&lt;xs:complexType name="log_type"&gt;<br>
&nbsp; &lt;xs:sequence minOccurs="0" maxOccurs="unbounded"&gt;<br>
&nbsp;&nbsp;&nbsp; &lt;xs:element name="property" type="synapse:property_type"/&gt;<br>
&nbsp; &lt;/xs:sequence&gt;<br>
&nbsp; &lt;xs:attribute name="level"/&gt;<br>
&nbsp; &lt;xs:attribute name="seperator"/&gt;<br>
&lt;/xs:complexType&gt;</div>
            </div>
          </blockquote>
          <div><br>
As an example ,<br>
Wouldn't this should be simplified as follows,<br>
          <br>
&lt;xsd:element name="log&gt;<br>
&nbsp;&nbsp; &lt;xsd:complexType&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xsd:sequence&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xsd:element name="property" type="syn:property_type" minOccurs="0"
maxOcuurs="unbounded"/&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xsd:sequence&gt;<br>
&nbsp;&nbsp; &lt;/xsd:complexType&gt;<br>
&lt;/xsd:element&gt;<br>
          </div>
          <br>
          <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:
1ex;">
            <div>
            <div bgcolor="#ffffff" text="#000000">Now as Synapse does
not
know
which complex type in the above fragment
defines the type for the Log mediator element, we also need the
mediator factory to expose it through the <b>public QName
getTagSchemaType()</b> method, which will return "log_type". (A schema
fragment as shown above may define more than one complex type - e.g.
for the switch mediator)<br>
            <br>
Now if we want to validate a Synapse configuration, we need to include
"log_type" as a valid "mediator_type" - please refer [1] which gives a
brief sample Synapse.XSD<br>
            <br>
&lt;xs:complexType name="mediator_type"&gt;<br>
&nbsp; &lt;xs:sequence&gt; <br>
&nbsp; &lt;xs:choice&gt;<br>
&nbsp;&nbsp;&nbsp; &lt;xs:element name="sequence" type="sequence_type"/&gt;<br>
&nbsp;&nbsp;&nbsp; &lt;xs:element name="log" type="log_type"/&gt;<br>
&nbsp;&nbsp;&nbsp; ...................<br>
&nbsp;&nbsp;&nbsp; &lt;xs:element name="javascript" type="javascript_type"/&gt;
<br>
&nbsp; &lt;/xs:choice&gt;<br>
&nbsp; &lt;/xs:sequence&gt;<br>
&lt;/xs:complexType&gt;<br>
            <br>
Without "mediator_type" having the "log_type" as a valid choice, we
cannot validate a configuration properly. The discussion we had
yesterday was more around the extension mediators one would write for
Synapse, and the use of the <i>public QName getTagSchemaType() method </i>in
that instance. Take a look at the Javascript mediator, and how its
included into the "mediator_type" set of choices. As we dynamically
locate the JS mediator from the classpath and load it as a mediator, we
do not know which complex type within its schema fragment defines the
actual type for the JS mediator - to be included into the
"mediator_type".. I hope this explains why we need the above method on
the MediatorFactory<br>
            <br>
The second issue we discussed yesterday was on the dependency of the
Apache XmlSchema that we use for the above, to Xalan (and any of its
dependencies such as Xerces..) Right now we do not ship any code that
requires Xerces or Xalan with the Synapse core - hence the code right
now hacks to see if these are available during runtime, and performs
the loading of the schemas if its possible, and remains silent (with a
WARN log message) if it cannot process the schemas due to the non
availability of the above.<br>
            <br>
Your thoughts, comments and suggestions welcome<br>
            <br>
asankha<br>
            <br>
References <br>
[1] <a
 href="http://wiki.apache.org/incubator/Synapse/InProgress/Synapse_XSD"
 target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://wiki.apache.org/incubator/Synapse/InProgress/Synapse_XSD</a><br>
            </div>
---------------------------------------------------------------------
To unsubscribe, e-mail: <a
 href="mailto:synapse-dev-unsubscribe@ws.apache.org" target="_blank"
 onclick="return top.js.OpenExtLink(window,event,this)">synapse-dev-unsubscribe@ws.apache.org</a>
For additional commands, e-mail: <a
 href="mailto:synapse-dev-help@ws.apache.org" target="_blank"
 onclick="return top.js.OpenExtLink(window,event,this)">synapse-dev-help@ws.apache.org</a>
            </div>
          </blockquote>
          </div>
          <br>
        </blockquote>
        </span></div>
        </div>
        <div><span>---------------------------------------------------------------------
To unsubscribe, e-mail: <a
 href="mailto:synapse-dev-unsubscribe@ws.apache.org" target="_blank"
 onclick="return top.js.OpenExtLink(window,event,this)">synapse-dev-unsubscribe@ws.apache.org</a>
For additional commands, e-mail: <a
 href="mailto:synapse-dev-help@ws.apache.org" target="_blank"
 onclick="return top.js.OpenExtLink(window,event,this)">synapse-dev-help@ws.apache.org</a>
        </span></div>
      </blockquote>
      </div>
      <br>
    </blockquote>
    </span></div>
    </div>
    <div><span class="e" id="q_10c5cb11cc4c386e_16">---------------------------------------------------------------------
To unsubscribe, e-mail: <a
 href="mailto:synapse-dev-unsubscribe@ws.apache.org" target="_blank"
 onclick="return top.js.OpenExtLink(window,event,this)">synapse-dev-unsubscribe@ws.apache.org</a>
For additional commands, e-mail: <a
 href="mailto:synapse-dev-help@ws.apache.org" target="_blank"
 onclick="return top.js.OpenExtLink(window,event,this)">synapse-dev-help@ws.apache.org</a>
    </span></div>
  </blockquote>
  </div>
  <br>
</blockquote>
</body>
</html>


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