You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by bdm <br...@byu.edu> on 2008/04/01 00:07:03 UTC

WSDL First Development Cycle - specifically wsdl:port address question

I'm looking for suggestions for a "best practice" in how we accomplish moving
our CXF code through the various parts of our development lifecycle - i.e.
development, test, and production.  We have divided these responsibilities
among three hosts - ws-dev, ws-tst, and ws (production).  We also prefer
WSDL first development and are supplying our own wsdl to CXF.  

The problem we have is that we have to either change the wsdl as we move
through the various stages to reflect the new host, or add ports for each in
the original wsdl like so:

    <wsdl:service name="PersonService">
        <wsdl:port name="PersonPortStg" binding="tns:PersonBinding">
            <soap:address
                location="https://ws-tst/services/personService/PersonSOAP"
/>
        </wsdl:port>
        <wsdl:port name="PersonPortDev" binding="tns:PersonBinding">
            <soap:address
                location="https://ws-dev/services/personService/PersonSOAP"
/>
        </wsdl:port>
        <wsdl:port name="PersonPortProd" binding="tns:PersonBinding">
            <soap:address
                location="https://ws/services/personService/PersonSOAP" />
        </wsdl:port>
        <wsdl:port name="PersonPortLocal" binding="tns:PersonBinding">
            <soap:address
                location="http://localhost:8080/personService/PersonSOAP" 
/>
        </wsdl:port>
    </wsdl:service>

We are early enough in the process that we can change our practice without
much pain right now, but soon we will have to live with what we have.  

We are really interested in what others are doing to handle this issue.


Thanks in advance,

Brent
-- 
View this message in context: http://www.nabble.com/WSDL-First-Development-Cycle---specifically-wsdl%3Aport-address-question-tp16399116p16399116.html
Sent from the cxf-user mailing list archive at Nabble.com.


Re: WSDL First Development Cycle - specifically wsdl:port address question

Posted by Glen Mazza <gl...@verizon.net>.
I haven't given this much thought before but I'm not sure why it matters
what the address is in the WSDL that is sent from the service to the
client.  By virtue of the fact that the client accessed the service
using the ...?wsdl URL in order to get the WSDL to begin with, it
already knows what URL to use to get to the web service--the same one it
used to get the WSDL.  Furthermore, it arguably should not use the URL
in the downloaded WSDL at that stage.  Might that not be a
security/safety risk?

For the following three web services below from commercial companies,
none of the URLs in the soap:address match that of the URL used to get
the WSDL.  (Or am I missing something?)

[1] http://developer.ebay.com/webservices/latest/ShoppingService.wsdl
[2] http://sdpwsparam.strikeiron.com/sdpNFLTeams?WSDL
[3]
http://webservices.amazon.com/AWSECommerceService/AWSECommerceService.wsdl?

Regards,
Glen


