Jaxws-webservice programming

Objective:

With the gradual maturation of SOA,EAI and other architecture systems in recent years, WebService is becoming more and more hot, especially when the enterprise makes heterogeneous platform integration become the first choice technology.

Java's WebService technology is endless, the more popular are:

Axis2,spring ws and JAXWS.

I in the daily work and the past works, in the use of these webservice after the summary, compared, the final feel jaxws is the most standard, need additional third-party plug-in minimum, configure the least flexible webservice.

JAXWS is suitable for almost all WebService client calls, so a lot of giant manufacturers such as: Ibm,weblogic, etc., in their products are used to JAXWS as the standard WebService interface.

This tutorial is divided into five days for the beginner tutorial.

With this tutorial, you can get a quick start with a Java resource that doesn't have a WebService concept or written webservice, and can meet webservice applications in small to medium-sized projects.

For WebService Security, it is not available in the (beginner) tutorials and is described in detail in the advanced tutorials.

However, the real use of WebService security features, XML encryption technology is not much engineering, less, mostly http://xxx/xxxservice?userid=&password= This form of "false security" communication.

Most of our projects are run on the intranet and are well monitored and armed.

Here's how to start our tutorial.

First day

Goal:

1. Understanding Jaxws

2. Preparation before writing Jaxws

3. It all started in HelloWorld.

4. Understanding synchronization, asynchronous

First, understand Jaxws1.1JAX-WS Overview

Jax-ws2.0 is all called Java API for xml-based webservices (JAX-WS) 2.0. JAX-WS 2.0 is an extension to the Jax-RPC 1.0 specification and is a subsequent version of Jax-RPC 1.1, which was renamed to Jax-WS 2.0 shortly after the Jax-RPC 2.0 standard was released. JAX-WS 2.0 is the latest programming standard for development Web services for Java 5, which provides a new programming model and enhancements to previous JAX-RPC-style Web services. jax-ws2.0 (JSR 224) is Sun's new Web services protocol stack and is a fully standards-based implementation. At the binding layer, the Java Architecture for xmlbinding (JAXB, JSR 222) is used in the parsing layer, using the streaming API for XML (StAX, JSR 173) , and it also fully supports the schema specification.

1.2JAX-WS 2.1 Features

?? Supports SOAP 1.1 (default), 1.2

?? Support Xml/http Binding

?? Support Ws-addressing

?? Supports document/literal styles

?? Support for WS-I Basic profile 1.1

?? Support for message transmission optimization mechanism (MSG transmission optimization Mechanism,mtom)

Ii. preparatory work before writing JAXWS2.1JDKjavaversion "1.6.0_x".2.2jax-ws RI 2.1.1 in JDK 62.2.1 Jax-ws RI 2.1.1 Installation notes

The JAX-ws RIS component is downloaded as a ". Jar" file and is not intended to be used directly in the project, it is a JAXWS installation package with Java Swing as its interface.

We need to open a command-line window and enter:

After entering this command, you will get an installation interface as follows:

Next, after completing the installation you will get a directory like this:

This directory has all of the LIB packages we need to write jaxws and the tutorials that Jaxws comes with.

Three, all started in HelloWorld3.1 Building the WebService server-side project

You can see that our directory has several directories in addition to the traditional src,webcontent directory, namely:

? Build
? Wsdl
? Wssrc

Let's write our first WebService, whose name is Hello (Come on, old-fashioned, again).

Package Ctsjavacoe.ws.fromjava; Import Javax.jws.WebMethod; Import Javax.jws.WebService; @WebService public class Hello { @WebMethod public string Say (string name) { Return ("Hello:" +name); } }

Attention:

@WebService

The comment is above class, which tells the jaxws that this class is webservice.

@WebMethod

Note on the public method, this tells Jaxws that this method is a SOAP method that has two parameters, a string of input, and a string of output.

The business logic is simple, the client calls pass in a name, and the server returns a "Hello:" +name string to the client.

Now we are using Java files to generate WebService related deployment files and call interfaces.

3.2 Compiling WebService with Java class

JAX-WS 2.0 has two development processes: top-down and bottom-up. The top-down approach is to create a Web service from a WSDL file, from the bottom up to the Java class to create the Web service. The final documents of the two development processes include:

1. Sei. An SEI corresponds to a port in the WSDL webservice, which is a Java interface in Java.

2. SEI implementation class.

3. WSDL and XSD files.

Combined with the characteristics of the company's projects, we have encountered the following two kinds of situations:

1. Onsite want us to do a WebService or customer request we provide WebService interface;

2. Onsite already has a webservice, now we want to do the client integration.

Therefore, we use the server side to generate WebService through Java class, and the client generates Java call class by WSDL .

JAXWS provides us with two tools:

ü Wsgen

Primarily used for server side compilation into WebService and related WSDL files through Java classes

ü Wsimport

Used primarily for client side (caller) to compile the Java file on the calling server side via WSDL

Let's just generate the above hello, open a command window and type the following:

The-WSDL parameter represents the build WebService

-the s parameter represents where the generated. java files are placed

The-d parameter represents where the generated compiled class file is placed (this can be ignored, we compile with eclipse)

The-r parameter represents where the generated. wsdl file is generated from the. xsd file

The-CP parameter represents classpath, where Hello.class is, why is our-CP so long a path? See the path to the project compiler output directory in eclipse to find out:

3.2.1 Generated src file

OK, now we're back in the Eclipse Project, refresh the project:

See in the WSSRC directory has generated our required Java files, please manually cut (to, is cut) these files to our project "src" directory, if not cut, the next time you continue to use the directory to generate WebService class, Wsgen sometimes can not generate, but also do not error , do not know why, check a bit, may be a bug, because it will be in the subsequent jdk1.6.30up improvements.

3.2.2 generated WSDL and XSD files

Here we have two files, one is the WSDL file, this is our WebService entry, one is the XSD file, what is this?

This is the corresponding parameter in our Java method, or in other words, it is a Java bean in XML format, in the WebService world, XSD is used as a data structure description.

Now we have the service of the webservice.

3.2.3 WebService

Preparation before deployment:

The "Sun-jaxws.xml" file is created under the Web-inf directory of the project, which reads as follows:

<?xml version= "1.0" encoding= "UTF-8"?> <endpoints xmlns= ' Http://java.sun.com/xml/ns/jax-ws/ri/runtime ' Version= ' 2.0 ' > <endpoint name= ' Hello ' implementation= ' Ctsjavacoe.ws.fromjava.Hello ' url-pattern= '/helloservice '/> </endpoints>

Declare Ctsjavacoe.ws.fromjava.Hello as a Web Service.

If the Web Service is generated from WSDL, the

<?xml version= "1.0" encoding= "UTF-8"?> <endpoints version= "2.0" xmlns= "Http://java.sun.com/xml/ns/jax-ws/ri/runtime" > <endpoint implementation= "Ctsjavacoe.ws.fromjava. Hellosei " Name= "Hello" url-pattern= "/helloservice"/> </endpoints>

Modify the Web. xml file under the Web-inf directory to add the following:

<servlet> <servlet-name>Hello</servlet-name> <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class> <load-on-startup>2</load-on-startup> </servlet> <servlet-mapping> <servlet-name>Hello</servlet-name> <url-pattern>/HelloService</url-pattern> </servlet-mapping>

Declare a com.sun.xml.ws.transport.http.servlet.WSServlet for each of the webservice.

Start deployment:

1. Create a directory under Tomcat's WebApps directory called "D:\tomcat2\webapps\JaxWSSample"

2. Copy all the items under the WebContent directory under Eclipse engineering jaxwssample to this directory

3. Restart Tomcat

In IE, enter:

http://localhost:9090/JaxWSSample/HelloService?wsdl

You can see that our webservice has been generated.

3.3 Generating a Client for Java calls through the server-side WSDL3.3.1 Synchronous vs. asynchronous

Synchronous invocation , well understood, namely one back, client request to server side, Sever end immediately back to a response.

asynchronous invocation , that is, after the client invokes a server, the service side processing transaction is not immediately returned, for example, a 600MB file to the server, the server in the processing of receiving and parsing the file, the client will not immediately get a response, it will wait for a period of time, and so on, after the servers have finished processing, Notify the client again, "I'm done with it."

3.3.2 using Wsimport to generate the client

We create a new Eclipse project, just need to be a Java project, no web engineering, because we only use code to invoke:

Manually copy the server-side WSDL and XSD to the WSDL directory of the client project.

Open a CMD window and typed the following command:

wsimport-keep-d bin-s src wsdl/helloservice.wsdl

These are the commands that generate the synchronization client.

If you want to generate an asynchronous client command, you need to build a Binding.xml file in the project root directory, as follows:

<?xml version= "1.0" encoding= "UTF-8"?> <bindings xmlns:xsd= "Http://www.w3.org/2001/XMLSchema" Xmlns:wsdl= "http://schemas.xmlsoap.org/wsdl/" wsdllocation= "wsdl/helloservice.wsdl" xmlns= "Http://java.sun.com/xml/ns/jaxws" > <bindings node= "Wsdl:definitions" > <enableAsyncMapping>true</enableAsyncMapping> </bindings> </bindings>

The Wsimport command that generates the client code will then be different:

Wsimport-keep–b binding.xml-d bin-s src wsdl/helloservice.wsdl

Let's look at the code for the asynchronous call (the synchronous code is simpler than the asynchronous call, leaving everyone to do their own exercises)

The Wsimport command generates the Java SRC file that you used to invoke in the SRC directory of the Eclipse project.

Hello.java and Helloservice.java are Java files that wsimport to us to generate for client calls.

We open the HelloService file, we can see two lines:

file:/d:/workspace/jaxwsclient/wsdl/helloservice.wsdl

Change them to:

http://localhost:9090/JaxWSSample/HelloService?wsdl

There are two lines, especially the URL url= this line, do not miss the change.

We create a call class called: Helloasyncpollingclient.java file with the following contents:

Package Ctsjavacoe.ws.fromjava; Import Javax.xml.ws.Response; public class Helloasyncpollingclient { /** * @param args */ public static void Main (string[] args) throws Exception { HelloService service = new HelloService (); Hello port = Service.gethelloport (); response<sayresponse> Sayasync = Port.sayasync ("Mk"); while (!sayasync.isdone ()) { System.out.println ("isn't Down"); } try { Sayresponse callnameresponse = Sayasync.get (); String message = Callnameresponse.getreturn (); SYSTEM.OUT.PRINTLN (message); } catch (Exception ex) { } } }

Run and get the result as follows:

3.3.3 the synchronous and asynchronous

In the old Jax-RPC-based WebService programming model, asynchronous service calls are not supported, and in the latest JAX-WS WebService programming model, support for asynchronous calls to WebService is added.

First of all, let me tell you how it works, so let's not assume that the SOAP message flow from the client to the server is asynchronous in the asynchronous invocation, not that the Soap/http protocol is the same as the asynchronous call. Both the client service opens a connectin at run time, sends the request, and then receives the return, which are all in the same connection. How does this affect us? From the perspective of the client program, there is no impact, the client's programming model is defined by the WSDL messages and port types, as long as these things have not changed, request and response is not in the same TCP/IP session To send to us is not affected by, and then from the perspective of architecture and resources, the impact on us, the connection layer of resources with the application layer program running state binding is a lot of drawbacks, if the asynchronous call, the program run an exception, will cause the connection layer resources are occupied, This will greatly affect our program, stability, reliability, use of resources and performance.

Another implementation of 3.3.4 asynchronous

In the above example, a "polling asynchronous call" is implemented, and the following gives the asynchronous calling client of "callback" mode.

Because of this callback when the request is sent out, the current connection will be closed, in order to achieve the purpose of testing, add sleep, let the client program waiting for the server to return.

Callback type of client to pass in an anonymous inner class of Javax.xml.ws.AsyncHandler type, when SoapMessage arrives, Jax-WS will handleresponse this method to handle response.

The client test code is as follows:

Package Ctsjavacoe.ws.fromjava; Import Javax.xml.ws.AsyncHandler; Import Javax.xml.ws.Response; public class Helloasynccallbackclient { public static void Main (string[] args) throws Exception { HelloService service = new HelloService (); Hello port = Service.gethelloport (); Port.sayasync ("Mk", new asynchandler<sayresponse> () { public void Handleresponse (response<sayresponse> res) { try { Sayresponse response = null; Response = Res.get (); String message = Response.getreturn (); SYSTEM.OUT.PRINTLN (message); } catch (Exception e) { E.printstacktrace (); } } }); Thread.Sleep (1000); } }