[Geoserver-devel] XML binding with JiBX, WMS 1.3.0 example

GeoServer GeoServer Developer
1

I've been working on a subproject of JiBX which takes an XML Schema and produces Java source files and a JiBX binding definition file. The first beta of xsd2jibx is nearing release and the examples I've been preparing are ones I think this project and Geotools project can benefit from. The code that I checked in today supports the WMS 1.3.0 capabilities schema and example at http://schemas.opengis.net/wms/1.3.0/. I had JiBX unmarshal the example capabilites.xml and out the attached xml. They data *should* be identical.

JiBX takes a different approach than the other data binding apps like JAXB. It allows you to map your existing objects to an XML structure, similar to how Hibernate allows you to map your objects to a relational database. Unlike Hibernate, it doesn't use reflection. It compiles the bindings into the bytecode of the class files. It also uses XMLPull rather than SAX. It is fast and flexible and is starting to pick up a lot of interest. I think it can be used to improve performance of geoserver and make the XML handling easier to maintain.

Essentially, xsd2jibx will produce reference code and a refering binding definition needed to support an XML structure that conforms to an XML Schema. To add support to your code, you can then adjust the binding definition as necessary or add your additional properties and methods to the produced source files. Somehow, they must be synced, but this is much easier IMHO than dealing with SAX or DOM.

