Recieve Soap Messages

[mnouwens]

In Wildlfy we have a service like:

@ServiceMode(Service.Mode.MESSAGE)
@default
@WebServiceProvider(serviceName = "soapreceiverservice")
public class MessageParsingService implements Provider {

  @Override
public SOAPMessage invoke(final SOAPMessage request) {

//Do Stuff.
}

}

What would be the quarkus equivalent?

Thanks

[shumonsharif]

Hi @mnouwens The JAX-WS Provider interface is currently not supported by the extension. However, assuming you are able to convert to the SEI method, and depending on your specific use case, you may be able to access the CXF SoapMessage in an SEI @WebService implementation using something like the below.

Message message = PhaseInterceptorChain.getCurrentMessage();

[mnouwens]

What do you mean With SEI?

The service is being called by an third party product so we are not able to change the content.

Can you provide a small example?

Thansk a lot.

Marteijn

[shumonsharif]

The JAX-WS API provides two different service endpoint implementations types: the standard service endpoint interface (SEI) and the Provider interface for services to work at the XML message level. You can only use one or the other, ie. either the @WebServiceProvider or @WebService annotation. There's a lot of JAX-WS content on the web regarding both approaches.

You can read about the CXF based SEI approach here, and the CXF based Provider approach here.

A meaningful example will be difficult to put together without understanding what you are doing with the SOAPMessage request and response objects, as these are low-level objects that may possibly expose methods that may not have direct equivalents in the SEI approach. My suggestion would be that you review the CXF links, and if you still need some help with an example, I can attempt to put something together, but it will likely take some time.

[mnouwens]

Based on your remark on why we needed to work on this low level. I started wondering. Why would a supplier implement something so weird. After some digging I found the wsdl.

And we know how to implement that :-)

So problem avoided/solved.

[shumonsharif]

Awesome, that's great news; glad you found the WSDL, that definitely simplifies things!

[Skrrytch]

As far as I understand, the question is whether I can receive plain SOAP xml (provider service) instead of having to create Java objects (SEI), right?

We currently have the requirement to be able to receive, map (with XSLT) and forward the SOAP content (XML) like in a messaging broker. A conversion into Java objects is unnecessary and not desired. It's a pity that this service providing not (yet?) supported in Quarkus.

By the way: With the SEI approach we get a slightly different generated endpoint WSDL from the original WSDL.

Therefore intercepting the XML message in a phase interceptor is a work around but a weak one ;-)

---

I have tried to register a provider service endpoint in Quarkus with CXF but it is not accessible

GreetingEndpoint wsImpl = new GreetingEndpoint();
Endpoint endpoint = Endpoint.create(wsImpl);
Map<String, Object> properties = new HashMap<>();
properties.put(Endpoint.WSDL_PORT, new QName(NAMESPACE, PORT_NAME));
properties.put(Endpoint.WSDL_SERVICE, SERVICE_QNAME);
endpoint.setProperties(properties);

if (!(endpoint instanceof EndpointImpl)) {
    throw new IllegalStateException("Created endpoint instance not of expected type "
            + EndpointImpl.class.getName() + " but was " + endpoint.getClass().getName());
}

EndpointImpl endpointImpl = (EndpointImpl) endpoint;
endpointImpl.setWsdlLocation(WSDL_URL);
endpointImpl.setAddress(SERVICE_URL);
endpointImpl.setPublishedEndpointUrl(SERVICE_URL);
endpoint.publish(SERVICE_URL);

Depending on the SERVICE_URL I have the following problems:

• 404 when using releative path like "/endpointPath"
• Exception ("Cannot find any registered HttpDestinationFactory from the Bus.") when using absolute url like "http:/llocalhost:8080/endpointPath"

Is there really no way? It seems that there is just one little step to go .... Or am I missing important internal stuff that prevents CXF/Quarkus from supporting provider services?

[shumonsharif]

As far as I understand, the question is whether I can receive plain SOAP xml (provider service) instead of having to create Java objects (web service), right?

I don't entirely agree with this viewpoint. JAXB objects are a small piece of the overall picture. While JAXB objects are not used in the JAXWS Provider interface, we'd need to support the following object types in order to integrate the Provider interface in this extension.

• javax.xml.transform.Source
• javax.xml.soap.SOAPMessage
• javax.activation.DataSource

For reference, you can see more details here: https://cxf.apache.org/docs/provider-services.html

We currently have the requirement to be able to receive, map (with XSLT) and forward the SOAP content (XML) like in a messaging broker. A conversion into Java objects is unnecessary and not desired. It's a pity that this service providing not (yet?) supported in Quarkus.

While this community extension is widely leveraged by many - it would actually be great to see more contributions to the project.

Is there really no way? It seems that there is just one little step to go .... Or am I missing important internal stuff that prevents CXF/Quarkus from supporting provider services?

I don't believe it's as easy as it may appear on the surface level, but definitely please feel free to submit a PR if you can dedicate some time to this.

[shumonsharif]

• Exception ("Cannot find any registered HttpDestinationFactory from the Bus.") when using absolute url like "http:/llocalhost:8080/endpointPath"

FWIW, you may have some luck with adding the following dependency, it may take care of this error.

    <dependency>
      <groupId>org.apache.cxf</groupId>
      <artifactId>cxf-rt-transports-http-undertow</artifactId>
    </dependency>

But keep in mind that when you use Endpoint.publish I don't believe you will be able to leverage any of the numerous Quarkus capabilities, and you may be limited to running in JVM node. In fact, I believe you don't even need to use this CXF extension when you use Endpoint.publish, the jaxws-api and jaxws-rt dependencies may be all you need.

[Skrrytch]

Thanks alot. I know that this is not a support forum for any kind of soap stuff :) The problem with all those nice high level APIs is that we forget to know and use low level APIs ...

Your suggestion does really work and I see why I do not need Quarkus CXF for this kind of service. I hesitated to use this dependency because I wasn't sure whether it would work in Quarkus. Sticking with JVM may be acceptable I think.

P.S. Of course I use java objects to receive SOAP data and payload in provider services but they do not depend on a wsdl2java generator like SEI.

[shumonsharif]

Hi @Skrrytch @mnouwens I just introduced support for JAX-WS Providers. It will be in the next release, within the next day or two.

I realize it was a while ago, but in case you still have a need for it, please feel free to test and let me know in case of any issues.