Enthuware

javax.xml.ws.Service has two create static methods:
1. static Service create(QName serviceName)
2. static Service create(URL wsdlLocation, QName serviceName).

Option 3 can be a correct option.

Hi Himai,

This question is talking about a WebServiceProvider implementation. When you create a WebServiceProvider implementation then there won't be any WSDL published by JAX-WS. (just try and see). That is why option 3 is not a correct option.

Regards,
Frits

I can see why a @WebServiceProvider-annotated web service cannot auto-publish a WSDL.

But I'm just curious about the @WebServiceProvider-annotated 'StringProcessor' ('implements Provider<...>') example given by Ivan's notes.

The example starts with BOTH a WSDL and the implementation code for the web service. (From here, client artifacts can be generated from the WSDL, including the service & proxy types that can be easily used to call the web service.)

From the point of view of the java developer of the web service, in practical terms, does it mean he created the code AND the WSDL by hand separately? (It's neither WSDL-first nor Java-first, but both!) ... I'm looking at how this kind of 'approach' can be done in actual practice, because I find it kind of 'weird' to have this scenario of a @WebServiceProvider and a WSDL coming together.

The example starts with BOTH a WSDL and the implementation code

Yes, that won't be done in real-life situations. I guess he used the WSDL from a Java-First implementation. More logical is to use the SAAJ 1.3 API in low-level SOAP implementations.

There is something the literature calls meet-in-the-middle approach where you have an existing WSDL and existing code, but I haven't seen that in real-life though.

In our company we had once a couple of shifts: we started off from WSDL-first, shifted to Java-First and ended up with WSDL-first. We had to make a back-end implementation where the front-end group hadn't started yet (and they didn't know what the interface should look like). The back-end group started writing a WSDL by hand, so I adviced them to shift to Java-first as we were the one's who were defining the interface. It is much easier to use Java-first in that case (just try to write a nice WSDL by hand...).

After some time, when the front-end group started working we run into the problem that it is difficult (let's say almost impossible) to add restrictions to the Java classes so that these restrictions would end up in the WSDL. All validation logic ended up in Handlers on the back-end side, where you would prefer to validate against the WSDL in the front-end before you would invoke the WebService (better choice for performance, and simpler validation logic in the front-end) This made us decide to shift again to WSDL-first (using the generated WSDL from Java-first).

Regards,
Frits

hi
the explanation for option 3

The Service instance should be created only with the serviceName:Service service = Service.create(serviceName);

is not enough.
it does not say why.
After clicking [Discuss], it makes sense that "WebServiceProvider" does not publish wsdl.
maybe the explanation should say,

The Service instance should be created only with the serviceName:Service service = Service.create(serviceName);. WebServiceProvider does not publish wsdl. Service.create(url,serviceName) will not work.

Good point, added that to the explanation!

Regards,
Frits

Hello ,

There is an issue at discuss button.
I came from below question at test number 3

enthuware.ocejws.v6.2.18
"

Which methods are exposed by the following WebService?

@WebService (endpointInterface="LogService")
public class LogServiceImpl {
private String logR(String msg) {
System.out.println(msg);
return msg;
}
public String logN(String msg) {
System.out.println(msg);
return msg;
}
... and all the method implementations of the methods defined in the SEI ...
}
and the SEI

@WebService
public interface LogService extends LogSuper{
@WebMethod
public void log(String msg);
}
public interface LogSuper extends LogSuperSuper {
public void logParent(String msg);
}
public interface LogSuperSuper {
public void logSuper(String msg);
}


"

Yes, we know about this issue. The problem is in the Forum software.

Just post your question in this thread.

Regards,
Frits

Hallo Frits,

the first antwort says that:

All @WebMethod annotated methods.

is wrong.

The Explanation is:

A private method (i.e. logR()) cannot be exposed.

But logR isn't private...A typo?
If it were private would @WebMethod be accepted? I expect a compile time Exception or something like that...

Thank you!
Regards

Fabio

Hi Fabio,

But logR isn't private...A typo?

Yes, that is a typo, corrected it, thanks!

If it were private would @WebMethod be accepted? I expect a compile time Exception or something like that...

It is accepted (just try it yourself) but ignored because the method is private.

Thanks again for your feedback!
Frits