Am Dienstag, den 01.04.2008, 15:31 -0600 schrieb Brent Moore:
> Dan,
> 
> I've created a JIRA [1] with an attached war for an echo service that
> exhibits the behavior I'm talking about.  If I understand you
> correctly, the "bogushost" address should be replaced with the real
> address of the service.  But at least on my tomcat 5.5.23 it doesn't
> happen.  
> 
> Once it does happen, is there a way to influence which of the aliases
> for the box it uses?  Some of our boxes serve multiple virtual hosts.
> 
> 
> [1] http://jira.codehaus.org/browse/CXF-1497 
> 
> 
> Thanks for the help.
> 
> 
> Brent
> 
> Daniel Kulp wrote: 
> > If the client is grabbing the wsdl view the ?wsdl flag to the endpoint, 
> > it SHOULD be getting a modified wsdl that has the proper address in it.   
> > If that's not the case, that might be a bug, but it's probably a 
> > configuration issue as I know we have several tests that test this (and 
> > the TCK requires it to work).  Thus, I'd probably like to see a war that 
> > demonstrates this.
> > 
> > Also, the client can always be reconfigured post-creation to hit any url 
> > you give it.   It DOESN'T need to use the url in the wsdl.   If the 
> > container can provide a new URL, just set the ENDPOINT_ADDRESS_PROPERY 
> > thing on the client's request context and it will use that address 
> > instead.
> > 
> > Dan
> > 
> > 
> > 
> > On Tuesday 01 April 2008, bdm wrote:
> >   
> > > Glen,
> > > 
> > > Thanks for the response but I may not have been clear on what I'm
> > > trying to accomplish.
> > > 
> > > In our normal development life cycle, once code (a .war file in this
> > > case) leaves development for test and production we do not change
> > > anything in the code or the accompanying configuration files (spring
> > > context, etc).  All of the differences in the environments (database
> > > connections, etc) are handled by the container - tomcat in this case. 
> > > We would like to implement the same type of configuration with our web
> > > service deployments.
> > > 
> > > In [1] - the last sentence of note 4 reads - "Note the URL specified
> > > in the wsdl:port section (under wsdl:service) is ignored by the
> > > servlet container. It is used, however, by the web service client
> > > which reads in this WSDL to determine where to route the requests."
> > > 
> > > This is exactly the problem.  Yes the web service deploys correctly
> > > and the servlet container ignores the address given in the provided
> > > WSDL.  But, the WSDL is delivered unmodified to any requesting client
> > > with the address given in the WSDL and not the address of the service.
> > >  I tried this yesterday one last time before posting to the list using
> > > 2.0.4 of CXF.
> > > 
> > > I'm not sure if that is a bug or a feature, I'm just trying to figure
> > > out how to implement our standard practice given the current behavior
> > > of CXF.
> > > 
> > > Brent
> > > 
> > > Glen Mazza-2 wrote:
> > >     
> > > > Note #4 of here[1] shows how the WSDL URL is created when you deploy
> > > > to an application server; as you can see, what you have in the wsdl
> > > > file is pretty much ignored web-service provider side.
> > > > 
> > > > For the client, it is just an issue of modifying the
> > > > ENDPOINT_ADDRESS_PROPERTY as shown in Step #7 here[2].  You can use
> > > > Spring Dependency Injection for that if helpful.
> > > > 
> > > > Glen
> > > > 
> > > > [1] http://www.jroller.com/gmazza/date/20071019#notes
> > > > [2] http://www.jroller.com/gmazza/entry/using_the_ebay_shopping_api1
> > > >       
> > 
> > 
> > 
> >   
> 
> -- 
> *********************************
> Brent Moore
> Platform Engineering
> Office of Information Technology
> Brigham Young University
> 
> Character is what you have left when
> you've lost everything you can lose.
>   - Evan Esar
> ********************************


Re: WSDL First Development Cycle - specifically wsdl:port address question

Posted by Daniel Kulp <dk...@apache.org>.
Brent,

On Tuesday 01 April 2008, Brent Moore wrote:
>  I've created a JIRA [1] with an attached war for an echo service that
> exhibits the behavior I'm talking about.  If I understand you
> correctly, the "bogushost" address should be replaced with the real
> address of the service.  But at least on my tomcat 5.5.23 it doesn't
> happen. 

I looked at the war and can duplicate the issue.   I probably won't have 
a chance to dig into the code and find out what is going on until Friday 
though.  (meetings)   Couple quite thoughts:
1) As Glenn said, try using WEB-INF/wsdl/...  for the wsdlLocation.

2) Put SOMETHING valid in the wsdls soap:address.   Just put 
in "http://localhost:8080/" or something.   We MIGHT be trying to parse 
whats there or something and your blank location might be confusing it.

Anyway, I can dig into it more on Friday to figure out really what it 
going on.

>  Once it does happen, is there a way to influence which of the aliases
> for the box it uses?  Some of our boxes serve multiple virtual hosts.

