2 Replies Latest reply on Oct 28, 2009 12:24 PM by 698709

    Handling common XML schema shared across services

      Hi all,

      We are using ALSB 3.0. We have a problem, it would be of great help if you could point me in the right direction.

      We are building several web services (proxy services in ALSB) that all use a common 'core' data. We have project structure where each web service is a separate ALSB project. This would allow us to version control, release, deploy individual services without any problem. Now, we don't want to duplicate 'core' data in each of these projects (we want a single copy of this). We could create a separate common project and keep the 'core' data in there. One problem we see with this is in XSD where we refer 'core' data, we need to use relative path like '../commonproject/xsd/core.xsd'; this will create a problem when we distribute the XSD to our consumers. They will not have directory structure like ours and import might fail in their development environment.

      I am sure this is a common scenario and you people might have come across a neat solution for this. I would be very happy if you could share your experiences.

        • 1. Re: Handling common XML schema shared across services
          Your assertion is wrong. If you distribute ALSA/OSB projects, you distribute EVERYTHING. Basically you distribute your configuration setup, because you want to export security settings and other requirements for your services to work too. So relateively within that configuration project, everything will be the same. Actually, you can do "absolute" references like /project/xsd/myschema.xsd to do what you want (that's how we do it) and it works great.
          • 2. Re: Handling common XML schema shared across services
            We are not distributing ALSB projects. We are only distributing WSDL and XSDs to clients.

            One more thing "absolute" references, are you saying in WSDL and XSDs we will use absolute references to dependent artefacts? Wouldn't this cause problem for your clients to have the same structure when they try to generate stubs?

            To explain our scenario in detail with an example,

            we have service WSDL
            -> imports hellodata_1_0.xsd
            -> imports coredata_1_0.xsd

            Currently, we have all service WSDL and XSDs stored only in one ALSB project. So in the import statement, we don't have to give path of XSD. Example import statement is given below,

            hello_1_0.wsdl :-
                      <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
                           <xsd:import namespace="http://soa.o2.co.uk/hellodata_1" schemaLocation="hellodata_1_0.xsd"/>

            hellodata_1_0.xsd :-
            <xsd:import namespace="http://soa.o2.co.uk/coredata_1" schemaLocation="coredata_1_0.xsd"/>
            As you can see we don't use paths in 'schemaLocation' attribute. This works quite well because when we distribute WSDL and XSDs to clients, they are all zipped as they are in the folder and sent to them. Our clients don't have to manipulate the structure of WSDL and/or XSD to generate stubs. Everything works fine. But as we are adding more and more services, single project holding all WSDL and XSDs is becoming more complex.