Announcement Announcement Module
Collapse
No announcement yet.
XML Schema Centralization and Management Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • XML Schema Centralization and Management

    I'm starting a thread on the SOA design pattern "Schema Centralization" because i'm curious how others are going about it within their organization, or at all for that matter.

    Here's my situation, I'm hand coding a wsdl and will eventually use a SimpleWsdl11Definition bean to expose it for consumers. Truely, this is contract-first development. Currently, I'm working on the <wsdl:types> section to define the messages for each of the operations. The messages are composed of simple types and complex types, the later being defined as part of the enterprise data architecture or a canonical data model. So for instance we have this wsdl snippet:

    Code:
    <wsdl:types>
    	<xsd:schema targetNamespace="http://schemas.shawmut.com/contract/project-v1">
    		<xsd:import namespace="http://schemas.shawmut.com/type/project/project-v1" schemaLocation="/ws/services/xsd-project-v1.xsd"/>
    		<xsd:element name="findProjectByProjectNumber">
    			<xsd:complexType>
    				<xsd:sequence>
    					<xsd:element name="projectNumber" type="xsd:string" />
    				</xsd:sequence>
    			</xsd:complexType>
    		</xsd:element>
    		<xsd:element name="findProjectByProjectNumberResponse">
    			<xsd:complexType>
    				<xsd:sequence>
    					<xsd:element name="project" type="project:ProjectType"/>
    				</xsd:sequence>
    			</xsd:complexType>
    		</xsd:element>
    	</xsd:schema>
    </wsdl:types>
    So far so good, no problem here...Until I need to supply a schemaLocation for the <import> that points to xsd file that defines the ProjectType complex type. I have to make sure that my IDE can resolve the path to the XSDs as well when the WSDL is in production, where consumers can resolve the location as well. SoapUI will uncover these issues for you right away for you. The only way i know how to satisfy these requirements is to use a complete uri path to the XSD like http://shemas.mycompany.com/types/pr...project-v1.xsd. This is fine too, but it seems to me if I go down this road, i will have a lot of extra work to maintain those xsd files and i'm hesitant to start something that will be cumbersome to maintain and have to train other developers to play nice with.

    So, how do i properly manage a centralized schema to satisfy the above requirements?

    First and foremost our IT organization will need to have a process and standards in place to successfully maintain a centralized schema. But, what i'm most curious about is the development methodology for maintaining the centralized schema. Some of my initial questions are:

    1. Do you keep your xsd files in version control? (I'm sure the answer is yes.)
    2. Do you have a centralized location for hosting xsd files (ie. http://schemas.yourcompany.com/types/....)
    3. Are you automating the process of updating the schemas from your vcs to your schema host?
    3. Are you unit testing your xsd files? If so, any tools in particular you are using?
    4. Is all of this development activity overkill?


    Any thoughts or advice you can share with the community?


    -Russ
Working...
X