It will use the URL from the incoming request.   For example, if you hit 
localhost:8080, that is what will appear in the returned wsdl.  If you 
hit "myhost.com", that is what will appear.   

Dan


>
>  [1] http://jira.codehaus.org/browse/CXF-1497
>
>
>  Thanks for the help.
>
>
>  Brent
>
>  Daniel Kulp wrote:
> If the client is grabbing the wsdl view the ?wsdl flag to the
> endpoint, it SHOULD be getting a modified wsdl that has the proper
> address in it. If that's not the case, that might be a bug, but it's
> probably a configuration issue as I know we have several tests that
> test this (and the TCK requires it to work).  Thus, I'd probably like
> to see a war that demonstrates this.
>
> Also, the client can always be reconfigured post-creation to hit any
> url you give it.   It DOESN'T need to use the url in the wsdl.   If
> the container can provide a new URL, just set the
> ENDPOINT_ADDRESS_PROPERY thing on the client's request context and it
> will use that address instead.
>
> Dan
>
>
>
> On Tuesday 01 April 2008, bdm wrote:
>
> Glen,
>
> Thanks for the response but I may not have been clear on what I'm
> trying to accomplish.
>
> In our normal development life cycle, once code (a .war file in this
> case) leaves development for test and production we do not change
> anything in the code or the accompanying configuration files (spring
> context, etc).  All of the differences in the environments (database
> connections, etc) are handled by the container - tomcat in this case.
> We would like to implement the same type of configuration with our web
> service deployments.
>
> In [1] - the last sentence of note 4 reads - "Note the URL specified
> in the wsdl:port section (under wsdl:service) is ignored by the
> servlet container. It is used, however, by the web service client
> which reads in this WSDL to determine where to route the requests."
>
> This is exactly the problem.  Yes the web service deploys correctly
> and the servlet container ignores the address given in the provided
> WSDL.  But, the WSDL is delivered unmodified to any requesting client
> with the address given in the WSDL and not the address of the service.
>  I tried this yesterday one last time before posting to the list using
> 2.0.4 of CXF.
>
> I'm not sure if that is a bug or a feature, I'm just trying to figure
> out how to implement our standard practice given the current behavior
> of CXF.
>
> Brent
>
> Glen Mazza-2 wrote:
>
> Note #4 of here[1] shows how the WSDL URL is created when you deploy
> to an application server; as you can see, what you have in the wsdl
> file is pretty much ignored web-service provider side.
>
> For the client, it is just an issue of modifying the
> ENDPOINT_ADDRESS_PROPERTY as shown in Step #7 here[2].  You can use
> Spring Dependency Injection for that if helpful.
>
> Glen
>
> [1] http://www.jroller.com/gmazza/date/20071019#notes
> [2] http://www.jroller.com/gmazza/entry/using_the_ebay_shopping_api1



-- 
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog

Re: WSDL First Development Cycle - specifically wsdl:port address question

Posted by Daniel Kulp <dk...@apache.org>.
If the client is grabbing the wsdl view the ?wsdl flag to the endpoint, 
it SHOULD be getting a modified wsdl that has the proper address in it.   
If that's not the case, that might be a bug, but it's probably a 
configuration issue as I know we have several tests that test this (and 
the TCK requires it to work).  Thus, I'd probably like to see a war that 
demonstrates this.

Also, the client can always be reconfigured post-creation to hit any url 
you give it.   It DOESN'T need to use the url in the wsdl.   If the 
container can provide a new URL, just set the ENDPOINT_ADDRESS_PROPERY 
thing on the client's request context and it will use that address 
instead.

Dan



