#161 [ART] Refactore proposal XIS package

[Alexander Henket]

The XIS package currently is set up with everything that needs to be called under the same path. This gives the controller a harder time to find out what's been requested.

The controller however needs to distinguish between retrieval of resources/data requested by the xforms, the services RetrieveMessage / ViewTestresult and finally serving the configured SOAP services. Currently the routing is quite weak as it is hard to find out what's been requested. This is all due to the fact that the controller does not know what SOAP services are being offered (Ping, 02/Ping, ...) and cannot inspect request get-data() for SOAP-ENV:Envelope as you can apparently do request:get-data()/SOAP-ENV:Envelope only once.

Here is a proposal to improve:

if (/xis/services/RetrieveMessage)
then (forward to /xis/services/modules/RetrieveMessage.xquery)

if (/xis/services/ViewTestResult)
then (forward to /xis/services/modules/retrieve-testresult.xquery)

if (/xis/services/soap/...)
then (forward to /xis/services/modules/SOAP-response.xquery)

if (/xis/services/soap/....?wsdl)
then (forward to /xis/services/modules/WSDL-response.xquery)

else (
send to requested resource
)

This stacks up nicely with how the decor/service package works, but requires that soap clients (testers/qualification applicants) use a different (deeper) path. Their change is calling:

http://art-decor.org/xis/services/soap/Ping
instead of
http://art-decor.org/xis/Ping

[Alexander Henket]

Any comments as one of the primary users of this feature?

[Alexander Henket]

I don't see any compelling reasons anymore to start messing with this. Since I created this ticket, I'm withdrawing it.