Using Java technology to implement XML-based web services
Summary: XML solves the problem of data representation, separating the data display and data representation, the XML Schema (XSD) set by W3C defines a set of standard data types and gives a language to extend this set of data types. The Web service platform uses XSD as its data type system, the Web Service Description Language (WSDL) is based on XML-based language, used to describe web services and their functions, parameters, and return values. Web services can realize communication across firewalls, which is conducive to application integration, software and data reuse. This article describes how to use Java (mainly Java Web service development packages) and related technologies to implement web services.
Keywords: web service; Java; XML
introduction
With the gradual expansion of the Internet, online transactions, e-commerce is gradually prosperous, and within the enterprise, information exchange between enterprises is increasingly dependent on Internet. However, currently, the applications of most e-commerce and web-based commercial services, due to the development of language, deployment platform, the communication protocol adopted, and the difference in external exchange data format, the system integration will cost high cost. The main goal of the Web service is to construct a generalized platform-independent, language-independent technical layer on the basis of existing heterogeneous, and to achieve application and integration of each other.
1 xml with java
The implementation of the web service is inseparable from XML. XML is a key technology for web services implementation, which meets the needs of Web services to achieve inter-data communication between different information systems. XML is a standard markup. By using XML, it can be a member of a rapidly developed community that is rapidly developed by a large number of standard and product support. This means that it is easy to find support in various forms when creating, operating, storeing, and swapping XML documents. Especially after the W3C has launched a series of criteria to improve XML, XML has been widely used. To date, XML has become the most ideal data expression method on the Web and the factual criteria for data representation and exchange on Web, which is an effective way to share data between applications or between applications.
Java technology. Java natural cross-platform capabilities, written a common code running everywhere, making it a natural choice for Web service programming languages. At the same time, the scalability, security, and efficiency of the J2EE platform also provides convenient development of Web services, and partially solves the security issues of Web services, and expands problems. In addition, Java has added APIs specifically for XML processing, providing greater convenience for processing XML data. Java's powerful handling of XML data and cross-platform features, providing convenience for Web services, developers can use J2EE standard API and various components to develop systems.
2 Web service architecture
Three roles are included in the Architecture of the Web Services: Service Provider, Service Requestor, Service Registry. There are three operations between roles: Publish, Find, Binding (BIND). The web service architecture is shown in 1. Specifically, the roles in the web service architecture are as follows:
(1) Service Provider. From a business perspective, this is the owner of the service; from the perspective of the architecture, this is a platform for hosting access services.
(2) Service Requester. From a business perspective, this is an enterprise that requires a specific function; from the perspective of architecture, this is a application that is looking and calling services, or launching an interaction with the service. The service requester role can be used by the browser, controlled by a program or without a user interface (such as another web service).
(3) Service Broker. This is a searchable service description registry, and the service provider releases their service description. During static binding development or dynamic binding execution, the service requestor looks for the service and obtains the binding information of the service (in the service description). For static binding service requestors, the service registration center is an optional role in the architecture because the service provider can send the description to the service requestor. The operation in the web service architecture is as follows:
(1) Publish. To enable service access, you need to issue a service description to enable service requestors to find it. The location of the release service description can vary depending on the requirements of the application.
(2) Find (find). In the lookup operation, the service requester directly retrieves the service description or queries the required service type in the Service Registry.
(3) Binding (BIND). In binding operations, service requestors use the binding details in the service description to locate, contact, and call services to call or initiate interaction with services at runtime.
3 Core Agreements in Web Services
1 SOAP
Simple Object Access Protocol, SOAP is a simple protocol to exchange information through XML in a disperse or distributed environment. It consists of four parts: 1SOAP package (Envelop), the package defines what is the content in the message, who is sent, who should accept and process it, how to handle their framework; 2SOAP coding rules (Encoding Rules), Used to indicate an instance of the data type required to use; 3SOAP RPC
Representation, represents an agreement to remote procedure calls and answers; 4SOAP Binding, exchange information using underlying protocol. As an open protocol, SOAP can be understood as SOAP = RPC HTTP XML: HTTP is used as the underlying communication protocol; RPC is used as a consistent call path; XML is used as data transfer format, allowing service providers and service customers through firewall Communication interaction in the Internet. Of course, SOAP can also use SMTP, FTP, etc. as the underlying communication protocol.
2 WSDL
Web Services Definition Language (WSDL) defines a set of service access points based on XML-based syntax, describing web services as a service access point capable of messaging. In WSDL, due to service access points and
The abstract definition of the message has been separated from the specific service deployment or data format binding, so the abstract definition can be used again: message refers to the abstract description of the exchange data; the port type, the abstract collection of the operation. Specific protocols and data format specifications for specific port types constitute bindings that can be used again. Associate a web access address with the re-used binding, you can define a port, and the port of the port is defined as a service. In a Web service implementation, the generation of files such as WSDL is usually done using the tools provided by the manufacturer.
3 UDDI
Unified Description, Discovery and Integration Protocol (UDDI) is a web-based, distributed, implementation standard specification for the information registry provided for web services, and also contains a set of enabled Web services to be registered. The implementation of the access protocols that other companies can discover. UDDI provides a method based on a distributed business registration center that maintains a global catalog of a Web service provided by a business and businesses, and the information description format is based on universal XML format. UDDI is also a name based on Web-based registry, which stores information of commercial or other entities and related technical call interfaces (or API). These registration centers operate through multiple UDDI Operation Inlet Site (Operator Site), by accessing any of the common UDDI operating portfolio, anyone can query the web services provided by the business entity or represent the business entity.
4 implementation of Web services
1 Java Web Service Development Kit
Java Web Services Developer Pack is a development package provided by Sun for Web services. It integrates Java and XML technology into a package, allowing developers to be faster and easily integrated XML technology into the development project. Java XML APIs can be divided into two categories: for document processing APIs and procedures processing APIs.
l API (1) JAXP (Java API for XML Processing) for XML document processing. Such APIs use various parsers to convert and process XML documents. Support for two ways to process XML documents: one is based on SAX technology, one is based on DOM technology. At the same time, the latest JAXP also supports the XSLT standard.
(2) JAXB (The Java Architecture for XML Binding). XML binding technology can be implemented from XML Schema to the Java class. With jaxb, you can convert the XML document into a Java object in the background of the EJB layer; also you can also convert Java objects taken out from EJB to XML document returns to users. The JAXB interface provides the XML document than SAX and DOM more advanced methods.
(3) SAAJ (The Soap with Attachments API for Java). SAAJ provides a standard way for the Java platform to send an XML document via the Internet. It is based on SOAP 1.1 and an accessory SOAP specification, provides a basic framework for XML messages.
l Process processing APIS
(1) JAX-RPC (The Java API for XML-Based RPC). It supports XML-based remote procedure calls that define mappings between WSDL / XML and Java, allowing developers to quickly develop SOAP-based web services. The RPC mechanism is often used in a distributed client / server model.
(2) JAXR (The Java API for XML Registries). JAXR is a Java XML API used in service registration, which provides a unified interface to realize business registration, support EBXML, UDDI, and other registration specifications.
2 Specific implementation of the Web service
The implementation of the Web service, mainly including the implementation of the logical layer, deployment, generates customer access code, and deploying four basic steps. Developing a Web service using the JAX-RPC requires two parts of the server side and the client.
2.1 Server
At the server side, first, based on the function required by the service written logic required, compile it into a Class file, then use the tool to generate the required file, package the WAR file, and finally deploy service. The specific implementation includes the following steps:
(1) Writing a logical class that requires a server-side interface and inheritance interface implementation. A service's end-point has some provisions: Java.rmi.Remot interface must be implemented, each method needs to throw RemoteException exception. In the class of inheritance interface, the logic function to be implemented in the service is implemented.
(2) Compile the class file required to serve. This process refers to the basis of compiling Java files as a Class file and is the basis of the entire process.
(3) Generate a service required document. Use the WSCompile tool to generate a Model.gz file, which contains the internal data structure described by the service. The specific command is as follows:
WSCompile -Define -d build -nd build -classpath build config.xml -Model build / model.gz
Where: the define flag tells the tool to read the EndPoint interface of the service and create a WSDL file. -d and -nd flag tells the tool to write the output file into the specified directory build, config.xml means that the tool needs to read the information from the file, and model.gz is the desired file generated.
(4) Pack the service as a WAR file. Copy the web.xml file of the class file, model.gz, web application description information, and JAXRPC-RI.xml that calls Web service notes information to the web-INF directory, and package the JAR command to the WAR file. (5) Handling the WAR file. Use the wsndeploy command to generate a deployable WAR file. The specific command is as follows:
WSDeploy -o OutputFile.war InputFile.war
Where: InputFile.war is an input information file, ie (4) package generated WAR file, OutputFile is a newly generated deployment file, which contains Tie Classes and WSDL files.
(6) Deploy service on the server. Deploy the packaged Web service with the deploy command provided by the SOAP server. If you are using Tomcat, copy the WAR file directly to the webapps directory. You can then view whether you are configured in SOAP services from providing deployment. For Tomcat, you can in View on Cename>. 2.2 client There are usually three types of customers: Static Stub, Dynamic Proxy and Dynamic Invocation Interface (DII) (1) static stub. The implementation of the Static Stub type is mainly related to: generating stub, writing a static guest Household code, compile code, run the client. WSCompile tool reads the WSDL file on the server and generates Stub: WSCompile -gen: Client -d Build-ClassPath Build Config-Wsdl.xml (2) Dynamic Proxy. The Dynamic Proxy type implementation is mainly related to: generating an interface, writing dynamic customer code, compiling code, running the client. WSCompile tool reads the WSDL file on the server and generates the interface required for the customer: WSCompile -import -d build -classpath build config-wsdl.xml (3) Dynamic Invocation Interface (DII). The DII method provides more elastic customer calls, and the customer code is not required to generate a runtime class generated by the WSCompile tool. But this code is more complicated. Specific steps are as follows: · Create a ServiceFactory instance · Create service (QNAME using service name) · Create a Call object (QNAME using the endpoint interface) · Set the address of the endpoint and some Call object properties · Set the return type, operand and parameters of remote calls · Call the invoke method of Call · Compile the code and set the main method Client implementation using Static Stub and Dynamic Proxy types, you must know the WSDL description information, by entering the WSDL document to generate the class files required for runtime, to compile the source file. For DII methods, do not need to use WSCompile tools to generate corresponding class files, as needed to know the corresponding information at runtime, relatively flexible, but relatively complex when writing client code. 3 Register web services and find registration Customers can register their own services to the UDDI server, or find the services provided by other customers they need from the registry. These operations can be implemented using JAXR technology. In the registration process, first establish a connection with the registration center, and then use the Add method to include the name of the service, describe and easy to find the classification concept, etc. to join the service, and finally join the organization and Saveoragnization method to join the SAVEORAGNIZATION method. And save it to the registry. When looking up registration, you can activate the FindoNizations method to complete. During the interaction of the client and registry, the user can successfully complete the operation in the case of underlying. 5 Conclusion This article mainly discusses how to use Java technology to implement XML-based Web services. With Java Web Service Developer Pack and XML standards, we can develop a powerful and well-flexible and scalable web service system. Java is an excellent language for developing a web service program due to its network development advantage of platform-based, security, etc. Currently, technology for developing Web services includes servlets, JSP, JavaServer Faces, EJB, and more. As Java API's higher version, the development of Web services will become simpler, and various standards and technologies will help provide a more powerful and perfect solution. references: 1 JWSDP-1.3 Tutorial, http://java.sun.com 2 Chai Xiaoxi, Liang Yuqi, Web Services Technology, Architecture and Applications, Electronic Industry Press, 2003. 3 JASNOWSKI, M. Java, XML and Web Services Collection [M], Beijing: Electronic Industry Press, 2003. 4 David Chappel, Tyler Jewell, Java Web Services [M], O'Reilly Press, 2002