I'm now working on the SLD 0.7.2 example, since that is what I believe geotools currently supports. If there are other XSD's that are in high demand let me know. I would however, not like to tackle the most diffiicult ones to begin with (I've heard stories of GML 3). I could really use some more test XM's from both WMS 1.3.0 and SLD 0.7.2. If any of you are interested in checking out the CVS code and trying out the WMS example, let me know and I'll provide instructions (I need more testers. :] ).

Thanks,
Cameron

(attachments)

wms_capabilities1.xml (9.25 KB)

2

JiBX takes a different approach than the other data binding apps like
JAXB. It allows you to map your existing objects to an XML
structure,
similar to how Hibernate allows you to map your objects to a
relational
database. Unlike Hibernate, it doesn't use reflection. It compiles
the
bindings into the bytecode of the class files. It also uses XMLPull
rather than SAX. It is fast and flexible and is starting to pick up
a
lot of interest. I think it can be used to improve performance of
geoserver and make the XML handling easier to maintain.

Hmmm... I wish I had more time so I could more easily justify testing
this out, as it looks promising. We're certainly not up to wms 1.3
yet, so I don't have a huge motivation to test that out. And we don't
yet return sld to users, and even if we did it'd be easier to just roll
in geotools stuff. Sorry, it's just much easier to work with what
we've already got. After I get 1.2.0 out I will probably play with it
a bit. You also could do WFS 1.0.0, as it's an easy schema you can
hit. I doubt JiBX will have performance gains for us though, since we
use SAX to produce our Capabilities instance documents, which I think
it about the fastest way to handle it. Yes, it's more complicated, and
if I were doing it again and JiBX were more mature it probably would be
the solution to use. But if you want a concrete test to do you could
attempt to rewrite WfsCapabilitiesResponseHandler and
WFSCapabilitiesResponse with JiBX - I do imagine you'll be able to
simplify the code greatly. If you do performance and scalability
testing I'd consider using your code instead of our current. But you'd
have to pass the script that David wrote that sends like 1000 GetCaps
requests to GeoServer all at once. Hey David, maybe you could include
that in the source somewhere? Would be a nice little test for people
to run.

I'm now working on the SLD 0.7.2 example, since that is what I
believe
geotools currently supports. If there are other XSD's that are in
high demand let me know.

Like I said, the wfs capabilities document -
http://schemas.opengis.net/wfs/1.0.0/WFS-capabilities.xsd
You also might try the filter document, though that's one that we
already have both SAX and DOM to and from geotools already.

I would however, not like to tackle the most
diffiicult ones to begin with (I've heard stories of GML 3). I could
really use some more test XM's from both WMS 1.3.0 and SLD 0.7.2.

GML is definitely where this has the highest potential. It could
potentially solve the really nasty problem of parsing the xsd's of the
gml definitions. The twist with gml is that with it you define other
xsd documents, it just gives you the basis to write your own schemas
that have geometries. So all Features in a WFS essentially have their
own schema, which is obtained with a DescribeFeatureType response.
Instead of refering to a static schema document the DescribeFeatureType
response is generated on the fly. We do this from a geotools
FeatureType. So basically your jibx code could prove incredibly useful
in parsing GML Schemas into GeoTools featureTypes, because they could
do the parse directly. The FeatureType would then be used to do the
actual parsing of the GML. So basically if you can figure out how to
turn any gml xsd file into a geotools FeatureType then geotools and
geoserver developers will love you. It sounds like it should be
possible and not too difficult with JiBX, combined with your xsd2jibx,
and a bit of new code, to go xsd2FeatureType

Again, sorry I don't have the time to test things out for you, as I
would love to help you out, as this could prove extremely useful. But
good luck with it all, and I encourage others on this list to help out.

best regards,

Chris

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

3

I would be interested in doing performance and scalability testing. Please send me the scripts. When Dennis wrote an article on performance with Java data binding , dated 1/1/2003, the perfomance looked quite good in terms of both quickness and memory usage. http://www-106.ibm.com/developerworks/library/x-databdopt2/
http://jibx.sourceforge.net/performance.html

JiBX 1.0 final will probably be released early summer. The beta releases have been pretty stable. My xsd2jibx utility definitely isn't as stable, but you only need it have it work correctly once. It produces a reference set of Java objects and a binding definition. Here is how I used it with the WFS schema as example after a couple of minor tweaks to the schema: xsd2jibx wfs\1.0.0\WFS-capabilities.xsd

This produces the attached binding definition document wfs.jibx.xml and the corresponding Java bean source files. To get it to work with geoserver, I would need to change the mappings to use the corresponding objects in Geoserver. The only JiBX related code you need to create is the marshal() and unmarshal() methods or whatever you want to call them. Attached is a the test sample for WFS. I saved the capabilities document returned from http://localhost:8080/geoserver/wfs?request=GetCapabilities as geoserver-wfs.xml (attached). I ran it through the test:
java wfs.CapabilitiesTest geoserver-wfs.xml
And the output is attached as geoserver-wfs2.xml.

It looks like it fully supports the WFS schema. I'll ask James and the Geotools guys about the SLD versions.

Cameron

You also could do WFS 1.0.0, as it's an easy schema you can
hit. I doubt JiBX will have performance gains for us though, since we
use SAX to produce our Capabilities instance documents, which I think
it about the fastest way to handle it. Yes, it's more complicated, and
if I were doing it again and JiBX were more mature it probably would be
the solution to use. But if you want a concrete test to do you could
attempt to rewrite WfsCapabilitiesResponseHandler and
WFSCapabilitiesResponse with JiBX - I do imagine you'll be able to
simplify the code greatly. If you do performance and scalability
testing I'd consider using your code instead of our current. But you'd
have to pass the script that David wrote that sends like 1000 GetCaps
requests to GeoServer all at once. Hey David, maybe you could include
that in the source somewhere? Would be a nice little test for people
to run.

(attachments)

wfs.jibx.xml (16.5 KB)
geoserver-wfs2.xml (4.85 KB)
geoserver-wfs.xml (4.62 KB)
CapabilitiesTest.java (1.75 KB)

4

I would be interested in doing performance and scalability testing.
Please send me the scripts.

David, could you email that little scalability script you wrote to test
GetCaps?

JiBX 1.0 final will probably be released early summer. The beta
releases have been pretty stable. My xsd2jibx utility definitely
isn't as stable, but you only need it have it work correctly once. It
produces a reference set of Java objects and a binding definition.

I guess the xsd2jibx utility could be used for a basis of
xsd2FeatureType using JiBX perhaps...that would require some good
stability from it though.

Here is how I used it with the WFS schema as example after a couple
of
minor tweaks to the schema:
xsd2jibx wfs\1.0.0\WFS-capabilities.xsd

This produces the attached binding definition document wfs.jibx.xml
and
the corresponding Java bean source files. To get it to work with
geoserver, I would need to change the mappings to use the
corresponding
objects in Geoserver.

Ok, so if you want to code this up the classes that you'll replace are
WfsCapabilitiesResponseHandler and WFSCapabilitiesResponse. The object
that contains _most_ of the definitions you need is
org.vfny.geoserver.global.Service, you'll be using the WFS subclass.
Be sure to look at WfsCapabilitiesResponseHanlder, as there are a few
fields we construct from the Request object, as it has the information
on what url should be returned for the requests. And how big is the
JiBX jar? Please know that even if you do all this work (though it
shouldn't be all that much), I will still be hesitant to roll it in
right away, if at all, as JiBX will be an extra jar and thus a bigger
download for something that we can already do. Unless it's far faster,
but our GetCaps response is already pretty fast, or it offers
capabilities we don't have (other than potential code simplification).
Though if you do xsd2FeatureType and get some GML Schema parsing with
JiBX then I'd probably be fine to roll both in. But even if you have a
slightly forked version of GeoServer it sounds like it could be a good
example of JiBX's capabilities.

best regards,

Chris

The only JiBX related code you need to create

is
the marshal() and unmarshal() methods or whatever you want to call
them. Attached is a the test sample for WFS. I saved the
capabilities
document returned from
http://localhost:8080/geoserver/wfs?request=GetCapabilities as
geoserver-wfs.xml (attached). I ran it through the test:
java wfs.CapabilitiesTest geoserver-wfs.xml
And the output is attached as geoserver-wfs2.xml.

It looks like it fully supports the WFS schema. I'll ask James and
the
Geotools guys about the SLD versions.

Cameron

>You also could do WFS 1.0.0, as it's an easy schema you can
>hit. I doubt JiBX will have performance gains for us though, since
we
>use SAX to produce our Capabilities instance documents, which I
think
>it about the fastest way to handle it. Yes, it's more complicated,
and
>if I were doing it again and JiBX were more mature it probably would
be
>the solution to use. But if you want a concrete test to do you
could
>attempt to rewrite WfsCapabilitiesResponseHandler and
>WFSCapabilitiesResponse with JiBX - I do imagine you'll be able to
>simplify the code greatly. If you do performance and scalability
>testing I'd consider using your code instead of our current. But
you'd
>have to pass the script that David wrote that sends like 1000
GetCaps
>requests to GeoServer all at once. Hey David, maybe you could
include
>that in the source somewhere? Would be a nice little test for
people
>to run.
>
>

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/