CXF
CXF is implemented on the basis of xfire.
1) First of all, it is still the problem of packages. You can download the latest version of CXF at http://cxf.apache.org/download.html. Of course, I use the latest version. Next is the nonsense, build a WEB project and put it in a JAR package. We don’t choose JAR packages, put them all in.
We will see that it contains the JAR package of spring. When we need to deploy CXF as a WEB project, we need to use the spring configuration file, which will be discussed later.
Or interface class and implementation class:
@WebService public interface IReaderService { public Reader getReader(@WebParam(name="name") String name,@WebParam(name="password") String password); public List<Reader> getReaders(); } @WebService(endpointInterface="com.cxf.servlet.IReaderService",serviceName="readerService") public class ReaderService implements IReaderService{ public Reader getReader(@WebParam(name="name") String name,@WebParam(name="password") String password) { return new Reader(name,password); } public List<Reader> getReaders(){ List<Reader> readerList = new ArrayList<Reader>(); readerList.add(new Reader("shun1","123")); readerList.add(new Reader("shun2","123")); return readerList; } } Except for adding annotations, these two classes are the same as those mentioned yesterday. I won’t talk about it here. For explanations of the annotations, you can take a look at the JAVAEE documentation. But it should be easy to understand according to the meaning.
Next is JAVABEAN, or the Reader class:
public class Reader{ private static final long serialVersionUID = 1L; private String name; private String password; public Reader(){} public Reader(String name,String password) { this.name = name; this.password = password; } //Get/Set method omits public String toString(){ return "Name:"+name+",Password:"+password; } } The above has been written.
2) Do we want to use it as a WEB project? Don't worry, don't use it now. CXF comes with a lightweight container service, which is equivalent to spring itself providing IOC containers. We can use it to test whether our deployment was successful.
Let's just take a test class:
public static void main(String[] args) { System.out.println("Server is starting..."); ReaderService readerService = new ReaderService(); Endpoint.publish("http://localhost:8080/readerService",readerService); System.out.println("Server is started..."); } Very simple. It's OK to directly publish the address and then specify the interface or class. I am using classes here, but try to use interfaces. After all, interface-oriented programming is the real object-oriented idea.
Let's start to see the results:
We see that the startup has been completed, and then start the browser to see if it is successful.
Directly enter http://localhost:8080/readerService?wsdl in the browser, we can see:
It generates the wsdl file we need, indicating that we have successfully deployed it.
3) After the deployment is successful, we will call it. Its call is also quite simple. It is similar to xfire. You can get the interface and then call the method like the local class.
public static void main(String[] args) { JaxWsProxyFactoryBean factoryBean = new JaxWsProxyFactoryBean(); factoryBean.setServiceClass(IReaderService.class); factoryBean.setAddress("http://localhost:8080/readerService"); IReaderService readerService = (IReaderService)factoryBean.create(); Reader reader = readerService.getReader("shun","123"); System.out.println("Reader:"+reader); } It's very simple here. You can get a factory class, then directly set the interface and address and create to get the corresponding interface. Like xfire, you also need to define the interface prototype first, otherwise these calls will have no way to start.
We run to get the result:
No problem, it is consistent with the results we expected.
4) But in many cases, we do not want our webservice and our application to separate two servers, but want them to be in the same container, tomcat or JBOSS or other, so we must deploy the webservice we completed earlier through WEB.
Note that we need to use spring definition files here.
First look at web.xml:
<?xml version="1.0" encoding="UTF-8"?> <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="WebApp_ID" version="3.0"> <context-param> <param-name>contextConfigLocation</param-name> <param-value>WEB-INF/beans.xml</param-value> </context-param> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <servlet> <servlet-name>CXFServlet</servlet-name> <servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>CXFServlet</servlet-name> <url-pattern>/webservice/*</url-pattern> </servlet-mapping> </web-app>
It's very simple here, just specify the spring listener and the corresponding configuration file path, and specify the CXF interception method.
Next, take a look at beans.xml:
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jaxws="http://cxf.apache.org/jaxws" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd"> <import resource="classpath:META-INF/cxf/cxf.xml" /> <import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" /> <import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" /> <import resource="classpath:META-INF/cxf/cxf-servlet.xml" /> <jaxws:endpoint id="readerServicce2" implementor="com.cxf.servlet.ReaderService" address="/readerService2" /> </beans>
It's very simple here, just define a webservice through jaxws:endpoint. The implementor is the processing class of the webservice, and the address is its access path, similar to the readerService we wrote earlier.
At this time, we can deploy it to tomcat and can be accessed directly through http://localhost:8080/CXFWebservice/webservice/readerService2?wsdl.
Some friends will ask why the URL you visited this time is different from the previous one. In fact, the previous access address is defined by ourselves, and the webservice address here is configured in the configuration file and is deployed through a web project. The project name is needed here, and we configured the url-pattern as a webservice in CXFServlet, so the final URL is the same as above.
We can see the effect:
This proves that our deployment was successful.
You can use the previous test class to test again. Note that you need to modify the address to the URL we post.
CXF is a bit more concise than xfire. Although it adds some annotations, these are innocuous. It just concentrates the information in the previous services.xml into the class, which is more convenient to maintain. However, this is still a matter of opinion. Some people like configuration files, while others don't. In addition, the call method of CXF is more concise, and it has a smaller code volume than xfire, which is a major improvement.
Some friends have some problems during the construction process, so they are exempted from replying one by one. The code is released here. Friends in need can download it.
All packages in the lib directory are not put in, just put all packages in cxf.
Note: The IDE used is idea, and the file structure is not common to eclipse. If you need to use it under eclipse, you can directly copy the code and files to the newly created project in eclipse.
Jersey
Let's take a look at its basic usage.
Let’s take a look at a project. Before starting the project, you should download the package yourself: https://maven.java.net/content/repositories/releases/com/sun/jersey/To run the example, you need to download both server and client. Of course I don't want to find so many, so I can directly download this zip package. https://maven.java.net/service/local/artifact/maven/redirect?r=releases&g=com.sun.jersey&a=jersey-archive&v=1.10&e=zip
1) Just do JAVABEAN
@XmlRootElement public class Reader implements Serializable{ private static final long serialVersionUID = 1L; private String name; private String password; public Reader(){} public Reader(String name,String password) { this.name = name; this.password = password; } //Omit the Get/Set method public String toString(){ return "Name:"+name+",Password:"+password; } } A tag is used here, which represents the type when it returns, that is, this Reader class can be used for XML return.
2) If you want to use a service class, you no longer need to interface like CXF and xfire in the past. Just use a class directly.
@Path("/readerService/{name}/{password}") public class ReaderService { @GET @Produces(MediaType.APPLICATION_JSON) public Reader getReader(@PathParam("name") String name,@PathParam("password") String password) { return new Reader(name,password); } public static void main(String[] args) throws IllegalArgumentException, IOException, URISyntaxException { HttpServer server = HttpServerFactory.create("http://localhost:8080/"); server.start(); } } At this time, several tags were used. Path believes that friends who have used springMVC should know this way of writing, which is URL matching. If you are not clear, you can go and have a look first. The Get tag indicates that this method can only be accessed through the Get method, while Produces indicates the generated result, which means that the system will enclose the Reader object into a JSON result and return it.
It doesn't matter if you don't understand, you can understand it after a while.
And at this time there is a main method, I believe there are big questions. This is a lightweight internal container provided by jersey. It can be temporarily used for us to debug, but it is definitely not possible to use this in real use.
3) Let's write a test class
public class ReaderClient { public static void main(String[] args) { Client client = Client.create(); WebResource resource = client.resource("http://localhost:8080/readerService/shun/123213"); Reader reader = resource.get(Reader.class); System.out.println(reader); } } Very simple code, you should understand it. A client object, requests a webservice, returns a resource, and then the resource directly calls the corresponding method. Of course, this method is matched through our URl.
Here we will first test it with a lightweight service that comes with it. Run ReaderService directly, which contains a main method. After running, we run ReaderClient and we can see that the result is:
The result is correct.
Of course we don’t want to use the lightweight service that comes with it as our server. We need to put it on the same server as our project, such as tomcat, jboss, etc.
4) Of course, web.xml is indispensable for WEB projects.
<?xml version="1.0" encoding="UTF-8"?> <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="WebApp_ID" version="3.0"> <servlet> <servlet-name>Jersey Web Application</servlet-name> <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>Jersey Web Application</servlet-name> <url-pattern>/rest/*</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file>index.jsp</welcome-file> </welcome-file-list> </web-app>
At this time, all the rest path specified will be intercepted by jersey.
We deploy to tomcat and start it and then re-run the readerClient. Note that we need to modify the resource path first:
WebResource resource = client.resource("http://localhost:8080/jerseyWebService/rest/readerService/shun/123213"); My project name is jerseyWebService, please modify it according to your project name.
After modification, we re-run it, and the results are as follows:
Consistent with the above results, it means that the deployment effect is the same and is also correct.