[Xml-compile] Accessing schemaLocation attribute url values inside <include> elements

Morad IGMIR migmir at alliancemca.com
Fri Jul 16 14:20:21 GMT 2010


I'd like my project to become a stable application.
But I also want it not to be a pain in deployment.

I understand your point clearly.
I agree, dynamically loading some spec from some server has many hazards.

But I'm using my specs from my servers. A lot less hazard involved.
Worst case : soap server is down, wsdl file won't download.
Well that's ok, since the wsdl file would be useless without a working
service.
Hence on frontend websites using the services I can display a nice error.

But dealing with as musch as 30 wsdl/xsd files on 10 to 20 servers is just
terrible.
And much more error prone in my opinion.

Dealing with heavy sets of wsdl/xsd files is my conception of a big
environment

For instance, the inherent problem to using Document/Literal is that this :

			<soap:address
location="http://host.domain.tld/Action" />

...defines where the request goes.

Let's take a practical case here.

I setup a catalyst app using C:C:SOAP (which relies on XMC), i have a fairly
simple Service.wsdl file : 


<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://ws.alliancemca.com/"
targetNamespace="http://mynamespace.lol/">
	<wsdl:types>
		<xs:schema elementFormDefault="qualified"
targetNamespace="http://mynamespace.lol/">
			<xs:include
schemaLocation="http://host.domain.tld/file.xsd" />
			<xs:element name="LoginMsgIn" type="tns:login"/>
			<xs:element name="LoginMsgOut" type="tns:full_user"
/>
		</xs:schema>
	</wsdl:types>
	<wsdl:message name="LoginSoapIn">
		<wsdl:part name="login" element="tns:LoginMsgIn"/>
	</wsdl:message>
	<wsdl:message name="LoginSoapOut">
		<wsdl:part name="param" element="tns:LoginMsgOut"/>
	</wsdl:message>
	<wsdl:portType name="LoginPortType">
		<wsdl:operation name="Login">
			<wsdl:input message="tns:LoginSoapIn"/>
			<wsdl:output message="tns:LoginSoapOut"/>
		</wsdl:operation>
	</wsdl:portType>
	<wsdl:binding name="LoginBinding" type="tns:LoginPortType">
		<soap:binding
transport="http://schemas.xmlsoap.org/soap/http"/>
		<wsdl:operation name="Login">
			<soap:operation
soapAction="http://127.0.0.1:10000/ws/Login" style="document"/>
			<wsdl:input>
				<soap:body use="literal"/>
			</wsdl:input>
			<wsdl:output>
				<soap:body use="literal"/>
			</wsdl:output>
		</wsdl:operation>
	</wsdl:binding>
	<wsdl:service name="AuthService">
		<wsdl:port name="LoginPort" binding="tns:LoginBinding">
			<soap:address
location="http://127.0.0.1:10000/ws/Login" />
		</wsdl:port>
	</wsdl:service>
</wsdl:definitions>

This file is accessible through http://127.0.0.1:10000/static/service.wsdl

So this apps gives a fairly simple service. It has only one method. No
biggie.

But then I need to make it accessible to clients and proxy services on other
hosts.
I know, I'll just have apache reverse proxy to it from outside
But then clients can't connect, cause 

<soap:address location="http://127.0.0.1:10000/ws/Login" />

Says go to 127.0.0.1

Well now I have to have a copy of that wsdl file (!), that i'll name
Service_80.wsdl

Service_80.wsdl where everything but soap:address of that one method isn't
the same

<soap:address location="http://authservice.domain.tld/ws/Login" />

And have mod_rewrite rewrite calls to /static/service.wsdl to
/static/service_80.wsdl when needed.

BUT THEN I ALSO HAVE SSL REQUESTS !!
And that's another copy of the file. 
This time with :
<soap:address location="https://authservice.domain.tld/ws/Login" />

So now i have 

Service.wsdl
Service_80.wsdl
Service_443.wsdl

Really it's the URL's that mess up everything.
Considering this case is valid for all my services (and there are quite a
few)
I can't keep track of THAT many files
All my web apps and soap apps rely on this, and then some other soap apps
act as proxy of each other.


I can't just copy the right file according to how they call the service,
And expect things to turn out ok.
Plus it would complicate the developpment part so much.
That would end up in a major headache, don't you think ?

My environment is already huge, I have to deal with it, and meet deadlines
:s



-----Message d'origine-----
De : Mark Overmeer [mailto:mark at overmeer.net] 
Envoyé : vendredi 16 juillet 2010 14:52
À : Morad IGMIR
Cc : xml-compile at lists.scsys.co.uk
Objet : Re: [Xml-compile] Accessing schemaLocation attribute url values
inside <include> elements

* Morad IGMIR (migmir at alliancemca.com) [100716 12:40]:
> Using automatic internet fetching makes file distribution easy.
> Only one set of wsdl/xsd per service, accessible through one url each.
> It considerably lessened my margin of error

When you want to run a stable application, you do not want it to
depend from external factors. Dynamically loading some spec from
some remote server has many, many hazards.

SOAP spevs suggest you to download the WSDL at the start of your
connection, via <url>?WSDL. When the server upgrades it WSDL, any client
may tumble over. Before upgrade, clients should be able to run regression
tests... upgrades are dangerous and difficult! So: bad idea to change
the WSDL via this mechanism!

If we do not change de WSDL because it is dangerous, why not declare it
constant. Keep it with the software which uses it. My long development
experience taught me: you must make your environment as small as possible
with minimal components and zillion of regression tests.
-- 
Regards,
               MarkOv

------------------------------------------------------------------------
       Mark Overmeer MSc                                MARKOV Solutions
       Mark at Overmeer.net                          solutions at overmeer.net
http://Mark.Overmeer.net                   http://solutions.overmeer.net




More information about the Xml-compile mailing list