I'm trying to get to grips with writing a transport for the RI. Seems
simple enough in a standalone context but I am a bit lost when deploying
to a servlet.
My requirements are
1) deploy as servlet (war with sun-jaxws.xml)
2) service exposed over non-http transport(s) only
3) WSDL is exposed over ?wsdl as normal and has correct non-http
endpoint in it's port
Say I want to expose a service over JMS (not necessarily using the
jms-jaxws-transport implementation in its current form). I would like to
deploy this as a war as normal with a sun-jaxws.jar and use the
"url-pattern" to specify the transport url ("x-jms:...") - or some other
attribute (transport-url for example).
Currently this is not possible at all AFAIK. Is there any way to achieve
this without having to duplicate the whole servlet code with changes?
One approach that may get me part of the way would be to extend the
WSServletContextListener class (ah, if only it were not final) so that
after it returns from setting up the endpoints for HTTP (specifically
ServletAdapter) I could then parse the sun-jaxws.xml file again looking
for a new attribute ("transport-url") on <endpoint> elements and then
setup new transport listeners based on these endpoints (is there a
schema for sun-jaxws.xml that I would then be violating? The code
doesn't appear to validate there are no extra attributes).
This still has the problem that ?wsdl would return the http specific
WSDL, not the extra transport (I think). Also, the request would also be
accepted over HTTP instead of just over the extra transport.
Am I barking up the wrong tree here? Do I need to start from scratch and
write my own application loading code to replace the RI code (something
I would be reluctant to pursue for maintenance reasons) when deploying
as a war?
Once there are more transports being written this would seem to me to be
a "normal" type of deployment (service not published over http but ?wsdl
still works and returns non-http endpoint in port).
FWIW, the way our application loading works is to look at the WSDL and
see the transports to be supported (from the URL schemes). The call
chain (tubes equivalent) is then created and linked from each endpoint
instance created for each endpoint definition in the wsdl. The endpoints
over which messages can arrive have no relation to how the app was
deployed (other than integrating with the servlet endpoint processing
when exposed over http). The wsdl is available over http in all cases
with all defined endpoints in it.
Or is this already possible and I just can't see it?
Cheers
Pete