Introduction to Java Web Service Learning report-web

With the rapid development of the web today, every organization faces the same challenge: creating an isomorphic environment when balancing core competencies with existing applications. It requires a simple, platform-independent way of communicating between applications. In this demand, a Web service is created, a generic term for a class of services that can be obtained from the Internet, using standard XML messaging systems that are not bound by any operating system or programming language. Over the past three years, three major technologies have emerged as global standards: SOAP,WSDL and UDDI. They form the core of today's Web services technology. However, all Web services protocols and new technologies are based on XML as their data representation layer, XML eliminates protocol-specific networks, operating systems, and platform binding constraints, so XML is the foundation of all Web services.




1. XML (extensible Markup Language)
1.1 XML
The birth of HTML makes Web publishing very simple, but HTML has a lot of limitations, because the standard tags have been predetermined by the consortium, so in the description of complex documents, HTML appears to be powerless. And HTML is descriptive, not object-oriented, so HTML does not give the meaning of the content. To solve these problems, the consortium began to look for answers, which is XML.
XML is extensible, and we can create custom elements to meet the needs of authoring. XML is also structurally configurable. We can examine the syntax of XML documents to avoid the spread of a large number of erroneous XML documents over the Internet. This is the DTD.
1.2 DTD
A DTD (document type definition) can be thought of as a syntax file for markup languages, a set of rules that define how XML tags are used, the DTD defines the elements, the attributes and values of the elements, and the description of which elements can be included in another element. DTDs can also define entities. XML parsers can use DTD files to parse XML documents. DTDs enable us to publish documents for other people to share. An XML document that has a DTD reference file is called a valid XML document.
However, because the XML DTD does not fully meet the requirements of XML automation processing, such as not well to implement the coordination between different modules of the application, lack of sufficient description of the constraints such as document structure, attribute, data type, etc., the consortium formally recommended XML Schema as XML in May 2001. Standard mode. Obviously, the consortium wants to use XML schemas as the mainstream of the XML Schema description language and gradually replace the XML DTD.
1.3 XML Schema
XML schemas differ greatly from XML DTDs. XML Schemas are in fact an application of XML, which means that XML schemas are in exactly the same format as XML, and as a subset of the SGML DTD, XML DTDs have a completely different format from the XML format. This distinction brings a lot of benefits to the use of XML schemas. For example, an XML parser can be applied directly to an XML Schema without the need for modification. Also as an application of XML, XML schemas naturally inherit the self-describing and extensible nature of XML, which makes XML schemas more readable and flexible. And because the format is exactly like XML, XML schemas can be stored together in the same way as XML documents that it describes, and are easy to manage.
1.4 DOM
In addition, to better access XML documents, we need to use the Document Object Model DOM, which is in fact the abstract specification of a tree-like collection of objects to access the contents of a given document. The DOM Object Library allows us to build XML syntax trees in memory, providing a more efficient way to add documents, locate document structures, add, modify, and delete document elements.
With these specifications, XML has provided a canonical structure for us to transmit data over the network. XML-RPC technology provides an xml-based and HTTP-based mechanism for methods or function calls over a network. XML-RPC allows a program to invoke a function or procedure over a network. It uses only a very small number of XML words to describe the attributes of the request and response, and transmits the information from the client to the server using the HTTP protocol. The client specifies the procedure name and parameters in the XML request, and the server returns an error or response in the XML response. Of course, XML-RPC seems too restrictive for many applications in the domain of programming where objects are commonly used. But when we need to integrate different types of systems, the simplicity inherent in XML-RPC can be demonstrated. When we create a public service, we can use XML-RPC to define the interface and choose a language to implement it so that any client with XML-RPC capability can connect to it once the service is published on the web. And when building a distributed system, you can also use XML-RPC as the paste code to connect different parts of the internal network. Therefore, although XML-RPC is simple, simple tools with creative applications can build complex and powerful architectures. XML-RPC may be the most appropriate minimum standard when a wide variety of systems require communication.
2. SOAP (Simple Object Access Protocol)
2.1 SOAP
Soap is an xml-based protocol for exchanging information between computers. Soap can be applied to various messaging systems and can be passed through a variety of transport protocols, but the initial focus is on remote procedure calls that are transmitted over HTTP. As a result, soap makes it easy for client applications to connect to remote services and invoke remote methods.
The SOAP specification mainly defines four elements: SOAP envelope specification, transport and protocol bindings, encoding rules, and an RPC protocol.
n SOAP Envelope specification, the SOAP envelope specification defines specific rules for how the data passed between computers is encapsulated. This includes applying specific data, such as the name of the method to be invoked, the method parameter and the return value, and the information such as who will handle the encapsulated content and how to encode the error message when the failure occurs.
n Data encoding rules, in order to exchange data, the computer must agree on rules that encode a particular data type, and SOAP has its own set of conventions for encoding data types. Most of the conventions are based on the XML schema specification of the consortium.
n RPC protocol, SOAP can be used for a variety of messaging systems such as one-way and bidirectional. SOAP defines a simple protocol for a two-way message connection for remote procedure calls and responses, which allows the client application to specify a remote method name, obtain any number of parameters, and accept the response from the server.
n Transport and protocol bindings, which provide a common set of mechanisms for more low-level protocols to transmit soap wrappers.
The request originating from the client or the response from the server is a one-way message, called a SOAP message. Each message has a mandatory envelope element, an optional header element and a mandatory BODY element. The SOAP request must include the name of the method to invoke and all the necessary arguments. Second, you need to define several namespaces for distinguishing between XML elements and attributes, or for referencing external schemas. The SOAP response is similar to the SOAP request.
XML and SOAP can describe data well, but many application data are not suitable for XML to describe, such as binary data for images. SWA (Soap with Attachments) is needed to solve the problem. SWA combines the SOAP protocol and the MIME format so that the SOAP message can contain any desired data.
2.2 Soap-rpc
SOAP-RPC uses the SOAP underlying structure to define a model to represent RPC and RPC responses. It does not necessarily require a synchronous request/response model or an HTTP protocol to be tightly bound. In fact, the use of SOAP-RPC is irrelevant to the binding of the Protocol. It is therefore important that SOAP defines a unified model that represents the RPC and one or more of its return values. Soap also provides methods for encoding method signatures, header data, and URIs that represent destinations. So Soap-rpc is more complex and more powerful than XML-RPC.




