Differences between RPC and RMI and the connections and differences between Ajax-rpc, jax-ws, axis, and xfire

1. RPC does not support objects and uses the HTTP protocol.

 

2. Rmi supports object transmission. TCP/IP protocol

 

3. Rmi is only applicable to Java and RPC.

 

Comparison between RPC and RMI

 

The main difference between RMI and RPC lies in how methods are not called. In RMI, the remote interface enables each remote method to have a method signature. If a method is executed on the server but no matching signature is added to this remote interface, the new method cannot be called by the RMI client. In RPC, when a request arrives at the RPC server, the request contains a parameter set and a text value, usually in the form of "classname. methodname. This indicates to the RPC server that the requested method is named "methodname" in the class "classname ". Then the RPC server searches for the matched classes and methods and uses them as the input of the method parameter type. The parameter type here matches the type in the RPC request. Once the matching is successful, this method is called and the result is encoded and returned to the customer.

 

The distributed computing system requires that objects running on different hosts in different address spaces call each other. Various distributed systems have their own call protocols, such as the IIOP (Internet interorb protocol) of CORBA and the DCOM of MTS. What about the EJB component? Java provides a complete Sockets communication interface, but sockets requires that the client and server must encode and exchange data at the application level protocol. Using sockets is very troublesome.

A protocol used to replace sockets is RPC (Remote Procedure Call). It abstracts communication interfaces for Process calling, making it as convenient for programmers to call a remote process as to call a local process. The RPC system uses XDR to encode Remote Call parameters and return values.

 

However, RPC does not support objects, whereas EJB constructs a fully object-oriented distributed system. Therefore, Remote Method Invocation (RMI) is an inevitable choice. Using RMI makes it as convenient to call remote objects as to call local objects. RMI adopts the JRMP (Java Remote Method Protocol) communication Protocol and is a Remote call Method built on the TCP/IP Protocol.

 

RMI call Mechanism

RMI uses stubs and skeletons for remote object communication. Stub acts as the client proxy for the remote object and has the same remote interface as the remote object. The call to the remote object is actually done by calling the client proxy object stub of the object.

 

 

Jax-rpc, jax-ws, axis, and xfire connections and differences

 

Sun and Java standards

 

JAX-RPC 1.0 is the original standard for Java Web Services. Although JAX-RPC is designed to implement different protocols for actual Web Services, in practice, it is only used for SOAP services. Multiple different JAX-RPC implementations have been developed, the most widely used is probably the Apache framework, followed by the Reference Implementation distributed by Sun Microsystems as part of the Java Web Services Developer Pack.

 

When developing JAX-RPC 1.0, many in the industry believe that rpc/enc-style SOAP will become the most convenient and easy-to-use Web service. JAX-RPC 1.0 specifications require support for rpc/enc and doc/quiet styles, but do not require support for many pattern features. This has brought about an unfortunate side effect, making doc/parse SOAP (this technology is mode-based) A second-stream option.

 

JAX-RPC 1.0 has some limitations on Web service functions. From its name, we can see that the initial purpose is to support Remote Procedure Call (RPC) operations using XML. Java now has an existing technology for RPC calling between Java applications, that is, Remote Method Invocation (RMI ). The specification team chose to model the JAX-RPC on the existing RMI interface. As long as the request-response operation uses rpc/enc SOAP, this model can be matched very closely, but the effect of ing to asynchronous operations or other transfers is not ideal. By the end of 2003, Sun formed an expert group to begin development of the JAX-RPC 2.0 specification, realizing that there was always a significant revision to the JAX-RPC to address these and other issues.

 

 

JAX -*

 

The main goal of JAX-RPC 2.0 development is to update standards to support mandatory requirements for JAX-RPC 1.X (based on Java 5 features such as Annotation and generics ), improved messaging support, including asynchronous operations and transfers except HTTP, and improved mode support by using JAXB 2.0 bindings to replace the simple (but limited) built-in binding of JAX-RPC 1.X. The name of this subsequent standard was changed to JAX-WS 2.0 for emphasis on the scope of change and for other reasons. JAX-WS 2.0 now provides a prerelease version whose production version is expected to be available in mid-2006.

 

JAX-WS 2.0 successfully fulfilled various expectations for JAX-RPC 1.x and even provided some additional functionality such as limited rest support. Because JAX-WS 2.0 heavily uses annotation and other Java 5 features (so that older JVMs cannot be used), some developers may encounter problems during use, however, for many developers, dependency on the Java 5 feature will be a major advantage. A prominent concern is that JAX-WS 2.0 does not support any of the annotation's back-up options for Web service configuration, which may limit the flexibility and long-term advantages of the framework.

 

