2 Replies Latest reply on Jul 18, 2005 6:08 AM by Thomas Diesler

    Schema Model to be used WSDL Types

    Anil Saldanha Master

      I just want to use this forum thread as a means to convey to the web services team as to what the schema model will be, that will be plugged into WSDLTypes.

      The Xerces Schema API works on a flat model with no hierarchies. It has a single XSModel that is built on targetNamespace. Inside this XSModel, it has something called XSNamespaceItems that are full fledged schemas representing the various namespaces possible. Each of these namespaceitems contain types, elements, attributes pertaining to the namespace the nsi is built for. Lets have a pictorial attempt at explaining this:

       XSModel (targetNS)
       |
       contains
       |
       |
       ----------------------------------------------
       | | |
       XSNamespaceItem xsnsi xsnsi
       (ns1) (ns2) (ns3)
       --------------- ------------- -------------
       | | | |
       types attrs types attrs
      


      Explanation continued below:

        • 1. Re: Schema Model to be used WSDL Types
          Anil Saldanha Master

          Now that the schema model is described. Let me give a background into what our approach at creating the schema model is for the two tasks: Java -> wsdl and wsdl -> Java.

          WSDLToJava is an easier process. Use WSDL4J to obtain the WSDL model. It treats schema definitions as an extensibility elements.

          While parsing the wsdl, we move the schema definitions to temp files and then use XMLSchemaLoader from Xerces schema implementation to parse the various schema definitions. (An issue I have noticed is that the XMLSchemaLoader accepts one schema definition block in a single file. So if there are multiple schema definitions, they should all be moved to different files. Ahh...) By parsing, we have built a single XSModel that represents the target namespace. This XSModel will be plugged into WSDLTypes.

          Now comes the tricky part, JavaToWSDL was tough because we cannot use the Xerces implementation of the Xerces Schema API because the Xerces team advised us not to use their implementation to create schemas, as the implementation is subject to change. So we were left with no choice but to implement our version of the Xerces Schema API.
          When we are converting Java types to a wsdl, we know the targetnamespace. We create a XSModel with the targetnamespace and all schema types that are generated by the JavaToXSD subsystem are added to this XSModel. Now the XSModel basically looks at the namespace of the type that is being added and then adds it to the namespaceitem that represents the namespace of the type being added.

          Positives:
          - One XSModel that is smart enough to manage the schema model.
          - Flat model. All we have is namespace items which deal with their types.

          Negative:
          Not a lot of information kept in the schema model to serialize it back to schema files.

          Workaround:
          JBossXSModel (JBoss implementation of Xerces Schema API) has additional information stored, that will allow us to serialize the schema model back to schema files.

          • 2. Re: Schema Model to be used WSDL Types
            Thomas Diesler Master

            So what is the correct modeling of schema contained/referenced from wsdl/types?

            A) Map<String, List<XSModel>> schemaModels;
            
            B) Map<String, XSModel> schemaModels;
            
            C) XSModel schemaModel;
            


            Option (A) is what we currently have because it is a superset of (B) and (C)

            Your post suggests if I understand correctly that (B) is correct because each XSModel is associate with a single targetNS and a wsdl may contain/reference multiple schemas with different targetNSs

            Option (C) seems incorrect because of the above.

            In case (B) is correct, the WSDL11Reader should make sure that schemaModels is initialized correctly. Taking care of multiple contained/referenced schemas which in turn may contain/reference other schemas.

            An additional problem is the registry of schema temp file locations that are consumed by jbossxb. This registry is populated at parse time, which does not play well with dynamic schema generation with unconfigured clients.

            WSDLTypes should be refactored such that it contains the correct schema model that can be modified dynamically. The schema location registry should be removed from WSDLTypes - it should be a seperate entity that is controlled by WS endpoints/clients respectively.

            This is aiming towards

            D) Map<String, JBossXSModel> schemaModels;