replacement of REPLACE_WITH_ACTUAL_URL when using annotation

[will.tatam]

In the past we used the wstools to create our wsdl and then replaced REPLACE_WITH_ACTUAL_URL with http://REPLACE_WITH_ACTUAL_URL if the server we were going to deploy to was directly accessible.
For servers that were behind a firewall we replace with the actual url we wish to use for the <soap:address location=""/>

We are now using the @WebService annotation. For the directly accessible servers we can use the @WebContext(transportGuarantee="CONFIDENTIAL") but we still need a way to solve the second issue. I have tried setting the virtualHosts param but this appears to have no impact on the wsdl

ideas ?

[asoldano]

Does this http://jbossws.jboss.org/mediawiki/index.php?title=FAQ#How_does_rewriting_of_the_soap_address_in_WSDL_work.3F address your issue?

[will.tatam]

nope

The issue is not the hard coding on the client side

The client being used is asp.net and php

We could "hack" the

${jboss.bind.address}

To have the name of our load balancer rather than the ${jboss.bind.address} but that is a rather ugly hack

[will.tatam]

no further suggestions ? or still not really understanding our needs ?

[peterj]

or still not really understanding our needs ?

I agree with this statement. Look at your first post, and then at your second. In the second post you suddenly throw in a lot of information (php and .net clients, load balancer) that was completely missing from the first post. So the first question that comes to my mind is: what else are you not telling us? It is hard to help someone when they have not provided all of the information necessary to provide an answer.

Perhaps a complete example of what you are hoping to achieve and what you are seeing instead would help.

[will.tatam]

PeterJ:

If you re-read my first post, you will see that i already explained that some of our jboss servers are directly accessible and some are not.

This means that for the servers that are directly accessible, using the ${jboss.bind.address} is a reasonable guess when trying to construct the full url for the soap address.

For example

http://123.123.123.123:8080/myapp/mySoapService

or if @WebContext(transportGuarantee="CONFIDENTIAL") then jboss will guess

https://123.123.123.123:8443/myapp/mySoapService

Now, as I have already stated this is not applicable for all servers. If a jboss server is behind a firewall then the bind address might not be publicly accessible.

This leaves a bit of an issue, if you leave true then you would end up with an address like

https://192.168.1.123:8443/myapp/mySoapService

which is unless unless your clients have a VPN in place, in which case the firewall is redundant as you would be side-stepping the firewall by using the VPN tunnel to get behind it !!

The old way was use false. If this by itself then just breaks your service as your wsdl now just contains the litteral value REPLACE_WITH_ACTUAL_URL. To get round this, we had modified our build system so when building copies of our app that were destined for use on our servers that are not directly accessible, we used to replace the REPLACE_WITH_ACTUAL_URL with the correct address as compilation time. We are happy to continue with this model, but are unable to as we have yet to find a way to effect the construction of the soap address within the wsdl that is created at runtime

What client code is being used to consume a given web service is irrelevant as when consuming a soap webservice you need wsdl that defines a url for it to actually perform a given action, which if it it contains a private ip, as per RFC1918 is not going to be much use to you unless you are also inside the same address space. Also the fact that our "firewall" is infact a SSL off-loader is again irrelevant to the construction of the URL

I have found very little in the way of documentation for the virtualHosts option, but this is in effect what we want to define as it is the host part of the url we wish to override (we already use the context to set the filepath aspect of the url)

Can anyone spread any further light on virtualHosts and confirm (or deny) if JBoss AS 4.2.3 supports it's usage ?

[peterj]

If I understand you correctly, I think that what you are saying is that when a client accesses the wsdl via https://192.168.1.123:8443/myapp/mySoapService?wsdl, that you want the wsdl returned to contain:

<soap:address location='https://192.168.1.123:8443/myapp/mySoapService'/>

but at this time it is returning:

<soap:address location='https://123.123.123.123:8443/myapp/mySoapService'/>

Note I am guessing that 123.123.123.123 is the internally-accessible IP address (that is, the hosts configured IP address) and that 192.168.1.123 is the IP address accessible from outside the firewall (that is, the IP address used by the firewall/router). Even after reading your post several times I am not exactly sure which is the physical IP address and which is the IP address accessible outside the firewall.

[will.tatam]

There are two totally different setups

123.123.123.123 is the dummy ip for a server that runs on a global ip address

192.168.1.123 is the private ip address of a server sitting behind the unspecified ip address of the firewall

If the client accesses a url of

https://456.456.456.456:8443/myapp/mySoapService?wsdl

they the wsdl should list the location as <soap:address location='https://456.456.456.456:8443/myapp/mySoapService'/>

ideally it should be HTTP 1.1 compliant, so rather than use a hard coded hostname or ${jboss.bind.address} it builds the url based on the url used for the wsdl request (which is just as simple as stripping the ?wsdl from the end)

[peterj]

There are two totally different setups

123.123.123.123 is the dummy ip for a server that runs on a global ip address

192.168.1.123 is the private ip address of a server sitting behind the unspecified ip address of the firewall

This is what I though was the case based on the IP addresses themselves (I recognize the subnet 129.168.1.xxx as being the subnet typically used by routers), but your text seemed to indicate the opposite.

If the client accesses a url of

https://456.456.456.456:8443/myapp/mySoapService?wsdl

they the wsdl should list the location as <soap:address location='https://456.456.456.456:8443/myapp/mySoapService'/>

