ant elder wrote:
On Tue, Oct 21, 2008 at 12:17 AM, Luciano Resende <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Ok, how about we make a step back and think on the sample scenario :
Considering a client application accessing a sca service using a web
service binding, if the service were deployed in a different machine
(e.g luck.apache.org:8080 <http://luck.apache.org:8080> versus
dhaval.apache.org:8081 <http://dhaval.apache.org:8081>), the
composite used by the client application would have to be changed to
point to the proper service. In this application, we are getting
confused because the client and the service are all archived together
in the same web application.
I think that's a fair comment (i.e., that I was confused when I wrote the
original comment that kicked off this discussion :-) For a service binding
in a webapp, it should definitely not be necessary to hardwire a host/port.
For a reference binding, there isn't really any way to avoid this without
solving issues 1 and 2 as described by Ant below.
To avoid future issues, and to make things clear, you could split the
application into two web apps, a client and a service.
Heh. but that doesn't really solve the reported issue - "It should be
possible to create a (sample) WAR that can be deployed to different port
numbers without needing to be changed."
I think there are three parts to this:
1) The Tuscany webapp runtime doesn't have a proper "Base URI" (see
Assembly spec) so there is no way to wire with binding.ws
<http://binding.ws> without an absolute endpoint URL. So the earlier
suggestion to use a relative URL doesn't work and nor would using the
target attribute on the reference like this:
<reference name="addService" target="AddServiceComponent">
<binding.ws <http://binding.ws> />
</reference>
2) The Tuscany webapp runtime has no way to automatically determine that
Base URI so even if (1) was fixed we couldn't do it automatically. The
problem here is that there is no way for code running in a webapp to
programatically find the URL to the webapp before a request comes in. -
what is the host name and port? You just don't know. Ok for this sample
you might be able to assume a hostname of 'localhost' but you don't
know the port number. If we fixed (1) then we could add a webapp
env-entry to configure the Base URI and IMHO that would make things much
clearer than having to hunt around the SCDL looking for the URLs that
need changing.
3) What is it that the sample is trying to show? I guess its showing
using SCA services and references using the Web Service binding with the
Tuscany webapp runtime, but is that - creating and using external web
service endpoints - or - wiring within an SCA domain using binding.ws
<http://binding.ws>? If its the first of those maybe we should split the
sample into two seperate webapps but that makes the sample more
complicated and the issue reported here would still exist - you would
still need to update the client for the absolute service endpoint. We
already have some seperate helloworld type samples with seperate WS
services and references and having this one a single sample is useful, i
use it a lot as a quick and easy way to see things are working ok.
Would be good to fix (1) and (2). Until then for this sample I think it
might be easiest for now to just document in the README that you need to
update the URLs in the SCDL to match where the webapp is deployed.
+1 for fixing (1) and (2).
The README for calculator-ws-webapp already says this, so no change is
required here. However, helloworld-ws-sdo-webapp has a similar problem
(in this case it's the WSDL that needs to be changed) and its README
doesn't mention this, so this should be updated.
Simon
...ant