On Tuesday 01 April 2008, bdm wrote:
> Glen,
>
> Thanks for the response but I may not have been clear on what I'm
> trying to accomplish.
>
> In our normal development life cycle, once code (a .war file in this
> case) leaves development for test and production we do not change
> anything in the code or the accompanying configuration files (spring
> context, etc).  All of the differences in the environments (database
> connections, etc) are handled by the container - tomcat in this case. 
> We would like to implement the same type of configuration with our web
> service deployments.
>
> In [1] - the last sentence of note 4 reads - "Note the URL specified
> in the wsdl:port section (under wsdl:service) is ignored by the
> servlet container. It is used, however, by the web service client
> which reads in this WSDL to determine where to route the requests."
>
> This is exactly the problem.  Yes the web service deploys correctly
> and the servlet container ignores the address given in the provided
> WSDL.  But, the WSDL is delivered unmodified to any requesting client
> with the address given in the WSDL and not the address of the service.
>  I tried this yesterday one last time before posting to the list using
> 2.0.4 of CXF.
>
> I'm not sure if that is a bug or a feature, I'm just trying to figure
> out how to implement our standard practice given the current behavior
> of CXF.
>
> Brent
>
> Glen Mazza-2 wrote:
> > Note #4 of here[1] shows how the WSDL URL is created when you deploy
> > to an application server; as you can see, what you have in the wsdl
> > file is pretty much ignored web-service provider side.
> >
> > For the client, it is just an issue of modifying the
> > ENDPOINT_ADDRESS_PROPERTY as shown in Step #7 here[2].  You can use
> > Spring Dependency Injection for that if helpful.
> >
> > Glen
> >
> > [1] http://www.jroller.com/gmazza/date/20071019#notes
> > [2] http://www.jroller.com/gmazza/entry/using_the_ebay_shopping_api1



-- 
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog

Re: WSDL First Development Cycle - specifically wsdl:port address question

Posted by bdm <br...@byu.edu>.
Glen,

Thanks for the response but I may not have been clear on what I'm trying to
accomplish.  

In our normal development life cycle, once code (a .war file in this case)
leaves development for test and production we do not change anything in the
code or the accompanying configuration files (spring context, etc).  All of
the differences in the environments (database connections, etc) are handled
by the container - tomcat in this case.  We would like to implement the same
type of configuration with our web service deployments.  

In [1] - the last sentence of note 4 reads - "Note the URL specified in the
wsdl:port section (under wsdl:service) is ignored by the servlet container.
It is used, however, by the web service client which reads in this WSDL to
determine where to route the requests."

This is exactly the problem.  Yes the web service deploys correctly and the
servlet container ignores the address given in the provided WSDL.  But, the
WSDL is delivered unmodified to any requesting client with the address given
in the WSDL and not the address of the service.  I tried this yesterday one
last time before posting to the list using 2.0.4 of CXF.  

I'm not sure if that is a bug or a feature, I'm just trying to figure out
how to implement our standard practice given the current behavior of CXF.

Brent



Glen Mazza-2 wrote:
> 
> Note #4 of here[1] shows how the WSDL URL is created when you deploy to
> an application server; as you can see, what you have in the wsdl file is
> pretty much ignored web-service provider side.
> 
> For the client, it is just an issue of modifying the
> ENDPOINT_ADDRESS_PROPERTY as shown in Step #7 here[2].  You can use
> Spring Dependency Injection for that if helpful.
> 
> Glen
> 
> [1] http://www.jroller.com/gmazza/date/20071019#notes
> [2] http://www.jroller.com/gmazza/entry/using_the_ebay_shopping_api1
> 
> 
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/WSDL-First-Development-Cycle---specifically-wsdl%3Aport-address-question-tp16399116p16418462.html
Sent from the cxf-user mailing list archive at Nabble.com.


Re: WSDL First Development Cycle - specifically wsdl:port address question

Posted by Glen Mazza <gl...@verizon.net>.
Note #4 of here[1] shows how the WSDL URL is created when you deploy to
an application server; as you can see, what you have in the wsdl file is
pretty much ignored web-service provider side.

For the client, it is just an issue of modifying the
ENDPOINT_ADDRESS_PROPERTY as shown in Step #7 here[2].  You can use
Spring Dependency Injection for that if helpful.