You say that it "should list" that location. What location is it giving instead?

ideally it should be HTTP 1.1 compliant, so rather than use a hard coded hostname or ${jboss.bind.address} it builds the url based on the url used for the wsdl request (which is just as simple as stripping the ?wsdl from the end)

I do not know what you are saying here. What does HTTP 1.1 compliance have to do with this? What does the text "${jboss.bind.address}" have to do with this? When you say "it builds the url based on the url used for the wsdl request (which is just as simple as stripping the ?wsdl from the end)" are you saying that the soap location you are getting in the wsdl is:

<soap:address location='https://456.456.456.456:8443/myapp/mySoapService'/>

If so, then I am really confused because you earlier said "the wsdl should list the location as...".

So once again I am not sure what it is you are seeing and what it is that you are expecting. Please understand that I am not trying to give you a hard time, I am simply trying to understand what the problem is that you are having.

[will.tatam]

please read http://www.jboss.org/community/docs/DOC-12519 as this is basically the same problem as that of the creation of RMI stubs

This document details the use of these attributes to ensure that jndi returns the correct url for rmi invocations, just in the same way as the wsdl needs to return the correct url for soap invocations

-Djava.rmi.server.hostname=<external_host_name>
-Djava.rmi.server.useLocalHostname=true

In both cases, you are making a call to a given address, which is then forwarded on the the real jboss server, which is on a different address. When jboss is then creating anything that gives any kind or addressing details, by default it guesses it should use it's own address as it's unaware of the publicly accessible address.

The comment about HTTP 1.1 is that jboss should never be guessing the value for url in the first place. when the call for the WSDL is made, the HTTP connection provides the hostname as well as the filepath that was requested, this can then be used to build the response.

i,e

Current model

https://${webServiceHost}:${webServiceSecurePort}/${path.to.sevice}

where webServiceHost and webServiceSecurePort are hard coced values in WSServerConfig


Ideal Model

https://${http.request.hostname}:${http.request.port}/${path.to.sevice}

where the http.request values are populated based on the HTTP headers as part of the call for the WSDL


e.g

if I call https://myserver1.cust1,example.com:8443/myservice?wsl then the soap location should come back as https://myserver1.cust1,example.com:8443/myservice

if i have a dns record so that soap.example.com resolves to a http load balancer the if i call https://soap.example.com/myservice?wsdl then i get back a location of https://soap.example.com/myservice no matter whether it goes to myserver1.cust1,example.com, myserver2.cust1,example.com or even myserver9.cust4,example.com



As i say, this is the ideal. I would be happy with the old method whereby i hard-code the <soap:address location=''/> within the automatically created WSDL

[bschmoll1]

I've been recently struggling with the same issue. Apache operates as a front-end for our JBoss server which host several apps, one of which is a web service.

Look at the:
../deploy/jbossws.sar/jbossws.beans/META-INF/jboss-beans.xml

 <bean name="ServiceEndpointManager" class="org.jboss.ws.core.server.ServiceEndpointManager">

 <!--
 The WSDL, that is a required deployment artifact for an endpoint, has a <soap:address>
 element which points to the location of the endpoint. JBoss supports rewriting of that SOAP address.

 If the content of <soap:address> is a valid URL, JBossWS will not rewrite it unless 'alwaysModifySOAPAddress' is true.
 If the content of <soap:address> is not a valid URL, JBossWS will rewrite it using the attribute values given below.

 If next line (webServiceHost) is commented, JBossWS uses requesters protocolo, host and port when rewriting the <soap:address>.
 -->
<!-- <property name="webServiceHost">192.168.1.101</property> -->
 <property name="alwaysModifySOAPAddress">true</property>

 <!--
 Set these properties to explicitly define the ports that will be used for rewriting the SOAP address.
 Otherwise the ports will be identified by querying the list of installed connectors.
 If multiple connectors are found the port of the first connector is used.
 <property name="webServiceSecurePort">8443</property>
 <property name="webServicePort">8080</property>
 -->

The webServiceHost property should be commented out. I believe this is what your looking for.

[will.tatam]

what happens if you comment out the webServiceHost ? does it then use the HOST value of the HTTP 1.1 request ?

[bschmoll1]

Yes it uses the inbound http HOST value. Though I'm having "issues" with getting the correct port specified, currently the wsdl is showing

 <soap:address location="http://<www.blah.com>:-1/myservice"/>

No idea how it's coming up with -1, I tried setting the "webServicePort" in the property file to 80, but it still comes up as -1.

So if you find a work-around to that, I'd appreciate it if you could post it.

[peterj]

Try uncommenting the webServiceHost, setting the value to the IP address used outside the firewall. This example uses the IP address you identified as being the one that outside clients use:

<bean name="ServiceEndpointManager" class="org.jboss.ws.core.server.ServiceEndpointManager">
 <!--
 ---comment removed--
 -->
 <property name="webServiceHost">123.123.123.123</property>
 <property name="alwaysModifySOAPAddress">true</property>

Let us know if this fixes the problem.

[will.tatam]

This works, but it's still a hack

There is no reason at all to use a hard coded hostname unless you are looking to support ancient HTTP 1.0 clients, of which given SOAP comes years after 1.1 was released, I'm pretty sure all client support 1.1

Also this hack does not work as well as the way I used to do it as this will still re-write the url to include a port number, where my old method defined the full url so the access address doesn't have the nasty 8443 in there that can cause issues for clients accessing who might be behind firewalls