How to make Web service use TCP transport with WSIT: "Policies solution"
By oleksiys on Jan 05, 2007
Before starting I would like to mention that for now the only app/web server that is supporting TCP transport (SOAP/TCP) provided by WSIT is Glassfish V2. But also Tomcat support is planned to be implemented.
Ok, as I said in prev. blog, Glassfish has the SOAP/TCP protocol listener represented as a lifecycle module, which should be enabled by default. But it's possible to check its status using admin tools provided by Glassfish (Web or console). And make sure the lifecycle module with name "WSTCPConnectorLCModule" is enabled. If yes - it means that the listener is initialized and waits on TCP port for SOAP/TCP requests. And each Web service that is supposed to be SOAP/TCP enabled should register itself on SOAP/TCP listener (lifecycle module).
Next question that arises is "how to deploy web service to Glassfish and make it reachable via SOAP/TCP?".
- JavaEE 5 or JSR109 WS deployment.
Actually all Web services deployed to Glassfish using this deployment method become TCP transport enabled. They are automatically registered on SOAP/TCP listener and ready to process. But the question is - How to say to WS client, that the service supports TCP transport? WSIT Policies is one possible way. In Web service's WSDL file (for fromwsdl case) or wsit-\*.xml file (for fromjava case) to standard web service <binding> section (in most cases its HTTP <binding> section) should be added following policy:
<soaptcp:OptimizedTCPTransport xmlns:soaptcp="http://java.sun.com/xml/ns/wsit/2006/09/policy/soaptcp/service" enabled="true"/>
After client retrieves service's WSDL it will know, that in addition to the declared binding's transport, the web service also supports TCP transport.
\*One known issue with JavaEE 5 deployment of WS is: if WS is being deployed to a Web container - then it is required for this WS to have the descriptor web.xml, where it will be specified to load on startup. In this case the SOAP/TCP listener will get to know about this web service.
- Servlet deployment.
For this deployment type, things are not much different. In this case one more servlet context listener should be added to web service's (actually web appliction's) web.xml file:
And the servlet should be set to load on startup. Otherwise the SOAP/TCP listener doesn't know about it before it starts . Then policies should be specified in same manner as for JaveEE 5 deployment.
Next is "How to make client to choose SOAP/TCP as transport to work with web service?"
Again policies solve that. The WS client can pick up policies from the client's policy configuration file wsit-client.xml. Following policy should be added to <binding> section of WS description:
This policy says to the client that it should choose optimal transport from all transports supported by web service. For example if a web service declares (using WSDL) that it supports just HTTP protocol - then a client will choose HTTP to work, but if in a WSDL file there is the policy declaration that SOAP/TCP is also supported by a web service - then a client will choose SOAP/TCP as the transport. Client makes this decision at runtime, that's why if transport policies will be changed on server side, it's not necessary to recompile client.
In this case how will the client know the address for WS SOAP/TCP endpoint, as it is nowhere specified?
A client will use the same address and port as it is using for the HTTP endpoint, thanks to new feature, implemented by Jeanfrancois , Glassfish "port unification". A SOAP/TCP request that will be sent to same port used for HTTP will be filtered out and passed to SOAP/TCP listener.