Glen

[1] http://www.jroller.com/gmazza/date/20071019#notes
[2] http://www.jroller.com/gmazza/entry/using_the_ebay_shopping_api1

Am Montag, den 31.03.2008, 15:07 -0700 schrieb bdm:
> I'm looking for suggestions for a "best practice" in how we accomplish moving
> our CXF code through the various parts of our development lifecycle - i.e.
> development, test, and production.  We have divided these responsibilities
> among three hosts - ws-dev, ws-tst, and ws (production).  We also prefer
> WSDL first development and are supplying our own wsdl to CXF.  
> 
> The problem we have is that we have to either change the wsdl as we move
> through the various stages to reflect the new host, or add ports for each in
> the original wsdl like so:
> 
>     <wsdl:service name="PersonService">
>         <wsdl:port name="PersonPortStg" binding="tns:PersonBinding">
>             <soap:address
>                 location="https://ws-tst/services/personService/PersonSOAP"
> />
>         </wsdl:port>
>         <wsdl:port name="PersonPortDev" binding="tns:PersonBinding">
>             <soap:address
>                 location="https://ws-dev/services/personService/PersonSOAP"
> />
>         </wsdl:port>
>         <wsdl:port name="PersonPortProd" binding="tns:PersonBinding">
>             <soap:address
>                 location="https://ws/services/personService/PersonSOAP" />
>         </wsdl:port>
>         <wsdl:port name="PersonPortLocal" binding="tns:PersonBinding">
>             <soap:address
>                 location="http://localhost:8080/personService/PersonSOAP" 
> />
>         </wsdl:port>
>     </wsdl:service>
> 
> We are early enough in the process that we can change our practice without
> much pain right now, but soon we will have to live with what we have.  
> 
> We are really interested in what others are doing to handle this issue.
> 
> 
> Thanks in advance,
> 
> Brent


Re: WSDL First Development Cycle - specifically wsdl:port address question

Posted by Freeman Fang <fr...@gmail.com>.
Hi,

I think you can configure endpoint address by spring, you can change it 
in spring configure file according to different development cycle phase.

[1] for more details

[1]http://cwiki.apache.org/CXF20DOC/jax-ws-configuration.html

Freeman

bdm wrote:
> I'm looking for suggestions for a "best practice" in how we accomplish moving
> our CXF code through the various parts of our development lifecycle - i.e.
> development, test, and production.  We have divided these responsibilities
> among three hosts - ws-dev, ws-tst, and ws (production).  We also prefer
> WSDL first development and are supplying our own wsdl to CXF.  
>
> The problem we have is that we have to either change the wsdl as we move
> through the various stages to reflect the new host, or add ports for each in
> the original wsdl like so:
>
>     <wsdl:service name="PersonService">
>         <wsdl:port name="PersonPortStg" binding="tns:PersonBinding">
>             <soap:address
>                 location="https://ws-tst/services/personService/PersonSOAP"
> />
>         </wsdl:port>
>         <wsdl:port name="PersonPortDev" binding="tns:PersonBinding">
>             <soap:address
>                 location="https://ws-dev/services/personService/PersonSOAP"
> />
>         </wsdl:port>
>         <wsdl:port name="PersonPortProd" binding="tns:PersonBinding">
>             <soap:address
>                 location="https://ws/services/personService/PersonSOAP" />
>         </wsdl:port>
>         <wsdl:port name="PersonPortLocal" binding="tns:PersonBinding">
>             <soap:address
>                 location="http://localhost:8080/personService/PersonSOAP" 
> />
>         </wsdl:port>
>     </wsdl:service>
>
> We are early enough in the process that we can change our practice without
> much pain right now, but soon we will have to live with what we have.  
>
> We are really interested in what others are doing to handle this issue.
>
>
> Thanks in advance,
>
> Brent
>