[seek-dev] Wednesday call.

Kevin Ruland kruland at ku.edu
Tue Sep 20 10:53:46 PDT 2005


Hi all,

In order to reduce my babbling on tomorrows call, I typed up some
details for #1 on the agenda.

Matt Jones wrote:

>Sounds like most people can do it on Tuesday, so I will propose the 
>following time:
>
>                   Time: Tuesday, Sept 20 9am Pacific time
>                   Call#: 1-888-346-3950
>Participant Code: 39501
>You'll hear muzak until I join with the host code, so just be patient if 
>you're on hold at first.
>
>Let me know if that does NOT work for you.
>
>Tenative agenda:
>1) EcoGrid XSD changes + associated code refactoring
>2) Changes to require use of LSIDs
>3) Migration to GT4 or plain web services
>4) Agenda planning for October meeting
>     (http://seek.ecoinformatics.org/Wiki.jsp?page=AllHandsMeeting2005)
>
>Please suggest additional or revised agenda items.  Thanks.
>
>Matt
>  
>

                 Reorganization of generated types


Old layout had all generated types from wsdls and xsds in
org.ecoinformatics.ecogrid.  This directory also included some hand
written code.  Here's a list of src/org/ecoinformatics/ecogrid sorted
by source:

query.xsd
---------
org.ecoinformatics.ecogrid.ANDType           (modified from axis
generated source - see below)
org.ecoinformatics.ecogrid.ConditionType
org.ecoinformatics.ecogrid.LimitedXPathExpression
org.ecoinformatics.ecogrid.ORType                 (modified from axis
generated source - see below)
org.ecoinformatics.ecogrid.OperatorType
org.ecoinformatics.ecogrid.QueryType
org.ecoinformatics.ecogrid.QueryType_namespace

hand coded
----------
org.ecoinformatics.ecogrid.EcoGridConstant
org.ecoinformatics.ecogrid.EcoGridErrorCode
org.ecoinformatics.ecogrid.EcoGridFTPClient
org.ecoinformatics.ecogrid.EcoGridFTPTransfer
org.ecoinformatics.ecogrid.EcogridObjType
org.ecoinformatics.ecogrid.EcogridQueryParser
org.ecoinformatics.ecogrid.EcogridQueryTransformer
org.ecoinformatics.ecogrid.EcogridResultsetParser
org.ecoinformatics.ecogrid.EcogridResultsetTransformer
org.ecoinformatics.ecogrid.EcogridUtils
org.ecoinformatics.ecogrid.EcogridUtilsNamedNodeIterator
org.ecoinformatics.ecogrid.GridProxy

resultset.xsd
-----------
org.ecoinformatics.ecogrid.ResultsetType
org.ecoinformatics.ecogrid.ResultsetType_record
org.ecoinformatics.ecogrid.ResultsetType_record_returnField
org.ecoinformatics.ecogrid.ResultsetType_resultsetMetadata
org.ecoinformatics.ecogrid.ResultsetType_resultsetMetadata_namespace
org.ecoinformatics.ecogrid.ResultsetType_resultsetMetadata_recordStructure
org.ecoinformatics.ecogrid.ResultsetType_resultsetMetadata_recordStructure_returnField
org.ecoinformatics.ecogrid.ResultsetType_resultsetMetadata_system

>From wsdl
----------
org.ecoinformatics.ecogrid.stub.EcoGridQueryInterfaceLevelOnePortType
org.ecoinformatics.ecogrid.stub.Get
org.ecoinformatics.ecogrid.stub.GetResponseType
org.ecoinformatics.ecogrid.stub.bindings.EcoGridQueryLevelOneServieSOAPBindingStub
org.ecoinformatics.ecogrid.stub.service.EcoGridQueryLevelOneService
org.ecoinformatics.ecogrid.stub.service.EcoGridQueryLevelOneServiceGridLocator
org.ecoinformatics.ecogrid.stub.service.EcoGridQueryLevelOneServiceLocator

The situation becomes even more confusing when Put, Reg interfaces are
generated because their stubs (bindings, services) are placed in
org.ecoinformatics.ecogrid.stub (.bindings, .service, resp.)

In order to simplify the build process and improve maintainability,
these classes should be repackaged by service & schema as follows:

query.xsd
---------
org.ecoinformatics.ecogrid.queryservice.query.ANDType
org.ecoinformatics.ecogrid.queryservice.query.ConditionType
org.ecoinformatics.ecogrid.queryservice.query.LimitedXPathExpression
org.ecoinformatics.ecogrid.queryservice.query.ORType
org.ecoinformatics.ecogrid.queryservice.query.OperatorType
org.ecoinformatics.ecogrid.queryservice.query.QueryType
org.ecoinformatics.ecogrid.queryservice.query.QueryType_namespace

hand coded
----------
org.ecoinformatics.ecogrid.queryservice.EcogridFactoryQueryClient
org.ecoinformatics.ecogrid.queryservice.util.EcogridQueryParser
org.ecoinformatics.ecogrid.queryservice.util.EcogridQueryTransformer
org.ecoinformatics.ecogrid.queryservice.util.EcogridResultsetParser
org.ecoinformatics.ecogrid.queryservice.util.EcogridResultsetTransformer

resultset.xsd
-----------
org.ecoinformatics.ecogrid.queryservice.resultset.ResultsetType
org.ecoinformatics.ecogrid.queryservice.resultset.ResultsetType_record
org.ecoinformatics.ecogrid.queryservice.resultset.ResultsetType_record_returnField
org.ecoinformatics.ecogrid.queryservice.resultset.ResultsetType_resultsetMetadata
org.ecoinformatics.ecogrid.queryservice.resultset.ResultsetType_resultsetMetadata_namespace
org.ecoinformatics.ecogrid.queryservice.resultset.ResultsetType_resultsetMetadata_recordStructure
org.ecoinformatics.ecogrid.queryservice.resultset.ResultsetType_resultsetMetadata_recordStructure_returnField
org.ecoinformatics.ecogrid.queryservice.resultset.ResultsetType_resultsetMetadata_system

>From wsdl
----------
org.ecoinformatics.ecogrid.queryservice.stub.EcoGridQueryInterfaceLevelOnePortType
org.ecoinformatics.ecogrid.queryservice.stub.EcoGridQueryLevelOneService
org.ecoinformatics.ecogrid.queryservice.stub.EcoGridQueryLevelOneServiceGridLocator
org.ecoinformatics.ecogrid.queryservice.stub.EcoGridQueryLevelOneServiceLocator
org.ecoinformatics.ecogrid.queryservice.stub.EcoGridQueryLevelOneServieSOAPBindingStub
org.ecoinformatics.ecogrid.queryservice.stub.Get

Similar packages would be used for the other services:

org.ecoinformatics.ecogrid.putservice
org.ecoinformatics.ecogrid.reqservice

I don't really know how QueryLevelTwo should be packaged.  My first
impression is it should also go into
org.ecooinformatics.ecogrid.queryservice.


                 Refactoring of EcogridUtils

EcogridUtils has become the catch all for static methods.  The methods
in this class should be seperated into different support classes and
organized functionally.

The methods which are factory methods for ResultsetType should be
moved into a new class o.e.e.queryservice.util.EcogridResultsetFactory.

createSystem()
createNameSpace()
createRecordStructReturnField()
createRecordStruct()
createMetadata()
createRecordReturnField()

These methods should be moved into
o.e.e.queryservice.util.EcogridQueryParser

readEcogridXMLQuery()

Many other methods in EcogridUtils should be placed in more descriptive
classes.  Also some care should be taken to reduce the code bloat in the
client/stub jar.  Currently EcogridUtils is placed in the stub jar.  We
should agressively reduce this dependency.


                 Fixing QueryType handling

The current query.xsd defines some types using repeated choice fields.
The ANDType is defined like this:

        <xs:choice maxOccurs="unbounded">
            <xs:element name="AND" type="ANDType"/>
            <xs:element name="OR" type="ORType"/>
            <xs:element name="condition" type="ConditionType"/>
        </xs:choice>

Although this is a syntatically correct schema and provides the proper
semantics for AND, the Apache Axis code generated does not properly
handle repitition on choice and sequence elements.  The previous
developers attempted to correct this by hand modifying the generated
classed and checking them into cvs.

There are two problems with this approach.  First, having hand
modified classes increases maintenence costs because if the schema is
ever modified, appropriate changes needs to be made.  Second, the
modified code is incorrect and does not properly parse every instance
of the schema, ie, the server does not fully support the published
schema.

We have two options either modify the schema so Axis can properly
parse it and it still provides support for all logical operations.
Or, develop better code to handle the ANDType and ORType schema types
and use Axis custom bindings mechanism to utilize them.

The approach which is most maintainable is to modify the schema to
work around the Axis bug.  ANDType then becomes this:

        <xs:sequence>
            <xs:element name="AND" type="ANDType" minOccurs="0"
maxOccurs="unbounded"/>
            <xs:element name="OR" type="ORType minOccurs="0"
maxOccurs="unbounded""/>
            <xs:element name="condition" type="ConditionType
minOccurs="0" maxOccurs="unbounded""/>
        </xs:sequence>

ORType is similar.  This definition requires the <AND></AND> clause to
be structured so that all nested <AND> clauses come first, then all
nested <OR> clauses then the nested <condition> clauses.  This is not
as expressive as the previous definition which had no ordering
requirements, but because of associativity provides a logically
equivalent syntax.

With this modification in place, no types generated from query.xsd
needs to be placed in the repository and maintained seperately.  In
addition, the build process can be simplified by generating these
types at build time.


                 Changing deployment

Simplify the deployment by removing long directory names from the
schema/ directory, I've changed the deployment descriptor
(EcogridImplWithoutSecurity.wsdd).  The old schema location was:

schema/org.ecoinformatics.ecogrid/EcogridQueryInterfaceLevelOne/EcogridQueryInterfaceLevelOne_service.wsdl

I've removed the package-named directory to make it:

schema/EcogridQueryInterfaceLevelOne/EcogridQueryInterfaceLevelOne_service.wsdl



More information about the Seek-dev mailing list