Develop Reference

How to implement SOAP Endpoints that receive SOAP XML (SAAJ?) Instead of generated objects using CXF

We have currently implemented SOAP endpoints with CXF (Spring Boot). In accordance with the contract-first approach, we provide a WSDL, generate Java objects, and services from it (cxf-codegen-plugin) and finally implement the service interface.
This is all very nice and simple, but we only need the SOAP XML or the corresponding DOM tree. Not only is the conversion to Java objects unnecessary, we also have to convert them back to XML and lose some information from the original XML.
As far as I understand is SAAJ (SOAP with Attachments API for Java) exactly right here, or am I missing something? At most all resources about SAAJ are quite old and "low level". I cannot find good resources for that kind of approach.
In addition, we want to implement new services as microservices soon and are currently reviewing Quarkus and Apache Camel. However, I cannot find a (simple) way to create corresponding endpoints from the WSDLs, via which we then receive the SOAP message as plain XML / DOM tree.

In jax-ws, message-level access can be accomplished on the server side using web service Provider-based endpoints, and on the client side using Dispatch clients.
A web service Provider-based endpoint offers a dynamic alternative to the Java service endpoint interface (SEI)-based endpoint. Unlike the SEI-based endpoint that abstracts the details of converting between Java objects and their XML representation, the Provider interface enables you to access the content directly at the XML message level—without the JAXB binding. web service Provider-based endpoints can be implemented synchronously or asynchronously using the javax.xml.ws.Provider or com.sun.xml.ws.api.server.AsyncProvider interfaces, respectively.
See https://cxf.apache.org/docs/provider-services.html for details

How to expose EJB JAX-WS web method to receive object of commonj.SDO DataObject type

I'm almost new to web services in Java.
Our company has previously used IBM Process Server to handle the interactions between SCA objects. Due to some reasons we've decided to give up IBM Process Server and therefore we started to migrate our current integrations to EJB.
Just to make myself more clear I've attached a simple schema describing my current task. This is a process deployed at IBM Process Server:
I need to develop an EJB, which also acts as a JAX-WS web service and receives an SDO DataObject from the JAX-WS client service, then makes some additional logic and sends the SOAP-request to another web service.
I'm totally don't know how to make my EJB receive a DataObject via SOAP. I have a WSDL-file, describing SOAP request and response formats.
I also found an article, describing the way to solve this using IBM RAD JAX-RPC webservice from a WSDL with an SDO facade, but the article seems to be outdated.
Is there any way to create the service without using JAXB-bounded POJOs, but with SDO? In case of no, how to handle it using JAXB in a proper way? Thanks in advance.

Solved!
During my searchings I figured out, that it's neccessary to generate a bean skeleton, change all the web methods signatures to receive and return JAXB-binded POJOs, generated from WSDL and then transforming it to Data Objects if needed.
JAXB takes care of the all marshalling/unmarshalling staff. I just needed to RTFM a little bit.

Using webservices with javax.ws or javax.jws

I'm starting to choose a way to create my webservice, so i found 2 ways to do it:
1) Using the package javax.jws, with annotation #WebService:
#WebService(...)
public class MyServiceImpl {
2) The other way is using javax.ws, with annotation #Path:
#Path("/MyService")
public class MyServiceImpl
In my understand using the second solution is more simple, because when i need to create the Client i just need make a HTTP call (GET/POST). Using the first solution i need create a WSDL client, more complex solution.
So, I would like to know which is the advantage in use FIRST SOLUTION.

The SOAP/WSDL style is useful when a formal contract must be established to describe the interface that the web service offers.The Web Services Description Language (WSDL) describes the details such as messages, operations, bindings, and location of the web service.
Also the SOAP/WSDL style is useful when the application architecture needs to handle asynchronous processing and invocation (e.g. using JAX-WS the assynchronous clients can be created).
The disadvantages of SOAP/WSDL style are
its complexity: tools are required to create a client
heavier on Bandwidth : SOAP requires a heavy XML wrapper arround each request or response
complicated security rules
The advantages of REST style are
simplicity: REST client can be accessed from any browser (however, this is only true for GET method. Data creation request requires also the XML wrapper).
lighter on Bandwidth : data on the wire are usually bare xml elements (not wrapped within the <Envelope><Body> tags).
REST application security rules can be setup using the http standards: the administrator (or firewall) can discern the intent of each message by analyzing the HTTP command used in the request.
For example, a GET request can always be considered safe because it can't, by definition, modify any data.
The disadvantage of REST style is that it still doesn't cover all business requirements
There is no common standard accepted yet for the formal REST service description
REST requests (especially GET method) are not suitable for large amount of data
REST doesn't cover all web services standards, like Transactions, Security, Addressing, Trust, Coordination,

ReST webservice client - generate from WSDL or not?

I've some confusions about ReST clients and need a bit of help.
For ReST, does the service provider give WSDL document or not? If not, how does the client will know what kind of JSON data to expect? When I invoke the rest client, I will recieve the JSON/XML response in a string format which I'll need to convert it into a Java object(or Javascript, if using on client side) to do any meaningful tasks with the response. So it seems like I, as a client developer, need to know the WSDL or the Schema definition so that I can build a java object similar to the JSON response I'm expecting. But if you go by this answer, generating a client class based on the service definition flies directly in the face of ReST fullness. If that is the case, how do I go about creating my client code?

WADL/Web Application Description Language is not a standard but is gaining popularity for REST APIs contract definition.
The Web Application Description Language (WADL) is a machine-readable
XML description of HTTP-based web applications (typically REST web
services).1 WADL models the resources provided by a service and the
relationships between them.1 WADL is intended to simplify the reuse
of web services that are based on the existing HTTP architecture of
the Web.1[2] It is platform and language independent and aims to
promote reuse of applications beyond the basic use in a web
browser.

For documentation:
https://github.com/wordnik/swagger-core/tree/master/modules/swagger-jaxrs
For client code:
https://github.com/wordnik/swagger-ui
You integrate the library and annotate your resources and online documentation is generated on the fly.
You also need a client for which you can integrate the ui.
The dynamically generated REST client looks something like this:
http://petstore.swagger.wordnik.com/

How to call Java soap services thorough ajax in JqueryMobile framework

I have started working on web application using jquery touch. My web services is written in soap and I want to call from my application. Can you suggest me how should I move ahead.
Is it possible to call from ajax?

While many people thinks that managing the complexity of SOAP in a JavaScript environment would be counter-productive, it could nevertheless be done, in particular if you are familiar with SOAP web-services and want to avoid the need to learn another middle-layer framework; a library that I would suggest is Apache-CXF support for JavaScript.
The CXF JavaScript client library is indeed a code generator which (with some limitations), in its easiest form, wsdl2js, gets a wsdl file and generates JavaScript
contructors - for an service
methods - for any service operation, and
objects - for any web service complex element/type
which can be directly called in your scripting. Other available tools generate the javascript code starting with the Java code server-side implementation (java2js), or on-the-fly (dynamic javascript).
Pros:
leverage a component of a widely used library for web-services implementation (CXF)
avoid another layer in the middle
easy to use (run the tools against the wsdl, load the generated sources)
Downsides:
client knows nothings about WS urls and ports; you need the URL at which the ws ranswers and thats'it
as a code generator, the JavaScript client generator is parallel to JAXB or JAX-WS. It defines a mapping from an abstract model of a web service to JavaScript objects. Unlike JAXB and JAX-WS, there is no committee that has standardized a 'JavaScript binding.' The CXF binding may not be to everyone's tastes.
Soap 1.1 only
No Authentication support

Using soap from the browser is technically possible, but a very bad idea. You'll spend all your time fighting to get the soap protocol to work correctly and you'll miss all the benefits of soap.
A much better approach would be to build a back end for your new web application using the framework of your choice, eg. J2EE, .Net or any other. All those platforms have nice soap libraries that will do the work for you. Then you will either generate the html pages on server (old school web site) or use a static page and expose the data as a JSON rest API (modern single page app).
In summary: soap is good for communicating between servers, terrible for communication with the browser.