You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Steven E. Harris" <se...@panix.com> on 2007/05/02 22:33:43 UTC
Why does a JAX-WS client use the WSDL at run time?
I'm trying to understand a big difference in how a Web Service client
works in JAX-WS/CXF versus AXIS2. In AXIS2, the WSDL2Java process
reads a WSDL document and creates a lot of code to create, transport,
and consume messages as directed by the WSDL. After this WSDL2Java
process, the WSDL document is no longer required; it has essentially
been compiled into a set of Java operations that obey the WSDL's
specifications.
In JAX-WS, the WSDL2Java process also creates code, annotated with
details from the motivating WSDL document. I had assumed that these
annotations are used at compile time to generate much of the extra
code we see generated by the AXIS2 WSDL2Java process. Instead, I find
that the generated Service type wants to read a WSDL file in its
constructor (following the call chain along to
org.apache.cxf.wsdl11.WSDLServiceFactory.create() called on by
org.apache.cxf.jaxwsServiceImpl.initializePorts()).
Why does the client need to read the WSDL file at run time? Don't the
annotations and method signatures provide enough information to lock
in the basic operations it must perform? Is there some way to avoid
needing to use the WSDL file at run time?
--
Steven E. Harris
Re: Why does a JAX-WS client use the WSDL at run time?
Posted by "Steven E. Harris" <se...@panix.com>.
Daniel Kulp <dk...@apache.org> writes:
> The port only represents the operations defined in the WSDL. What
> happens if your wsdl has a setTargetAddress operation?
Ah, right. Then perhaps it could be something like:
Service.setTargetAddressOf( port, new URI( "..." ) );
That is, the Service class (or something else) would know enough about
the port implementation to access its innards and set the right
property.
--
Steven E. Harris
Re: Why does a JAX-WS client use the WSDL at run time?
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday 03 May 2007 21:42, Steven E. Harris wrote:
> Daniel Kulp <dk...@apache.org> writes:
> > This is part of the JAX-WS spec. You can override the URL that a
> > client uses by setting the BindingProvider.ENDPOINT_ADDRESS_URL
> > property on the request context:
> >
> > ((BindingProvider)port).getRequestContext().put(
> > BindingProvider.ENDPOINT_ADDRESS_PROPERY,
> > "http://foo.com/blah");
>
> I found a similar recipe on one of Sun's blogger's sites last night,
> and I'm still thinking, "Are they serious?" There's a cast, a method
> call to get a map of strings, and, as some icing, a manifest constant
> to designate which string means "target address".
>
> I'm sure it works, but it's crying out for some convenience wrappers
> to hide this "map of strings" underbelly. Is the problem that some
> ports don't have meaningful addresses? What else precludes exposing
>
> port.setTargetAddress(URI)
>
> or similar?
The port only represents the operations defined in the WSDL. What
happens if your wsdl has a setTargetAddress operation?
CORBA kind of got around that issue by allowing method names starting
with "_" for vendor stuff. But that always smelled like a hack as
well.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: Why does a JAX-WS client use the WSDL at run time?
Posted by "Steven E. Harris" <se...@panix.com>.
Daniel Kulp <dk...@apache.org> writes:
> This is part of the JAX-WS spec. You can override the URL that a client
> uses by setting the BindingProvider.ENDPOINT_ADDRESS_URL property on the
> request context:
>
> ((BindingProvider)port).getRequestContext().put(
> BindingProvider.ENDPOINT_ADDRESS_PROPERY,
> "http://foo.com/blah");
I found a similar recipe on one of Sun's blogger's sites last night,
and I'm still thinking, "Are they serious?" There's a cast, a method
call to get a map of strings, and, as some icing, a manifest constant
to designate which string means "target address".
I'm sure it works, but it's crying out for some convenience wrappers
to hide this "map of strings" underbelly. Is the problem that some
ports don't have meaningful addresses? What else precludes exposing
port.setTargetAddress(URI)
or similar?
--
Steven E. Harris
Re: Why does a JAX-WS client use the WSDL at run time?
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday 03 May 2007 19:41, Christopher Moesel wrote:
> +1 on Steve's comment. Does a client need to have access to the
> actual WSDL at run-time?
>
> And on a related note, is there a way for a client to specify a
> different endpoint URI at runtime? The current API allows you to pass
> in a URL to a WSDL file, but what if I just want to use the WSDL I
> built off of, but want to point all requests at a test server (or just
> change the port so I can use TCPMon)? All of the other major
> frameworks make this pretty easy. Maybe it exists in CXF but is
> undocumented?
This is part of the JAX-WS spec. You can override the URL that a client
uses by setting the BindingProvider.ENDPOINT_ADDRESS_URL property on the
request context:
((BindingProvider)port).getRequestContext().put(
BindingProvider.ENDPOINT_ADDRESS_PROPERY,
"http://foo.com/blah");
Dan
>
> -Chris
>
> -----Original Message-----
> From: Steven E. Harris [mailto:seh@panix.com]
> Sent: Wed 5/2/2007 4:33 PM
> To: cxf-user@incubator.apache.org
> Subject: Why does a JAX-WS client use the WSDL at run time?
>
> I'm trying to understand a big difference in how a Web Service client
> works in JAX-WS/CXF versus AXIS2. In AXIS2, the WSDL2Java process
> reads a WSDL document and creates a lot of code to create, transport,
> and consume messages as directed by the WSDL. After this WSDL2Java
> process, the WSDL document is no longer required; it has essentially
> been compiled into a set of Java operations that obey the WSDL's
> specifications.
>
> In JAX-WS, the WSDL2Java process also creates code, annotated with
> details from the motivating WSDL document. I had assumed that these
> annotations are used at compile time to generate much of the extra
> code we see generated by the AXIS2 WSDL2Java process. Instead, I find
> that the generated Service type wants to read a WSDL file in its
> constructor (following the call chain along to
> org.apache.cxf.wsdl11.WSDLServiceFactory.create() called on by
> org.apache.cxf.jaxwsServiceImpl.initializePorts()).
>
> Why does the client need to read the WSDL file at run time? Don't the
> annotations and method signatures provide enough information to lock
> in the basic operations it must perform? Is there some way to avoid
> needing to use the WSDL file at run time?
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
RE: Why does a JAX-WS client use the WSDL at run time?
Posted by Christopher Moesel <Ch...@avid.com>.
+1 on Steve's comment. Does a client need to have access to the actual WSDL at run-time?
And on a related note, is there a way for a client to specify a different endpoint URI at runtime? The current API allows you to pass in a URL to a WSDL file, but what if I just want to use the WSDL I built off of, but want to point all requests at a test server (or just change the port so I can use TCPMon)? All of the other major frameworks make this pretty easy. Maybe it exists in CXF but is undocumented?
-Chris
-----Original Message-----
From: Steven E. Harris [mailto:seh@panix.com]
Sent: Wed 5/2/2007 4:33 PM
To: cxf-user@incubator.apache.org
Subject: Why does a JAX-WS client use the WSDL at run time?
I'm trying to understand a big difference in how a Web Service client
works in JAX-WS/CXF versus AXIS2. In AXIS2, the WSDL2Java process
reads a WSDL document and creates a lot of code to create, transport,
and consume messages as directed by the WSDL. After this WSDL2Java
process, the WSDL document is no longer required; it has essentially
been compiled into a set of Java operations that obey the WSDL's
specifications.
In JAX-WS, the WSDL2Java process also creates code, annotated with
details from the motivating WSDL document. I had assumed that these
annotations are used at compile time to generate much of the extra
code we see generated by the AXIS2 WSDL2Java process. Instead, I find
that the generated Service type wants to read a WSDL file in its
constructor (following the call chain along to
org.apache.cxf.wsdl11.WSDLServiceFactory.create() called on by
org.apache.cxf.jaxwsServiceImpl.initializePorts()).
Why does the client need to read the WSDL file at run time? Don't the
annotations and method signatures provide enough information to lock
in the basic operations it must perform? Is there some way to avoid
needing to use the WSDL file at run time?
--
Steven E. Harris
Re: Why does a JAX-WS client use the WSDL at run time?
Posted by Daniel Kulp <dk...@apache.org>.
On Friday 04 May 2007 09:59, DONAHUE, BRYON J, ATTSI wrote:
> This is probably more of a JAXB2 question but... Many JAX-RPC
> implementations do not generate code to support XSD facets and the
> WSDL and embedded schema, in particular, are required at runtime to
> pick up the facets for runtime enforcement.
>
> This behavior is nice because facets can be changed and applied to the
> application at runtime without requiring code regen, redeployment,
> and, especially, retesting. In the enterprise environment, this is a
> powerful feature.
>
> Does CXF code gen facet enforcement? Or, is the WSDL/XSD required at
> runtime to support facet enforcement?
That's another (optional) use of the wsdl/schema at runtime. There's a
flag someplace (don't remember where, I'd have to dig through some code
to find it) to turn on the runtime validation. This does require the
schema to be available as much of that information is not burned into
the jaxb code.
That said, there is a performance impact of turning that on. That's
just something to keep in mind.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
RE: Why does a JAX-WS client use the WSDL at run time?
Posted by "DONAHUE, BRYON J, ATTSI" <bd...@att.com>.
This is probably more of a JAXB2 question but... Many JAX-RPC
implementations do not generate code to support XSD facets and the WSDL
and embedded schema, in particular, are required at runtime to pick up
the facets for runtime enforcement.
This behavior is nice because facets can be changed and applied to the
application at runtime without requiring code regen, redeployment, and,
especially, retesting. In the enterprise environment, this is a powerful
feature.
Does CXF code gen facet enforcement? Or, is the WSDL/XSD required at
runtime to support facet enforcement?
Bryon Donahue
-----Original Message-----
From: Christopher Moesel [mailto:Christopher_Moesel@avid.com]
Sent: Friday, May 04, 2007 8:27 AM
To: cxf-user@incubator.apache.org; dkulp@apache.org
Subject: RE: Why does a JAX-WS client use the WSDL at run time?
If the client is using the WSDL to check if it matches the code, does it
fail if the WSDL has changed? What if the WSDL has gone up a minor
revision, but all changes were backward compatible so existing clients
would still work? Can the client detect that it is still compatible on
the wire even though the WSDL has changed?
-Chris
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: Friday, May 04, 2007 9:23 AM
To: cxf-user@incubator.apache.org
Subject: Re: Why does a JAX-WS client use the WSDL at run time?
On Thursday 03 May 2007 21:55, Steven E. Harris wrote:
> Daniel Kulp <dk...@apache.org> writes:
> > Technically, with JAX-WS, you don't need the wsdl. However, the
> > spec does say that if it's available/specified, we're supposed to
> > use it.
>
> Use it to supply default values? It seems like a large run time tax
> that the WSDL2Java tool -- or something like it -- should be fixing
> into code.
There's a couple places it's really used. One is the actual connection
information. The URL isn't burned in anywhere. The other thing that
is done is to make sure the WSDL actually matches the code. For
example, does the interface that you are using actually have matching
operations in the wsdl.
On the server side, if the original WSDL is available, we return it
during ?wsdl processing rather than synthesize one.
.............
> > You would still need to set the endpoint address though. That
> > doesn't get recorded anywhere.
>
> Oh, as that normally gets read from the WSDL at run time, not from an
> annotation on the Service-derived class, right?
Right.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
RE: Why does a JAX-WS client use the WSDL at run time?
Posted by Andrei Shakirin <as...@talend.com>.
Hi,
Basically it is not absolutely necessary for the client to use WSDL at runtime time.
There are some cases when this is handy:
1. Using complex schema validations
2. Applying WS-Policy embedded to the WSDL
3. Resolving endpoint through the WSDL (if WSDL is retrieved from the central storage)
If this is not your case, you will be able to run client without WSDL. CXF will build service model on the base of generated classes.
Regards,
Andrei.
> -----Original Message-----
> From: yhjhoo [mailto:yhjhoo@gmail.com]
> Sent: Dienstag, 7. April 2015 15:50
> To: users@cxf.apache.org
> Subject: RE: Why does a JAX-WS client use the WSDL at run time?
>
> I am encountering this issue now.
>
>
> My wsdl file too big, the client takes quite long time to start.
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Why-does-a-
> JAX-WS-client-use-the-WSDL-at-run-time-tp548595p5755716.html
> Sent from the cxf-user mailing list archive at Nabble.com.
RE: Why does a JAX-WS client use the WSDL at run time?
Posted by yhjhoo <yh...@gmail.com>.
I am encountering this issue now.
My wsdl file too big, the client takes quite long time to start.
--
View this message in context: http://cxf.547215.n5.nabble.com/Why-does-a-JAX-WS-client-use-the-WSDL-at-run-time-tp548595p5755716.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: Why does a JAX-WS client use the WSDL at run time?
Posted by Christopher Moesel <Ch...@avid.com>.
> But is the idea here that a client would fetch this WSDL document from
> some remote server, or that it will have a WSDL document bundled up,
> say, in its JAR?
> I ask because fetching the WSDL from a remote server would add one
> network round-trip to every client's start-up sequence.
If this is the case, this could become a problem in some cases. I'm
thinking of the eBay service-- it's WSDL is over 3MB!
-Chris
Re: Why does a JAX-WS client use the WSDL at run time?
Posted by "Steven E. Harris" <se...@panix.com>.
Sergey Beryozkin <se...@iona.com> writes:
> Another reason a client can benefit from using a wsdl is that it
> might bring extra uptodate information for the client policy engine,
> extra alternative endpoints, etc...
But is the idea here that a client would fetch this WSDL document from
some remote server, or that it will have a WSDL document bundled up,
say, in its JAR?
I ask because fetching the WSDL from a remote server would add one
network round-trip to every client's start-up sequence. That seems
like a strange design: "The first thing the client does is contact
some server to see if the client still knows how to talk to service
and to figure out where and how the service is now offered."
That's a far cry from "contract-first" design that would allow clients
and servers to built independently, having agreed to a fixed set of
assumptions.
--
Steven E. Harris
Re: Why does a JAX-WS client use the WSDL at run time?
Posted by Sergey Beryozkin <se...@iona.com>.
Another reason a client can benefit from using a wsdl is that it might bring extra uptodate information for the client policy
engine, extra alternative endpoints, etc...
Cheers, Sergey
----- Original Message -----
From: "Daniel Kulp" <dk...@apache.org>
To: <cx...@incubator.apache.org>
Sent: Friday, May 04, 2007 2:23 PM
Subject: Re: Why does a JAX-WS client use the WSDL at run time?
> On Thursday 03 May 2007 21:55, Steven E. Harris wrote:
>> Daniel Kulp <dk...@apache.org> writes:
>> > Technically, with JAX-WS, you don't need the wsdl. However, the
>> > spec does say that if it's available/specified, we're supposed to
>> > use it.
>>
>> Use it to supply default values? It seems like a large run time tax
>> that the WSDL2Java tool -- or something like it -- should be fixing
>> into code.
>
> There's a couple places it's really used. One is the actual connection
> information. The URL isn't burned in anywhere. The other thing that
> is done is to make sure the WSDL actually matches the code. For
> example, does the interface that you are using actually have matching
> operations in the wsdl.
>
> On the server side, if the original WSDL is available, we return it
> during ?wsdl processing rather than synthesize one.
>
>
> .............
>
>> > You would still need to set the endpoint address though. That
>> > doesn't get recorded anywhere.
>>
>> Oh, as that normally gets read from the WSDL at run time, not from an
>> annotation on the Service-derived class, right?
>
> Right.
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
RE: Why does a JAX-WS client use the WSDL at run time?
Posted by Christopher Moesel <Ch...@avid.com>.
If the client is using the WSDL to check if it matches the code, does it
fail if the WSDL has changed? What if the WSDL has gone up a minor
revision, but all changes were backward compatible so existing clients
would still work? Can the client detect that it is still compatible on
the wire even though the WSDL has changed?
-Chris
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: Friday, May 04, 2007 9:23 AM
To: cxf-user@incubator.apache.org
Subject: Re: Why does a JAX-WS client use the WSDL at run time?
On Thursday 03 May 2007 21:55, Steven E. Harris wrote:
> Daniel Kulp <dk...@apache.org> writes:
> > Technically, with JAX-WS, you don't need the wsdl. However, the
> > spec does say that if it's available/specified, we're supposed to
> > use it.
>
> Use it to supply default values? It seems like a large run time tax
> that the WSDL2Java tool -- or something like it -- should be fixing
> into code.
There's a couple places it's really used. One is the actual connection
information. The URL isn't burned in anywhere. The other thing that
is done is to make sure the WSDL actually matches the code. For
example, does the interface that you are using actually have matching
operations in the wsdl.
On the server side, if the original WSDL is available, we return it
during ?wsdl processing rather than synthesize one.
.............
> > You would still need to set the endpoint address though. That
> > doesn't get recorded anywhere.
>
> Oh, as that normally gets read from the WSDL at run time, not from an
> annotation on the Service-derived class, right?
Right.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: Why does a JAX-WS client use the WSDL at run time?
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday 03 May 2007 21:55, Steven E. Harris wrote:
> Daniel Kulp <dk...@apache.org> writes:
> > Technically, with JAX-WS, you don't need the wsdl. However, the
> > spec does say that if it's available/specified, we're supposed to
> > use it.
>
> Use it to supply default values? It seems like a large run time tax
> that the WSDL2Java tool -- or something like it -- should be fixing
> into code.
There's a couple places it's really used. One is the actual connection
information. The URL isn't burned in anywhere. The other thing that
is done is to make sure the WSDL actually matches the code. For
example, does the interface that you are using actually have matching
operations in the wsdl.
On the server side, if the original WSDL is available, we return it
during ?wsdl processing rather than synthesize one.
.............
> > You would still need to set the endpoint address though. That
> > doesn't get recorded anywhere.
>
> Oh, as that normally gets read from the WSDL at run time, not from an
> annotation on the Service-derived class, right?
Right.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: Why does a JAX-WS client use the WSDL at run time?
Posted by "Steven E. Harris" <se...@panix.com>.
Daniel Kulp <dk...@apache.org> writes:
> Technically, with JAX-WS, you don't need the wsdl. However, the
> spec does say that if it's available/specified, we're supposed to
> use it.
Use it to supply default values? It seems like a large run time tax
that the WSDL2Java tool -- or something like it -- should be fixing
into code.
> For the most part, if you remove the wsdlLocation attribute, it
> should work.
Yes, I figured out somewhat after writing yesterday. It's annoying
that there's a no-arg constructor that supplies the WSDL location and
the service name, and there's a two-arg constructor requiring WSDL
location and service name. What I really want is a one-arg constructor
asking for the WSDL location -- which I could designate as null -- but
that uses the known service name. The code generator puts this service
name in the class as a manifest constant ("SERVICE"), but it's
private, so I can't even reuse the string when calling the two-arg
constructor myself. Oh, and I'm pretty sure the service name is
required, though I'm not sure why if the WSDL isn't provided.
I then saw that I could call addPort() to define a target, but then I
ran into this problem:
Service.addPort(QName, String, String) does not accept binding ID
javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_BINDING
http://issues.apache.org/jira/browse/CXF-628
> The client side ends up being a bit different. You don't really use the
> generated service class. Instead, you can do something like:
>
> PortClass port = Service.create(serviceName).getPort(PortClass.class);
> ((BindingProvider)port).getRequestContext().put(
> BindingProvider.ENDPOINT_ADDRESS_PROPERY,
> "http://foo.com/blah");
Oh, that's different. What's the purpose of the serviceName attribute
passed to Service.create()?
> You MAY be able to pass null into the generated service for the
> wsdlLocation. I'm not sure if that works or not.
Yes, it sort of works, but I'll need to get past the JIRA issue above
to know for sure.
> You would still need to set the endpoint address though. That
> doesn't get recorded anywhere.
Oh, as that normally gets read from the WSDL at run time, not from an
annotation on the Service-derived class, right?
--
Steven E. Harris
Re: Why does a JAX-WS client use the WSDL at run time?
Posted by Daniel Kulp <dk...@apache.org>.
Steven,
Technically, with JAX-WS, you don't need the wsdl. However, the spec
does say that if it's available/specified, we're supposed to use it.
For the most part, if you remove the wsdlLocation attribute, it should
work.
The client side ends up being a bit different. You don't really use the
generated service class. Instead, you can do something like:
PortClass port = Service.create(serviceName).getPort(PortClass.class);
((BindingProvider)port).getRequestContext().put(
BindingProvider.ENDPOINT_ADDRESS_PROPERY,
"http://foo.com/blah");
You MAY be able to pass null into the generated service for the
wsdlLocation. I'm not sure if that works or not. You would still
need to set the endpoint address though. That doesn't get recorded
anywhere.
Dan
On Wednesday 02 May 2007 16:33, Steven E. Harris wrote:
> I'm trying to understand a big difference in how a Web Service client
> works in JAX-WS/CXF versus AXIS2. In AXIS2, the WSDL2Java process
> reads a WSDL document and creates a lot of code to create, transport,
> and consume messages as directed by the WSDL. After this WSDL2Java
> process, the WSDL document is no longer required; it has essentially
> been compiled into a set of Java operations that obey the WSDL's
> specifications.
>
> In JAX-WS, the WSDL2Java process also creates code, annotated with
> details from the motivating WSDL document. I had assumed that these
> annotations are used at compile time to generate much of the extra
> code we see generated by the AXIS2 WSDL2Java process. Instead, I find
> that the generated Service type wants to read a WSDL file in its
> constructor (following the call chain along to
> org.apache.cxf.wsdl11.WSDLServiceFactory.create() called on by
> org.apache.cxf.jaxwsServiceImpl.initializePorts()).
>
> Why does the client need to read the WSDL file at run time? Don't the
> annotations and method signatures provide enough information to lock
> in the basic operations it must perform? Is there some way to avoid
> needing to use the WSDL file at run time?
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog