I need to create soap web service. I already have wsdl and interface and implementation (as pojo).
I am now choosing between subj.
I need frame work that will:
Work as servlet in servlet container
Require only one servlet mapping in my web.xml
Have good spring integration (because my service implementation is spring bean)
No require me to add annotations. I do not have annotations on my interface or implementation.
Spring-ws: Looks cool, but as far as I understood it forces me to deal with XML directly which I do not want to do. I want framework to deserialize message and pass it as parameter to my POJO.
Apache cxf is powerful and has spring integration, but if I use Jax-WS frontend for it I will have to use annotations, and I do not want to touch my POJO. What about simple front-end?
Metro is Jax-WS RI, so it depends on annotations heavily.
Axis2 seems to be my choice. What would you choose?
Just wanna tell what I am trying to do:
Our app connects to remote service using SOAP. They gave us WSDL, we've generated proxy classes and DTO and all this stuff is packed in jar and stored in VCS. Now I need to write emulation for this web service. And I do not want to generate new DTO.
I think Spring WS would be a good fit for you given your requirements. You do not need to deal directly with the XML. Spring will serialize/deserialize many types of objects including all of your data transfer objects. They should just be annotated JAXB entities. Check out this information: http://static.springsource.org/spring-ws/sites/2.0/reference/html/server.html#d5e1063
If you already have a WSDL you can generate your DTO objects from that WSDL. There are several tools that do this including most IDE's.
Related
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
I am working on a Spring MVC project with Spring 4.3.2 (latest at this time).
We also use Spring Security 4.1.1 and Hibernate 5.01. This back-end project is a set of RESTful API's.
Within the business login in our "services" layer, we want to call several third party SOAP Web-Services. We actually DO have the WSDL files, and a service name from these outside SOAP web-services. We do have the URL, and this URL is the location of the WSDL file, we have the username password.
I suppose this could be a standard java question on how to call/consume SOAP web-services, but since we are in the Spring world, I figure we want out code to be "Spring-ified."
I'll keep looking on the net, but most of the examples I have seen require a WSDL file we do not have at this point.
Any help would be much appreciated. Thanks!
UPDATE:
I was looking at some old code we had with Seam, JBoss, and RichFaces. There are a few API calls from Jboss/J2EE which we are removing. It looks like we had a generic SOAP proxy which took a WSDL-URL string and a QName. It looks like this old code had a FormSubmit and a FormSubmitResponse which was a class for a JAXB conversion to these objects.
So, provided I have the WSDL in a URL, and a known method name to call. That should make my problem easier.
You can generate the Web Service Stubs with Maven or Gradle (depending on what you are using)
Take a look at this example:
https://spring.io/guides/gs/consuming-web-service/
I am using XFIRE to develop soap services .
what is the other best alternative to XFIRE .
I want to replace XFIRE code from other best approach beca
You can develop web services in different ways; Apache CXF is the successor of XFIRE so perhaps it's the easiest path; there is also a migration guide . You can also using Spring-ws, but it depends if you are already familiar with spring and if you want/can adopt Spring in your project. Spring web services are contract first i.e. You start from the wsdl (or xsd in you prefer) and write the code that handle the data incoming; you can read more about this here
Spring ws is very flexible and lets you handle the whole soap body allowing even to handle some ws client mistakes (in an ws implementation I handled two slightly different version of the ws with the same endpoint).
If you are writing web services, you are already using Spring and you are not afraid to manage the whole soap body you can choose Spring WS; if you want an easy migration path (because part of your team alreay knows xfire) apache cxf is the way to go.
Evening all :)
I'm looking to create a Java web application. I envisage that it will use Spring web MVC and JSPs, however I would like to expose certain functionality as REST calls so I can create an android client.
Does spring offer anything to help me in this area? How can I keep the REST code and the web front end code separate yet not have to maintain essentially 2 versions of my application (one for the web, one for REST clients).
Not looking for spoon feeding, just some pointers of where I should start reading.
As others have mentioned, Spring has pretty good in-built REST support now. When combined with annotations, this allows really simple set-up of a RESTful API. Spring can be configured with different view resolvers, which can automatically respond with a different view of the data depending on the Accept header for example. So you could return either JSON or JSP automatically from the same data, see the ContentNegotiatingViewResolver. Your Controller and Model can then be common and implemented once, leaving the work in the View layer.
I've used this approach before to return JSON when the request was via AJAX and a JSP view built with the same data when accessed by a browser.
Jersey is a pretty nifty tool. It integrates well with tools like Spring, Guice, and Jackson to provide you a pretty seamless way to create RESTful resources.
Jersey is pretty simple, works well, and serves as the reference implementation to boot. Plus, it has some nice REST client support, much of which will probably make it into the JAX-RS spec.
In terms of marrying that with Spring MVC, I'd recommend you make sure you model your application so that you have facades (Service classes) that provide all the core functionality you need and then simply reference them as needed in your MVC code or REST code. You shouldn't be duplicating business logic
You can do this using Spring 3.0. Spring 3.0 came out with the ability to specify #PathVariables to pull values out of the URL path (previously this was not easy in Spring MVC).
You would also use #RequestMapping to specify the HTTP method(s) each method in your controller should respond to.
I've also use Spring Security to implement an API key type of functionality. This way you can restrict access to your API in a way that is easy for REST clients to implement. I had to extend org.springframework.web.filter.GenericFilterBean and add a the proper Authentication like this
SecurityContextHolder.getContext().setAuthentication(apiKeyAuth)
There's a new REST API in Spring 3.0 MVC:
http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/
http://www.springsource.org/download
Apache CXF integrates well with Spring and offers many method for exposing services. From the overview section of the CXF homepage:
CXF helps you build and develop
services using frontend programming
APIs, like JAX-WS and JAX-RS. These
services can speak a variety of
protocols such as SOAP, XML/HTTP,
RESTful HTTP, or CORBA and work over a
variety of transports such as HTTP,
JMS or JBI.
I'm creating a Spring WS client. I have a huge WSDL from a third-party company. They provide a set of classes that maps to their WSDL via the Axis' WSDL2Java. I don't want to use Axis or any dependencies from them.
Since this is a web service client, I'm free to choose any framework. My problem is how do I generate a mapping class for the WSDL without using Axis's WSDL2Java. Am I stuck with manipulating pure XML? Take note I'm using Spring WS.
Edit:
Is it true if the service provider has built their service with Axis 1, you're basically stuck with making a client that's also based on Axis 1? I read it from this answer JAX-WS client with Axis service. I thought web services are supposed to be decoupled or at least independent from the platform that it was created, allowing you to have a .Net based web service to be accessed from a Java based client and vice versa?
If you want to use Spring-WS, then your best bet is to use the wsimport tool that ships with Java 6 (or use the JAX-WS RI, if you're on Java5). This will generate JAX-WS stubs for the web service. Included in these stubs will be standard JAXB bindings for the WSDL's schema, and those can be used with Spring-WS (wsimport will generate other service stubs that you won't need for Spring-WS).
If you are only interested in generating the POJOs from the WSDL, I think you could just get the XSD from the WSDL and use XJC tool to generate only the JAXB beans. This would avoid generating useless JAX-WS stubs.