3. WSDL (Web Services Description Language)
WSDL is an XML grammar that describes Web services as a series of access endpoints that have the ability to exchange information in a process-oriented or document-oriented manner. WSDL describes four key types of data:
N describes the interface information for all public functions.
n the data type message for all message requests and message responses.
The binding information for the transport protocol used by N.
n is used to locate the address information for the specified service.




In summary, WSDL provides a protocol between the service requester and the service provider, primarily to describe the SOAP service. The WSDL itself uses XML syntax and can be divided into six main elements:
N Definitions: Must be the root element of all WSDL documents. It defines the name of the Web service, declares multiple namespaces used by other parts of the document, and includes all service elements.
N types: Describes all data types that are used between the client and the server.
N message: Describes a one-way message that defines the name of the messages and can contain 0 or more message part elements that reference message parameters or message return values.
N portType: Combines multiple message elements to form a perfect one-way or round-trip operation.
N binding: Describes the specifics of implementing services on the Internet.
N Service: Used to define the address of the calling specified service. Typically contains the URL that invokes the SOAP service.




4. UDDI (Universal Description, Discovery and integration)
UDDI is a technical specification for describing, discovering, and connecting Web services. With UDDI, companies can not only publish Web services, but also find Web services. The core of UDDI is made up of two parts. First, UDDI is a technical specification for a distributed directory that establishes business and Web services. Data is stored in a particular XML format, and the UDDI specification includes the details of the APIs that search for existing data and publish new data. Second, the UDDI Business Registry is a fully operational implementation of the UDDI specification.
The technical architecture of N UDDI consists of three parts:
N UDDI Data Model: An XML Schema that describes the business and Web services.
N UDDI API: A SOAP based API for searching and publishing UDDI data.
N UDDI Services Group: an operational portal site that provides the implementation of a UDDI specification to synchronize data to and from a predetermined basis.
To sum up, the above three technologies and transport protocols constitute a complete Web services of four levels, from top to bottom, respectively:
N Found------------------------------UDDI
N Description------------------------------WSDL
n XML Message-----------------------Xml-rpc,soap,xml
N Transmission-------------------------------Http,smtp,ftp,beep
These technologies enable Web services to be more widely used because of the ability to implement xml-based, loosely coupled, coarse-grained, synchronous, or asynchronous capabilities, support remote process calls, and support document switching.