You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Tom Oinn <tm...@ebi.ac.uk> on 2005/11/08 15:29:11 UTC
[Axis2] Schema parsing
Hi all,
We're planning to use Axis2 in Taverna to construct SOAP requests,
probably not using any form of data binding as we have our own and just
using the send / receive SOAP body functionality.
This means we have to be able to inspect arbitrary WSDL documents and
determine the input schema in such a way that we can present appropriate
'input' and 'output' ports on our workflow components - this is slightly
non trivial as we can attempt to split up sequence elements on input
documents into different inputs and suchlike.
Until recently we were using the WSIF library to present a slightly
friendlier interface on the schema support in WSDL4J but changes in the
latter have broken this for the time being.
It occurs to me that our requirement is probably not unique, and that it
might be useful for the more message driven approach in Axis2 to have
richer schema support for type declarations in WSDL definitions. Unless
anyone knows of a really good existing lightweight Java model for schema
(I've looked but no luck) that can be glued into WSDL4J's Definition
model we're going to write one - the purpose being to inspect a WSDL
file and, for a given operation, provide enough information in a
friendly and easy to digest form for a dynamic invoker to build a
compliant request document / parse a response. Note that this is _not_ a
databinding layer, just type metadata. Actual databinding could
obviously be driven off it though.
1) Does this exist?
2) Would anyone else use it?
3) We're happy to contribute it to Axis2, to any other project or to
manage it ourselves, any preferences?
Cheers,
Tom
Re: [Axis2] Schema parsing
Posted by Eric Johnson <er...@tibco.com>.
Tom Oinn wrote:
> Hi all,
>
> We're planning to use Axis2 in Taverna to construct SOAP requests,
> probably not using any form of data binding as we have our own and
> just using the send / receive SOAP body functionality.
>
> This means we have to be able to inspect arbitrary WSDL documents and
> determine the input schema in such a way that we can present
> appropriate 'input' and 'output' ports on our workflow components -
> this is slightly non trivial as we can attempt to split up sequence
> elements on input documents into different inputs and suchlike.
>
> Until recently we were using the WSIF library to present a slightly
> friendlier interface on the schema support in WSDL4J but changes in
> the latter have broken this for the time being.
>
> It occurs to me that our requirement is probably not unique, and that
> it might be useful for the more message driven approach in Axis2 to
> have richer schema support for type declarations in WSDL definitions.
> Unless anyone knows of a really good existing lightweight Java model
> for schema (I've looked but no luck) that can be glued into WSDL4J's
> Definition model we're going to write one - the purpose being to
> inspect a WSDL file and, for a given operation, provide enough
> information in a friendly and easy to digest form for a dynamic
> invoker to build a compliant request document / parse a response. Note
> that this is _not_ a databinding layer, just type metadata. Actual
> databinding could obviously be driven off it though.
>
> 1) Does this exist?
Xerces 2.7.1 has a schema API:
http://xerces.apache.org/xerces2-j/javadocs/xs/index.html
Also note that DOM 3 supports TypeInfo
(http://www.w3.org/TR/DOM-Level-3-Core/core.html#TypeInfo), although it
sounds insufficient to your needs.
I cannot speak to the remaining two questions.
-Eric.
Re: [Axis2] Schema parsing
Posted by Jim Murphy <im...@gmail.com>.
It is targeted as the object model for an XSD editor so its a little
heavy for your needs but the Eclipse XSD library[1] is the most
complete I've seen.
[1] - http://www.eclipse.org/xsd/
Jim Murphy
Mindreef, Inc.
Re: [Axis2] Schema parsing
Posted by Paul Fremantle <pz...@gmail.com>.
Tom
I always like the idea of taking a DOM-like object (how about AXIOM) and
making it typed. So instead on doing OMAbstractFactory.createOMElement(),
you could do TOMAbstractFactory.createElement(Schema s);
Then as you navigated the tree, you could query the type of a given element
and set its value using type-specific setters:
if (el.getType()==DOUBLE) el.setDouble(doub);
IBM has published a model a bit like this (SDO -
http://www-128.ibm.com/developerworks/library/specification/j-commonj-sdowmt/index.html)
but I've always found this a little heavy. I may have been overly influenced
by the implementation rather than the interface.
I like the idea of Axis2 building a TOM model (Typed Object Model) which
then uses OM under the covers. Honestly I'm not sucking up... it was the
name that popped into my head.
What do you think?
Paul
On 11/8/05, Tom Oinn <tm...@ebi.ac.uk> wrote:
>
> Sanjiva Weerawarana wrote:
> > On Tue, 2005-11-08 at 10:42 -0500, Dan Diephouse wrote:
> >> There is some schema parsing stuff here in the webservices commons:
> >>
> >> http://svn.apache.org/viewcvs.cgi/webservices/commons/trunk/XmlSchema/
> >>
> >> It sounds like you might be going a step beyond just parsing things
> into
> >> a schema oject model though?
> >
> > Since we're already using the commons schema (above) in Axis2 (for the
> > Axis2 data binding stuff), Tom would you guys be able to contribute to
> > that and help drive that to ultimate success? It doesn't seem to make
> > sense to create a parallel universe.
>
> Agreed on that, I'll have to take a proper look at the commons schema
> stuff to see whether I agree that that's the right way to go (a very
> brief look suggests it's sane). Basically I can get the QName of the
> type that the operation expects and want some way of getting the
> expected structure of a document conforming to that type to then drive
> my data binding layer. This also involved handling the rather grotty way
> the Definition object handles the various imports. Something like the
> following for usage would be ideal for us :
>
> Definition def = .... (get Definition here from WSDL4J)
> SchemaDescriber sd = new SchemaDescriber(def)
>
> ...
>
> QName operationInputType = ....
> SchemaDescription description = sd.getDescriptionFor(operationInputType)
>
> and then use 'description' to generate our input ports on the workflow
> processor and the logic required to massage those inputs into the
> request document - obviously similar things apply for outputs.
>
> Makes sense to drive this off the Definition object as this has already
> done the work of resolving imported schema (albeit badly) and if you're
> running in a WSDL centric world you almost certainly have one lying
> around anyway.
>
> Cheers,
>
> Tom
>
Re: [Axis2] Schema parsing
Posted by Tom Oinn <tm...@ebi.ac.uk>.
Sanjiva Weerawarana wrote:
> On Tue, 2005-11-08 at 10:42 -0500, Dan Diephouse wrote:
>> There is some schema parsing stuff here in the webservices commons:
>>
>> http://svn.apache.org/viewcvs.cgi/webservices/commons/trunk/XmlSchema/
>>
>> It sounds like you might be going a step beyond just parsing things into
>> a schema oject model though?
>
> Since we're already using the commons schema (above) in Axis2 (for the
> Axis2 data binding stuff), Tom would you guys be able to contribute to
> that and help drive that to ultimate success? It doesn't seem to make
> sense to create a parallel universe.
Agreed on that, I'll have to take a proper look at the commons schema
stuff to see whether I agree that that's the right way to go (a very
brief look suggests it's sane). Basically I can get the QName of the
type that the operation expects and want some way of getting the
expected structure of a document conforming to that type to then drive
my data binding layer. This also involved handling the rather grotty way
the Definition object handles the various imports. Something like the
following for usage would be ideal for us :
Definition def = .... (get Definition here from WSDL4J)
SchemaDescriber sd = new SchemaDescriber(def)
...
QName operationInputType = ....
SchemaDescription description = sd.getDescriptionFor(operationInputType)
and then use 'description' to generate our input ports on the workflow
processor and the logic required to massage those inputs into the
request document - obviously similar things apply for outputs.
Makes sense to drive this off the Definition object as this has already
done the work of resolving imported schema (albeit badly) and if you're
running in a WSDL centric world you almost certainly have one lying
around anyway.
Cheers,
Tom
Re: [Axis2] Schema parsing
Posted by Dan Diephouse <da...@envoisolutions.com>.
Dan Diephouse wrote:
> Sanjiva Weerawarana wrote:
>
>> On Tue, 2005-11-08 at 10:42 -0500, Dan Diephouse wrote:
>>
>>
>>> There is some schema parsing stuff here in the webservices commons:
>>>
>>> http://svn.apache.org/viewcvs.cgi/webservices/commons/trunk/XmlSchema/
>>>
>>> It sounds like you might be going a step beyond just parsing things
>>> into a schema oject model though?
>>>
>>
>>
>> Since we're already using the commons schema (above) in Axis2 (for the
>> Axis2 data binding stuff), Tom would you guys be able to contribute to
>> that and help drive that to ultimate success? It doesn't seem to make
>> sense to create a parallel universe.
>>
>>
> Where should contributions and questions be directed for the XmlSchema
> stuff?
A couple ideas from the few hours that I've spent with the XmlSchema
project that are probably related to what Tom was suggesting...
Wrking with the XmlSchema model is a real PITA. It'd be very nice if we
could use the schema model to drive a more workable form that is easier
to use. For instance, right now to find all the elements allowed in a
schema type you have to drill through all the sequences and substitution
groups, etc.
Maybe we could do something like this:
XmlTypeModel model = new XmlTypeModel(xmlSchemaElement);
List elements = model.getElements();
for (XmlElement element : elements)
{
element.getQName();
List elements = element.getElements();
List attributes = element.getAttributes();
boolean allowAnyElement = element.isAnyElementAllowed();
}
List attributes = model.getAttributes();
One of the criteria for a wsdl operation to be "wrapped" is that it
doesn't have an attributes. This type of pseudo model would make it
easier to determine such a thing. Kinda like XmlBeans schema stuff, but
simpler and not tied to xmlbeans. Is this reinventing the wheel? I
figure there has to be something like this already...
Another idea idea is that we could have a wsdl package, with a class like:
public interface WSDLTypesHelper
{
XmlSchemaCollection getSchemas(Types types);
boolean isWrapped(BindingOperation bindingOp);
}
Just some thoughts... Cheers,
- Dan
--
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com
Re: [Axis2] Schema parsing
Posted by Dan Diephouse <da...@envoisolutions.com>.
Sanjiva Weerawarana wrote:
>On Tue, 2005-11-08 at 10:42 -0500, Dan Diephouse wrote:
>
>
>>There is some schema parsing stuff here in the webservices commons:
>>
>>http://svn.apache.org/viewcvs.cgi/webservices/commons/trunk/XmlSchema/
>>
>>It sounds like you might be going a step beyond just parsing things into
>>a schema oject model though?
>>
>>
>
>Since we're already using the commons schema (above) in Axis2 (for the
>Axis2 data binding stuff), Tom would you guys be able to contribute to
>that and help drive that to ultimate success? It doesn't seem to make
>sense to create a parallel universe.
>
>
Where should contributions and questions be directed for the XmlSchema
stuff?
- Dan
--
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com
Re: [Axis2] Schema parsing
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Tue, 2005-11-08 at 10:42 -0500, Dan Diephouse wrote:
> There is some schema parsing stuff here in the webservices commons:
>
> http://svn.apache.org/viewcvs.cgi/webservices/commons/trunk/XmlSchema/
>
> It sounds like you might be going a step beyond just parsing things into
> a schema oject model though?
Since we're already using the commons schema (above) in Axis2 (for the
Axis2 data binding stuff), Tom would you guys be able to contribute to
that and help drive that to ultimate success? It doesn't seem to make
sense to create a parallel universe.
> > It occurs to me that our requirement is probably not unique, and that
> > it might be useful for the more message driven approach in Axis2 to
> > have richer schema support for type declarations in WSDL definitions.
> > Unless anyone knows of a really good existing lightweight Java model
> > for schema (I've looked but no luck) that can be glued into WSDL4J's
> > Definition model we're going to write one - the purpose being to
> > inspect a WSDL file and, for a given operation, provide enough
> > information in a friendly and easy to digest form for a dynamic
> > invoker to build a compliant request document / parse a response. Note
> > that this is _not_ a databinding layer, just type metadata. Actual
> > databinding could obviously be driven off it though.
Big +1 for using a schema model for introspective execution. Again,
please look at commons schema and see whether you can help improve
that ..
Sanjiva.
Re: [Axis2] Schema parsing
Posted by Dan Diephouse <da...@envoisolutions.com>.
There is some schema parsing stuff here in the webservices commons:
http://svn.apache.org/viewcvs.cgi/webservices/commons/trunk/XmlSchema/
It sounds like you might be going a step beyond just parsing things into
a schema oject model though?
Tom Oinn wrote:
> Hi all,
>
> We're planning to use Axis2 in Taverna to construct SOAP requests,
> probably not using any form of data binding as we have our own and
> just using the send / receive SOAP body functionality.
>
> This means we have to be able to inspect arbitrary WSDL documents and
> determine the input schema in such a way that we can present
> appropriate 'input' and 'output' ports on our workflow components -
> this is slightly non trivial as we can attempt to split up sequence
> elements on input documents into different inputs and suchlike.
>
> Until recently we were using the WSIF library to present a slightly
> friendlier interface on the schema support in WSDL4J but changes in
> the latter have broken this for the time being.
>
> It occurs to me that our requirement is probably not unique, and that
> it might be useful for the more message driven approach in Axis2 to
> have richer schema support for type declarations in WSDL definitions.
> Unless anyone knows of a really good existing lightweight Java model
> for schema (I've looked but no luck) that can be glued into WSDL4J's
> Definition model we're going to write one - the purpose being to
> inspect a WSDL file and, for a given operation, provide enough
> information in a friendly and easy to digest form for a dynamic
> invoker to build a compliant request document / parse a response. Note
> that this is _not_ a databinding layer, just type metadata. Actual
> databinding could obviously be driven off it though.
>
> 1) Does this exist?
> 2) Would anyone else use it?
> 3) We're happy to contribute it to Axis2, to any other project or to
> manage it ourselves, any preferences?
>
> Cheers,
>
> Tom
--
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com
Re: [Axis2] Schema parsing
Posted by Tom Oinn <tm...@ebi.ac.uk>.
Davanum Srinivas wrote:
> 1) Not that i know of
> 2) Absolutely
> 3) Axis2 please :)
Those were the answers I was hoping for, I'll start playing around and
see what I can get going. Current plan is to hack a prototype up as part
of Taverna's cvs / project module and get comments once I've something
working, sound reasonable?
Tom
Re: [Axis2] Schema parsing
Posted by Davanum Srinivas <da...@gmail.com>.
1) Not that i know of
2) Absolutely
3) Axis2 please :)
-- dims
On 11/8/05, Tom Oinn <tm...@ebi.ac.uk> wrote:
> Hi all,
>
> We're planning to use Axis2 in Taverna to construct SOAP requests,
> probably not using any form of data binding as we have our own and just
> using the send / receive SOAP body functionality.
>
> This means we have to be able to inspect arbitrary WSDL documents and
> determine the input schema in such a way that we can present appropriate
> 'input' and 'output' ports on our workflow components - this is slightly
> non trivial as we can attempt to split up sequence elements on input
> documents into different inputs and suchlike.
>
> Until recently we were using the WSIF library to present a slightly
> friendlier interface on the schema support in WSDL4J but changes in the
> latter have broken this for the time being.
>
> It occurs to me that our requirement is probably not unique, and that it
> might be useful for the more message driven approach in Axis2 to have
> richer schema support for type declarations in WSDL definitions. Unless
> anyone knows of a really good existing lightweight Java model for schema
> (I've looked but no luck) that can be glued into WSDL4J's Definition
> model we're going to write one - the purpose being to inspect a WSDL
> file and, for a given operation, provide enough information in a
> friendly and easy to digest form for a dynamic invoker to build a
> compliant request document / parse a response. Note that this is _not_ a
> databinding layer, just type metadata. Actual databinding could
> obviously be driven off it though.
>
> 1) Does this exist?
> 2) Would anyone else use it?
> 3) We're happy to contribute it to Axis2, to any other project or to
> manage it ourselves, any preferences?
>
> Cheers,
>
> Tom
>
--
Davanum Srinivas : http://wso2.com/blogs/