Java programming uses the Xfire framework to invoke the WebService program interface _java

Java call WebService, when you first contact you will feel it is a nightmare, especially without a unified standard implementation, compared to the. NET those steps can be completed WebService implementation, we look at the implementation of Java is really sad ah. But it is sad, we still have to finish. Java is also not lack of a better implementation, such as XFIRE,JERSEY,CXF. Here we'll look at the implementation of Xfire.

1 First of all, of course, to the next bag, this ordinary people know. Http://xfire.codehaus.org/Download can go down here, can under all also can under distribution. But the advice or all, lest a bunch of strange problems make you have no confidence.

The bag's down, so what? Put it in the project. Seemingly nonsense, but a lot of people just don't know what to do with the down.

Build a new project, compare mine is Xfirewebservice, this is certainly a Web project.

I'm here to put all its bags in here. After all, we write examples, there is no need to pick, casual point, if you want to see the exception information of the friend can not put all in, slowly joined, and later encountered errors or exclusion, but we do not do so here, After all, the general lack of what kind of exceptions are not ugly, we can exclude themselves.

2 We first look at the difference between Xfire and other WebService frameworks, the biggest difference is that it requires an interface, and if you need to use Xfire to invoke the corresponding WebService must know the definition of the interface, it feels a bit limited. But in addition to this, Xfire calls WebService, which is quite handy, just like invoking a local method. Let's take a direct look at the example:

The first is the most important interface:

Public interface Ireaderservice {public 
  Reader getreader (String name,string password); 
  Public list<reader> getreaders (); 
} 
 There are interfaces, of course, there are implementation classes, otherwise the interface is meaningless. Public
class Readerservice implements ireaderservice{public 
  Reader getreader (String name,string password) { C7/>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 
  } 
} 

Also look at the Javabean,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; 
  } 
    The Get/set method omits public 
  String toString () {return 
    "Name: +name+", Password: "+password; 
  } 
   
}" 

Note that our reader class here implements the Serializable interface, why? Here, first we need to understand the principle of webservice, for Java, if we need to upload objects on the Internet, many people will of course think of serialization, right, this is serialization, because we need to pass the reader as an argument. This is mandatory in previous releases, otherwise there will be an error, but now the latest version (in fact, the latest is also 07 years, because Xfire has stopped the development, the Apache merged into the CXF project, which we later said) no longer need, as to what way to achieve, We do not delve here for the time being, because it has been merged into CXF, if we want to study in depth, we should learn cxf better.

3 When we finish the above interface and JavaBean, many people will ask, I see a lot of WebService will have WSDL file, then how do you come here? Before we talk about this, let's talk about what WSDL is. Perhaps a lot of companies provide the interface is still just an HTTP address, return XML such a format, we are also. There is one advantage and one disadvantage. The advantage is that we are less difficult to develop, but the disadvantage is that we need to provide users with a stack of documentation, each return of the XML tag is what the meaning, this is not what, but is more annoying. And webservice, the disadvantage is that we developed a little bit more, and the advantage is that we do not have to write so many documentation, because there is a unified description, called WSDL, this is the WebService documentation, is unified, no matter what language is the same, So there is no question of who can not understand.

And here, when we're done with the Xfire, it can help us generate the WSDL file.

The question is how to deploy, this is actually simple. We create a new folder in the SRC directory meta-inf, and then build it a word folder Xfire, inside the file services.xml. The following structure follows:

Some people will ask why it was built into the SRC directory, but it's not a rule to be built here, but because we need to have the development tools help us deploy these files, so we put it here and eclipse can help us deploy to Tomcat or other containers. Note that the folder hierarchy of this file is fixed and cannot be modified.

Let's just take a look at Servics.xml:

<?xml version= "1.0" encoding= "UTF-8"?> <beans xmlns= 
"http://xfire.codehaus.org/config/1.0" > 
  <service> 
    <!--webserviceq name that needs to be specified when calling this--> 
    <name>readerService</name> 
    <!- -This is usually your company's Web site, not very meaningful--> 
    <namespace>http://test/HelloService</namespace> 
    <!--interface class--> 
    <serviceClass>com.xfire.servlet.IReaderService</serviceClass> 
    <!--implementation class--> 
    < implementationclass>com.xfire.servlet.readerservice</implementationclass> 
  </service> 
</beans> 

Looking at the notes is generally fine.

4 Many people think this will do, no, not yet, you specify this, how other people visit it. How to forward the corresponding request to xfire there, let it be processed. Here again need to modify the Web.xml.
Modified as follows:

<?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/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>xfireservlet</servlet-name > 
    <servlet-class>org.codehaus.xfire.transport.http.XFireConfigurableServlet</servlet-class> 
  </servlet> 
 
  <servlet-mapping> 
    <servlet-name>XFireServlet</servlet-name> 
    <url-pattern>/services/*</url-pattern> 
  </servlet-mapping> 
</web-app> 

In fact, added a servlet and corresponding mapping. Next, we enter directly into the browser:

http://localhost:8080/xfireWebService/services/readerService?wsdl

We can see:

This shows the WSDL, which shows the method we define and the type we return. The WSDL is explained later.
5 After the completion of the four steps above, we have completed the deployment of WebService. Others can call the corresponding webservice to access our methods. Below we will use Xfire provided by the client to visit the webservice we have just released:

public class Readerclient {public 
  static void Main (string[] args) { 
    //This is to create a service that needs to pass in an interface class, Because we must later call the corresponding interface method 
    Service Srcmodel = new Objectservicefactory (). Create (Ireaderservice.class); 
    Agent Factory, here is to create the corresponding interface class 
    Xfireproxyfactory factory = new Xfireproxyfactory (Xfirefactory.newinstance (). Getxfire () ); 
    WebService address, no need to add WSDL 
    String readerserviceurl = "Http://localhost:8080/xfireWebService/services/readerService"; 
     
    try { 
      ///Use the factory to return the corresponding interface class 
      Ireaderservice Readerservice = (ireaderservice) factory.create (Srcmodel, Readerserviceurl); 
 
      Reader reader = Readerservice.getreader ("Shun", "123"); 
      SYSTEM.OUT.PRINTLN (reader); 
    } catch (Malformedurlexception e) { 
      e.printstacktrace ();}}} 
 

So, we see the output as:

WSDL File Structure analysis

The WSDL (Web services Description language,web Service Description Language) is an XML application that defines a Web service description as a set of service access points, These service access points enable clients to access services that contain document-oriented information or process-oriented calls (similar to remote procedure calls). WSDL First abstracts the requested/response messages that are used to access operations and accesses, and then binds them to specific transport protocols and message formats to ultimately define the service access points for the specific deployment. The service access points for the specific deployment associated with them become abstract Web services through a combination. This article will explain the structure of the WSDL document in detail and analyze the role of each element.

One: WSDL definition

WSDL is a document that is used to accurately describe a Web service, and a WSDL document is an XML document that follows the WSDL XML schema. A WSDL document defines a Web service as a collection of service access points or ports. In WSDL, because the abstract definition of a service access point and message has been detached from a specific service deployment or data format binding, the abstract definition can be reused: a message, an abstract description of the exchanged data, and a port type, which refers to an abstract collection of operations. The specific protocol and data format specification for a particular port type constitutes a binding that can be used again. The Web Access address is associated with a reusable binding, you can define a port, and the collection of ports is defined as a service.

A WSDL document usually contains 7 important elements, namely types, import, message, PortType, operation, binding, service element. These elements are nested within the definitions element, and definitions is the root element of the WSDL document. The next section of the article will provide a detailed description of the basic structure of the WSDL.

Second: basic structure of WSDL--Overview

As described in the first section, a basic WSDL document contains 7 important elements. Here are a few of these elements and their role.

The WSDL document uses the following elements in the definition of a Web service:

· Types-a container of data type definitions that uses a type system (generally using the type system in an XML Schema).

· Message-the abstract typed definition of the data structure of the communication messages. Use the type defined by types to define the data structure of the entire message.

· Operation-An abstract description of the operations supported in the service, typically a single Operation describes a request/response message pair for an access portal.

· PortType-an abstract collection of operations supported by an access entry point type that can be supported by one or more service access points.

· Binding-binding of specific protocol and data format specifications for a specific port type.

· Port-Defines a single service access point for a protocol/data format binding and a combination of specific Web Access addresses.

· Service-A collection of related service access points.

The XML schema of the WSDL can refer to the following URL: http://schemas.xmlsoap.org/wsdl/

Three: The basic structure of WSDL--detailing

This section describes in detail the role of each element of the WSDL document in a single example. The following example is the content of a simple WSDL document that can be produced by referring to my other article: Xfire Development Example--helloworld.

A simple WSDL document for a Web service that supports a unique operation named SayHello, which is implemented by running the SOAP protocol on HTTP. The request accepts a string name and, after processing, returns a simple string. The documentation is as follows:

<?xml version= "1.0" encoding= "UTF-8"?> <wsdl:definitions targetnamespace= "http://com.liuxiang.xfireDemo/" HelloService "xmlns:tns=" Http://com.liuxiang.xfireDemo/HelloService "xmlns:wsdlsoap=" http://schemas.xmlsoap.org/ wsdl/soap/"xmlns:soap12=" Http://www.w3.org/2003/05/soap-envelope "xmlns:xsd=" Http://www.w3.org/2001/XMLSchema "x" mlns:soapenc11= "http://schemas.xmlsoap.org/soap/encoding/" xmlns:soapenc12= "http://www.w3.org/2003/05/ Soap-encoding "xmlns:soap11=" http://schemas.xmlsoap.org/soap/envelope/"xmlns:wsdl=" http://schemas.xmlsoap.org/ wsdl/"> <wsdl:types> <xsd:schema xmlns:xsd=" Http://www.w3.org/2001/XMLSchema "Attributeformdefa 
      ult= "qualified" elementformdefault= "qualified" targetnamespace= "Http://com.liuxiang.xfireDemo/HelloService" > <xsd:element name= "SayHello" > <xsd:complexType> <xsd:sequence> < 
            Xsd:element maxoccurs= "1" minoccurs= "1"  Name= "Name" nillable= "true" type= "xsd:string"/> </xsd:sequence> </xsd:complexType> 
          </xsd:element> <xsd:element name= "Sayhelloresponse" > <xsd:complexType> <xsd:sequence> <xsd:element maxoccurs= "1" minoccurs= "1" name= "Out" nillable= "true" Ty 
    Pe= "xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> </wsdl:types> <wsdl:message name= "Sayhelloresponse" > <wsdl:part name= "parame Ters "element=" Tns:sayhelloresponse "/> </wsdl:message> <wsdl:message name=" Sayhellorequest "> &L T;wsdl:part name= "Parameters" element= "Tns:sayhello"/> </wsdl:message> <wsdl:porttype name= "Helloservic Eporttype "> <wsdl:operation name=" SayHello "> <wsdl:input name=" sayhellorequest "message=" Tns:sayhellorequest "/&GT <wsdl:output name= "Sayhelloresponse" message= "Tns:sayhelloresponse"/> </wsdl:operation> < /wsdl:porttype> <wsdl:binding name= "helloservicehttpbinding" type= "Tns:helloserviceporttype" > <ws dlsoap:binding style= "Document" transport= "Http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name 
        = "SayHello" > <wsdlsoap:operation soapaction= ""/> <wsdl:input name= "Sayhellorequest" > 
        <wsdlsoap:body use= "literal"/> </wsdl:input> <wsdl:output name= "Sayhelloresponse" > <wsdlsoap:body use= "literal"/> </wsdl:output> </wsdl:operation> &LT;/WSDL:BINDING&G 
  T <wsdl:service name= "HelloService" > <wsdl:port name= "helloservicehttpport" binding= "Tns:HelloServiceHt" 
    Tpbinding "> <wsdlsoap:address location=" Http://localhost:8080/xfire/services/HelloService "/> </wSdl:port> </wsdl:service> </wsdl:definitions> 

 

The types element uses the XML Schema language to declare complex data types and elements that are used elsewhere in the WSDL document;

The import element is similar to the import element in an XML Schema document, which is used to import the WSDL definition from other WSDL documents;
The message element describes the payload of the messages by using the built-in type, complex type, or element of the XML schema defined in the type element of the WSDL document or in an external WSDL document referenced by the import element;
The porttype element and the operation element describe the interface of the Web service and define his methods. The porttype element and the operation element are similar to the method declarations defined in the Java interface. The operation element uses one or more message types to define the payload of his input and output;
The binding element assigns porttype elements and operation elements to a special protocol and encoding style;
The service element is responsible for assigning an Internet address to a specific binding;

1, Definitions elements

The root element of all WSDL documents is the definitions element. This element encapsulates the entire document and provides a WSDL document with its name. In addition to providing a namespace, the element has no other effect and is not described in detail.

The following code is the structure of a definitions element:

<wsdl:definitions 
  targetnamespace= "Http://com.liuxiang.xfireDemo/HelloService" 
  xmlns:tns= "http:// Com.liuxiang.xfiredemo/helloservice " 
  xmlns:wsdlsoap=" http://schemas.xmlsoap.org/wsdl/soap/" 
  xmlns: Soap12= "Http://www.w3.org/2003/05/soap-envelope" 
  xmlns:xsd= "Http://www.w3.org/2001/XMLSchema" 
  xmlns: soapenc11= "http://schemas.xmlsoap.org/soap/encoding/" 
  xmlns:soapenc12= "http://www.w3.org/2003/05/ Soap-encoding " 
  xmlns:soap11=" http://schemas.xmlsoap.org/soap/envelope/" 
  xmlns:wsdl=" http:// schemas.xmlsoap.org/wsdl/"> 
</wsdl:definitions> 

2, types elements

WSDL uses the common-system XML schema built-in type as its basic type. The types element is used as a container to define the various data types that are not described in the XML Schema built-in type. When declaring a payload for a message part, the message definition uses the data types and elements defined in the types element. The types definition in the WSDL document of this article:

 <wsdl:types> <xsd:schema xmlns:xsd= "Http://www.w3.org/2001/XMLSchema" attributeformdefault= "qualified" elementformdefault= "qualified" targetnamespace= "Http://com.liuxiang.xfireDemo/H" Elloservice "> <xsd:element name=" SayHello "> <xsd:complexType> <XSD:SEQUENCE&G 
            T 
          <xsd:element maxoccurs= "1" minoccurs= "1" name= "name" nillable= "true" type= "xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name= "Sayhellor Esponse "> <xsd:complexType> <xsd:sequence> <xsd:element maxoccurs=" 1 "m inoccurs= "1" name= "Out" nillable= "true" type= "xsd:string"/> </xsd:sequence> & lt;/xsd:complextype> </xsd:element> </xsd:schema> </wsdl:types> 

Above is the data definition section, which defines two elements, one is SayHello, the other is sayhelloresponse:

SayHello: Defines a complex type that contains only a simple string that will be used to describe the incoming part of an operation in the future;

Sayhelloresponse: Defines a complex type that contains only a simple string that will be used to describe the return value of the operation in the future;

3, import elements

The import element makes it possible to use the definition elements in the namespace specified in the other WSDL document in the current WSDL document. The import element is not used in this example. This functionality is usually very effective when the user wants to modularize the WSDL document.

The import format is as follows:

<wsdl:import namespace= "http://xxx.xxx.xxx/xxx/xxx" location= "http://xxx.xxx.xxx/xxx/xxx.wsdl"/> 

Must have namespace properties and location properties:

Namespace property: Value must match the targetnamespace declared in the WSDL document being imported;

Location property: You must point to an actual WSDL document and the document cannot be empty.

4, message Element

The message element describes the payload of a Web service using messages. The message element can describe the payload of the output or accept messages, and can also describe the contents of the soap file header and the error detail element. The way you define a message element depends on whether you are using RPC style or document-style messaging. In the definition of the message element in this article, document-style messaging is used in this document:

<wsdl:message name= "Sayhelloresponse" > 
    <wsdl:part name= "parameters" element= "Tns:sayhelloresponse"/ > 
  </wsdl:message> 
  <wsdl:message name= "Sayhellorequest" > 
    <wsdl:part name= " Parameters "element=" Tns:sayhello "/> 
  </wsdl:message> 

This section is an abstract definition of the message format: Two messages sayhelloresponse and sayhellorequest are defined:

The request message format for the Sayhellorequest:sayhello operation consists of a message fragment, the name is parameters, and the element is the element in the types we defined earlier;

The response message format for the Sayhelloresponse:sayhello operation consists of a message fragment, the name parameters, and the element is the element in the types we defined earlier;

If you are using RPC-style message delivery, you only need to modify the element elements in the document to type.

5, porttype elements

The porttype element defines the abstract interface of a Web service. This interface is somewhat like a Java interface, defining an abstract type and method without defining an implementation. In WSDL, the porttype element is implemented by the binding and service elements, which describe the Internet Protocol, encoding scheme, and Internet address that the Web service implementation uses.

A porttype can define multiple operation, and a operation can be considered a method, the definition of a WSDL document in this article:

  <wsdl:porttype name= "Helloserviceporttype" > 
    <wsdl:operation name= "SayHello" > 
      <wsdl:input Name= "Sayhellorequest" 
        message= "tns:sayhellorequest"/> <wsdl:output name= 
      "Sayhelloresponse" 
        Message= "Tns:sayhelloresponse"/> 
    </wsdl:operation> 
  </wsdl:portType> 

PortType defines the type of invocation pattern for a service, which contains an operation SayHello method, while both input and output indicate that the operation is a request/response pattern, and the request message is the previously defined sayhellorequest. The response message is the Sayhelloresponse defined earlier. Input represents the payload that is passed to the Web service, and output messages represent the payload that is delivered to the customer.

6, binding

The binding element maps an abstract porttype to a set of specific protocols (SOAO and HTTP), message passing styles, and encoding styles. Typically binding elements are used with protocol-specific elements and together, examples in this article:

  <wsdl:binding name= "helloservicehttpbinding" 
    type= "Tns:helloserviceporttype" > 
    <wsdlsoap: Binding style=, "document" 
      transport= "http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name= 
    " SayHello "> 
      <wsdlsoap:operation soapaction=" "/> 
      <wsdl:input name=" Sayhellorequest "> 
        <wsdlsoap:body use= "literal"/> 
      </wsdl:input> 
      <wsdl:output name= "Sayhelloresponse" > 
        <wsdlsoap:body use= "literal"/> 
      </wsdl:output>