Both JAX-WS 2.0 and jaxb 2.0 are preparing to bind to the release Java 5 version of The j2se specification. Using these components as part of the standard JVM installation will undoubtedly increase the attractiveness of developers, as this will avoid the need to include a large number of frameworks in each application. The disadvantage of including a large number of frameworks in the standard JVM is that (in addition to increasing the basic download size), it may be difficult to implement version control when an error fix is required, just like a situation where components such as JAXP have already been bound ).

 

Moving towards interoperability

 

JAX-WS 2.0 directly supports xop/MTOM, not other new WCF technologies. However, in Sun's declared commitment to interoperability with Microsoft, they announced that they would develop Java open source versions of other technologies included in WCF. These open-source implementations will be developed as part of the large project glassfish, which covers the application server as Sun (including JAX-WS 2.0 and jaxb 2.0 Reference implementations) all technologies used.

 

We need to wait and see before these new open-source projects take shape. Sun will provide something available in the 2006 S, so more details will be available in subsequent articles in this series.

 

 

Apache Method

 

Over the years, the Apache project has done a lot of work on Web Services, and its main focus is on Java platform development. Apache's current Java SOAP Web service production platform is the third-generation Axis framework. Axis is widely used, including developers downloading and using it directly, and embedding it into several different application servers as a SOAP engine. Axis is generally considered to be the most widely used Java SOAP Web service platform.

 

However, Axis also has some disadvantages. First, it was designed based on the JAX-RPC 1.0 standard, which largely constrained the Axis architecture and limited its flexibility. With the increasing demand for expansion to build new technologies based on the core of SOAP processing, this limited flexibility becomes increasingly problematic. At the same time, the transformation to the doc/lit SOAP service also brought about a demand for better mode support. For Axis code, this was very impractical at the time. By the middle of 2004, the Axis team had considered it necessary to recompile the work, to apply the experience gained by implementing Axis in the re-compilation process, and to provide better flexibility for future expansion.

 

"Savior" Axis2

 

Axis2 is a later version of Axis. It is designed as a lightweight SOAP processing engine (although Axis2 also has some REST support for JAX-WS 2.0) and can be expanded in many ways. Unlike the original Axis, Axis2 does not deliberately constrain the implementation of any specific API (although some JAX-WS 2.0 support level plans to use the packaging of Axis2 core code ). The development of Axis2 has lasted for more than a year and will soon be put into production.

 

One of the best features of axis2 is the Axiom object model used for soap messages. The XML Object Model is almost as long as the XML itself. The earliest version is the W3C Dom standard. Unlike other XML object models, axiom uses the flexibility provided by the New XML parser to allow on-demand construction of object models. This means that building an object model for some XML documents that actually need to access the model will cause performance loss.

 

Another major feature of axis2 is support for data binding that can be inserted. This feature allows you to select the simplest way to process the XML payload of the soap document, customize the generated code, and use the selected method. Possible options include directly using axiom, using simple data binding methods similar to the original axis, or using specialized data binding frameworks such as xmlbeans, jibx, and jaxb 2.0.

 

Axis2 Extension

 

Although axis2 is still under development, there are already a series of projects that implement soap Extension Based on axis2. These projects include all the major technologies supported by WCF and some extensions Microsoft plans for in the add-on (that is, independently priced) applications. The architecture of axis2 allows easy development of such extensions using a component called a module.

 

The WS-Addressing and WS-Security Modules are currently included in the basic axis2 distribution (which may be downloaded as an independent part or even an independent project in the future, because these modules are not closely coupled with the core axis2 code ). WS-reliablemessaging support is being developed through the sandesha project, while WS-trust and WS-secureconversation are being developed through the wss4j Project (WS-Security implementation is already provided ). WS-atomictransaction and WS-coordination are being implemented through the Kandula project.

 

 

 

Conclusion: Axis implements the JAX-RPC, but Axis2 does not fully implement the JAX-WS specification.

 

JAX-RPC and JAX-WS are the specifications of WebService.

 

JAX-WS 2.0 is a later version of JAX-RPC 1.1.

 

@ See http://www.ibm.com/developerworks/cn/webservices/ws-jaxrpc/part1/

@ See http://www.ibm.com/developerworks/cn/webservices/ws-tip-jaxwsrpc.html

 

Axis and xfire are open-source implementations of WebService.

 

Axis has two versions: axis1 and axis2, and xfire has been renamed to cxf.

@ See ws.apache.org

@ See cxf.apache.org