Web services have been around for a long time. The first is soap, but soap only describes the message, followed by WSDL. WSDL does not tell you how to use Java to write Web Services. In this case, JAX-RPC 1.0 came into being. After several months of use, the Java Community process (JCP) staff who compiled this specification realized that some adjustments were needed and the result was JAX-RPC 1.1. The specification was used about a year later, and the JCP staff wanted to build a better version: JAX-RPC 2.0. Its main goal is to be consistent with the industry direction, but the industry not only uses RPC web services, but also uses message-oriented web services. Therefore, the "RPC" is removed from the name and replaced by "ws" (Web Services ). So the subsequent version of JAX-RPC 1.1 is JAX-WS 2.0 [Java API for XML-based Web services ].
Similarities?
Before listing the differences between JAX-RPC 1.1 and JAX-WS 2.0, we should first discuss the similarities between them:
- The JAX-WS still supports soap 1.1 over HTTP 1.1, so interoperability will not be affected and the same message can still be delivered online.
- The JAX-WS still supports WSDL 1.1, so the knowledge you have learned about this specification is still useful. The WSDL 2.0 specification is nearing completion, but its work is still in progress at the end of work related to JAX-WS 2.0.
What is the difference?
- HTTP 1.2
- Both JAX-RPC and JAX-WS support soap 1.1. The JAX-WS also supports soap 1.2.
- XML/HTTP
- The WSDL 1.1 specification is defined in HTTP binding, which means that XML messages can be sent over HTTP without soap. The JAX-RPC ignores the HTTP binding. The JAX-WS has added support for it.
- WS-I basic profile
- New Java features
- The JAX-RPC maps to Java 1.4. The JAX-WS maps to Java 5.0. JAX-WS depends on many new features in Java 5.0.
- Java ee 5 is a later version of J2EE 1.4 that adds support for JAX-WS, but still supports JAX-RPC, which can be confusing for new Web Services.
- Data ing model
- The JAX-RPC has its own ing model that covers about 90% of all schema types. It does not cover the part mapped
javax.xml.soap.SOAPElement
.
- The data ing model for the JAX-WS is jaxb. Jaxb ensures the ing of all XML modes.
- Interface ing model
- The basic interface ing model of JAX-WS is not very different from the JAX-RPC, but there are the following differences between them:
- The model of the JAX-WS uses the new Java 5.0 feature.
- The JAX-WS model introduces the asynchronous function.
- Dynamic Programming Model
- The dynamic client model of the JAX-WS differs significantly from that of the JAX-RPC. Many changes are made to recognize the needs of the industry:
- Message-oriented functions are introduced.
- The dynamic asynchronous function is introduced.
- The JAX-WS also adds a dynamic server model, which is not available in the JAX-RPC.
- Message transmission optimization mechanism (MTOM]
-
- The JAX-WS added support for the new attachment specification MTOM through jaxb. Microsoft has never added an attachment specification to soap; however, it seems that everyone supports MTOM, so attachment interoperability should be achieved.
- Handler Model
- From JAX-RPC to JAX-WS, the processing program model has undergone great changes.
- The JAX-RPC processor depends on SAAJ 1.2. JAX-WS processors rely on the new SAAJ 1.3 specification.
- Content-Type
- The media type of HTTP/soap messages in soap 1.1 is "text/XML" and its encoding is defined in rfc2376.
- Soap 1.1: the character set of HTTP/SOAP requests is determined by the contenttype Character Set parameter in the HTTP header. The encoding features defined in the XML declaration section of the SOAP message will be ignored. If the contenttype Character Set parameter is not specified, the character set is considered as US-ASCII.
- The media type of HTTP/soap messages in soap 1.2 is "application/soap + XML", and its encoding is defined in rfc3023.
- Soap 1.2: the character set of HTTP/SOAP requests is determined by the contenttype Character Set parameter in the HTTP header. The encoding features defined in the XML declaration section of the SOAP message will be ignored. If the contenttype Character Set parameter is not specified, the encoding feature defined in the XML declaration section is used. If the encoding properties of the contenttype Character Set parameter or XML Declaration are not defined, it will be treated as a UTF-8.
PS: For more information, see http://www.ibm.com/?works/cn/webservices/ws-tip-jaxwsrpc.html;