Can I have the same service having simultaneously both REST and SOAP interfaces?
I currently have a REST service implemented in Java using EJB and Jersey:
import javax.ejb.EJB;
import javax.ejb.Stateless;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
#Stateless
#Path("test")
public class TestExternalService {
#EJB
private com.test.ejb.db.TestService testService;
#GET
#Path("/status")
#Produces("text/*")
public String status() {
return "ok";
}
}
How can I make changes in my class to also implement a SOAP interface?
Basically, Jersey is JAX-RS implementation, so you cannot have SOAP web-services here. You could take Apache CXF, which is implementation for both JAX-RS and JAX-WS and you would be able to combine your web-services in both architectural styles.
Here is a solution to expose an implementation as both rest and soap web service. Similar to what zack suggested in the comment.
You may have to do some refactoring if you already have the service supporting jax-rs as you pasted above.
The solution is to have two sets of interfaces and implementation. One supporting jax-rs and one jax-ws. You can still have your processing done in the ejb.
Example,
Do not annotate your ejb (say EService) with jax-rs.
Have an interface X and Ximpl class to support restful calls. This will support jax-rs, so basically be annotated with jax-rs. Ofcourse, this can still use jersey. Ximpl will reference the EJB EService and delegate the processing to it.
Have an interface Y and YImpl to support soap based calls. This will support jax-ws, so will be annotated with jax-ws. Yimpl will reference the EJB EService and delegate the processing to it.
If you have a web deployment descriptor, in your web deployment descriptor define different servlets and mapping for rest and soap.
Related
I have api.jar with interfaces annotated with Spring annotations like org.springframework.web.bind.annotation.GetMapping and so on. This api is used as a maven dependency. I would like to generate Rest client basing on given interfaces or use this interface as a source for some kind of proxy object to consume rest endpoints without manual implementation (restTemplate object..)
I have been given a Java application to maintain and a little confused as to what type of java application it is. The application is quite complex with numerous packages, uses Hibernate and runs on Tomcat.
There is NO servlet class and so no doGet or doPost methods etc and no front end in JSP for example, however it uses javax.servlet.http.HttpSession and in the tomcat\lib folder there is an "servlet-api.jar". Upon looking at the Java classes there is one in particular with web service and web method annotations so is the class with web service end points but there is no "MAIN" method in this class. Also there is a WSDL file in the WebContent\WEB-INF\wsdl location
I have determined that it uses the javax.servlet.http.HttpSession for controlling the session and uses session parameters and some of the imports for the Java class that has the web service annotations are;
import javax.annotation.Resource;
import javax.jws.HandlerChain;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;
import javax.servlet.http.HttpSession;
import javax.xml.ws.WebServiceContext;
import javax.xml.ws.handler.MessageContext;
I have done work with servlets and java web services before but I suppose the question I am asking is - is this a web service application using a servlet api for the HTTP session aspects or is this a Java servlet using JWS components to provide web service end points?
Here is examples of two of the annotations in the relevant Java class;
#WebService(targetNamespace = *manager won't allow me to show anymore of this*
#WebMethod
public String findPrice( ......
I created a rest webservice using Jax-rs 2. It uses the AsyncResponse to return the response. How I can add CORS support to my rest web services ? So any one can access it with out any cross domain issues ?
My sample rest webservice is as follows
#GET
#Path("/test")
#Consumes(MediaType.APPLICATION_JSON)
#Produces(MediaType.APPLICATION_JSON)
public void test(#Suspended AsyncResponse asyncResponse){
asyncResponse.resume(Response.ok().build());
}
Thank you!
RestEasy has the CorsFilter. But since you are using Glassfish, you are most likely using Jersey. Jersey doesn't seem to have any such class we can use. That said, the CorsFilter for RestEasy implements ContainterRequestFilter and ContainerResponseFilter (Note, this is a Jersey 2.x (JAX-RS 2.0) feature).
See Filters and Interceptors for more information
You can also see the source code for the CorsFilter here at GrepCode. You'll basically want to implements something similar to that class, then register it is as a singleton with the application.
I was reading this enter link description here. Specifically, this section is confusing to me.
Web Service Clients
A web service client can access a Java EE application in two ways. First, the client can access a web service created with JAX-WS. (For more information on JAX-WS, see Chapter 19, Building Web Services with JAX-WS.) Second, a web service client can invoke the business methods of a stateless session bean. Message beans cannot be accessed by web service clients.
Provided that it uses the correct protocols (SOAP, HTTP, WSDL), any web service client can access a stateless session bean, whether or not the client is written in the Java programming language. The client doesn’t even “know” what technology implements the service: stateless session bean, JAX-WS, or some other technology. In addition, enterprise beans and web components can be clients of web services. This flexibility enables you to integrate Java EE applications with web services.
A web service client accesses a stateless session bean through the bean’s web service endpoint implementation class. By default, all public methods in the bean class are accessible to web service clients. The #WebMethod annotation may be used to customize the behavior of web service methods. If the #WebMethod annotation is used to decorate the bean class’s methods, only those methods decorated with #WebMethod are exposed to web service clients.
This is what I am getting from the above article context: Highlighted the text with italics. Points bellow are in order of the highlighted sentences in the text above.
"First, the client can access ..." Means: Any clients that access the Web Services created with JAX-WS. (Of course, any web service created with any tools/technologies can be accessed by any client.).
"Second, a web service..." Means: JAX-WS Web Service can access stateless Session beans.
"any web service client can access" How? Can a .NET Web Service client access a Stateless Session Bean? Or I am understanding this incorrectly?
"A web service client accesses a stateless session bean ..." I am not getting this. Does it mean A Web Service Client accessing the another web service created using Stateless Session Bean?
In order to your points:
The implementation class is not a EJB.
#WebService public class MyService {
#EJB MyBean ejb;
#WebMethod
public void doSomething() { ... }
}
The implementation class is also a EJB.
#Stateless #WebService public class MyServiceBean {
#WebMethod
public void doSomething() { ... }
}
.NET client can access to EJB by:
#Stateless #WebService public class MyServiceBean {
#WebMethod
public void doSomething() { ... }
}
Explanation of 2. The endpoint implementation class is, e.g., MyServiceBean.
I have following java class and have published a wsdl for it, my question is that is there anyway to have different webservice classes and publish a single wsdl? I mean another seperate class to this one with number of methods or I have to have a webservice class as the main class of the application to keep all the webmethod methods and generate the wsdl from that?
package com.Services;
import javax.jws.WebService;
import javax.jws.WebMethod;
#WebService(name = "Hellos", targetNamespace = "http://localhost:8081/Mywebservice2/services/Hellos")
public class Hellos {
#WebMethod
public Customer[] mycustomers() {
.....
}
#WebMethod
public String Receiver(String name){
....
}
}
Exactly, that should be the way you should design your application. you should have one consolidated java file and that should be exposed. Clients should be given multiple end-points.
WSDL correspond to your service and literally each public method corresponds to a service. You can write many classes and methods but they will not be part of your wsdl if methods are private.
If you using any IDE plugin then it asks you during service creation what all public methods you want to be exposed to outer world. So in one java project you can have as many classes or methods you want. Finally when converting your project into web service you can decide which all methods can work as end point/service and then these will be part of your WSDL.
The tool wsgen since JDK 1.6 for generate de WSDL file takes only one Service Endpoint Interface or SEI.
wsgen [options] <SEI>
You can read that:
The wsgen tool generates JAX-WS portable artifacts used in JAX-WS web services. The tool reads a web service endpoint implementation class (SEI) and generates all the required artifacts for web service deployment, and invocation
And:
Note that you do not have to generate WSDL at the development time as JAXWS runtime will automatically generate a WSDL for you when you deploy your service.
In another hand, WSDL 1.1 supports having multiple services in a single WSDL file, but these services shares types. In that case, it's prefer put all in one service.