This content has been marked as final. Show 2 replies
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.
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,
<xsd:import namespace="http://soa.o2.co.uk/hellodata_1" schemaLocation="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.