In-depth discussion on soap, RPC, and RMI

Http://blog.csdn.net/xuhaipeng/archive/2009/03/12/3984260.aspx

 

In Brett McLaughlin's second collection about soapbox, he compared the "Simple Object Access Protocol" with RMI and RPC in detail, it also provides suggestions on how developers can make the best choice among the three message protocols. He checked the real-world SOAP implementation from IBM and Microsoft, and checked the XML limitations-the basic encoding format of soap-and the issues involved as full-featured programming languages. This article contains the sample code of RPC and soap ticket requests for side-by-side comparison.

Since the last talk about the temporary podium, a large amount of propaganda on soap continues to heat up, not surprisingly. Microsoft praised the Protocol on its. NET platform. Apache claims that it is the most important thing for message transmission (at least in the XML circle I met), and everyone wants it. Services for soap are being developed at enhydra and JBoss (two popular open source application servers), as well as many commercial application server companies. So what has changed the soap story since the previous article? Honestly, almost none. Soap is like a rock that has gained momentum and is ready to roll down the hill. The problem is whether you are running with it, or standing under it and looking up at it, hoping it will not surpass you. I will remove all market ads and give you some tools to clearly assess whether soap is suitable for you. In other words, I will help you to ensure that it will not be crushed by that rock!

This article goes on to my previous Temporary podium, which explores soap in depth, especially its foundation in RPC and XML-RPC. Here, I will compare the communication between soap and the Java space, its biggest competitor RMI (remote method call. RMI has been used for communication between components across networks in Java for a long time. It continues to become popular with Enterprise JavaBeans (EJB) technology. I will study how RMI differs from soap-including the reality of soap and the future prospects of soap. Finally, let's take a look at what I call "work-level soap", which means you can download it from Microsoft and IBM now. This part of this article will shift from a conceptual perspective to a specific consideration that developers are asking: "What can soap do for me now ?"

RMI or RPC?

In the first article of this one or two series, I studied soap, specifically describing what it is, and what it is equally important, and what it is not. In particular, I looked at RPC, XML-RPC, and soap and analyzed what each technology contains. You may be surprised to find that many of soap's "features" are actually a feature of XML-RPC, not inherent in soap. You may also understand that you can use simpler packages instead of soap to meet business needs, such as one of the XML-RPC libraries found at the userland XML-RPC site (see references. Alternatively, you may decide that the soap encapsulation mechanism can be used to easily encode the specific data type of the application. Soap is exactly what you need. In any case, with the information I provided in the first temporary podium article, you should have enough knowledge about soap and RPC, it can be compared with RMI, the main rival in today's programming. There are many good reasons to use RMI instead of RPC, but there are also good reasons to use RPC instead of RMI. (Is this always the case ?) In the following sections, we discuss the main factors necessary for selection between the three options: soap, RPC, or RMI.

It depends on the language

The use of soap, RPC, or RMI depends on your programming language. If you are a Java programmer, there is Rmi as part of the Java API-and it is easy to use and well-developed documentation. If it is not a Java programmer, RMI is not an automatic option. In fact, non-Java programmers will find that soap is a very attractive solution, even for Java developers. Soap provides easier message transmission and communication methods than CORBA and other remote protocols. Moreover, it provides very convenient encoding for XML: although some C and Perl XML syntax analyzers are available, this is generally slower (in terms of development) than Java under the same conditions ). Therefore, soap not only adds messages to your toolbox, but also adds the burden of using tools to perform syntax analysis on XML, and the tool is not as mature as its Java partner.

In fact, most of the Java programmers who use soap come back to the original problem: RPC or RMI. What if you are a Java developer and must communicate with non-Java applications or components? Other participants in your application space may not be able to send or receive RMI communications. It is possible that they do not want to deal with the debate between IIOP or CORBA. But they can indeed receive friendly and simple loads of soap delivery. Decoding payload and response in some way (using soap APIs in their own language) enables communication to easily bridge the "programming language barrier"-and this makes soap attractive.

What does it mean for you as a developer? If you use Java encoding and talk to Java, soap will lose some attractiveness if you never need anything other than Java. At this time, developers will accept more RMI than soap, it is easier to learn and use. However, for real Java-friendly users, soap still has some advantages (I will talk about it later), but it is not that attractive. If it does not work in the Java environment or needs to communicate with the non-Java environment, soap starts to emit light. It uses XML, which is irrelevant to the vendor and language and is easy to use for syntax analysis using Perl, C, Ada, and even COBOL (although why the use of COBOL is the subject of another speech. Soap is an attractive alternative to heavy-duty examples such as CORBA and RMI-IIOP. In addition, since soap is a popular technology, the soap APIs in other languages will soon come. In these cases, we can think that soap is a real friend of message delivery. Of course, soap is more than just message passing. Now, I will demonstrate how the client interacts with soap and RMI.

Call vs request and response

When deciding whether to use RMI instead of RPC or vice versa, it is important to take a look at the interaction between the two. The interaction RMI model is completely different from that used in RPC: there are significant differences in how to operate remote objects. In fact, remote objects are not directly operated in RPC and soap! To clarify this, I will explore this model in depth.

In RMI, remote objects act as if they were local objects. The client application directly calls the method on the remote object stub. Through the magic of RMI and Java, the stub can call the Network encoding method, and the final result is that the object on the other machine calls a method. Then, the result is encoded similarly and returned to the stub, which returns the result. For the client, it does not seem to involve remote objects. Perhaps the biggest benefit of using this interaction method is the type security and direct use of method names. In other words, a normal Java convention is followed: A method is called. If the parameter is incorrect, a compile-time error occurs. However, I must tell you that this method has negative effects. Many exceptions are eventually wrapped in Java. RMI. RemoteException. Therefore, you must make sure that you have some knowledge in the application that calls the RMI object. Otherwise, you will lose the packaging information in RemoteException (possibly numberformatexception. The result is a lack of error information.

The call of the alternative RPC style follows a completely different path. Instead of involving the method being called, it is better to have a message to be sent, basically a request to the remote server. Then, clearly express the response and return the response. In this case, the client never directly calls the method. A request usually consists of the name and parameters of the method on the remote server. However, these are all encoded. Listing 1 shows code snippets, requesting to book and buy a ticket.

Now, I know that you may feel cheated because this article is about soap and you are getting a sample of XML-RPC code. For the sake of completeness, see the same call using soap in Listing 2.

Up to now, using XML-RPC or using soap is irrelevant to RMI; The XML-RPC is the same as the interaction between the client and the server in soap, and there is a huge difference between the two and RMI. The method names and parameters seen in these lists are encoded in string or parameter (depending on the technology in use ). You also see that the search must be performed by name-instead of obtaining the actual java. Lang. Reflect. Method handle in the Java Virtual Machine, as in RMI. Using this RPC encoding style may cause more errors: Methods on the server may be lost, or methods on the client may be spelled incorrectly. Other possible problems are that the type of the independent variable is incorrect, the specified independent variable name is incorrect, or the server is on the machine. With RPC, all these problems are run-time problems, and with RMI (except server-on-server) these problems may be compile-time problems. In general, it is best to capture problems at compilation time rather than at runtime. The problem is that using RPC or soap causes you to lose the convenience of the Java compiler.

The RPC style does provide some advantages. First, it allows greater independence between the client and the server. Unlike RMI, you do not need to generate the stub classes and pass them to the client. The server can be completely shut down and replaced without being known to the client. (This can be done in RMI, but it is much more difficult to implement it .) In fact, without interrupting client processing, you can upgrade and recompile the classes and methods on the server between calls. In addition, with soap (compared with the XML-RPC separately), the fault mechanism of soap, the standard part of the API can be used to broadcast a large amount of information that the client may encounter problems.

Again. I want you to make judgments based on the use of RMI, RPC, and soap in your work. In some cases, soap has obvious advantages: it is very suitable for asynchronous communication and for loosely coupled clients and servers. However, this benefit may lead to some adverse results. A large number of runtime checks are required, and developers lose a lot to ensure that the methods and parameters are correct for compilation convenience. If you have read my first article on the temporary podium, I am sure you know what I want to say: Evaluate your business needs. Go to Taobao store. You may find that in some cases, sending a soap call makes the remote server very useful for calmly handling tasks. In other cases, we hope to use RMI for Java-to-Java communication and to ensure the type security during compilation.

Work-level soap

I have compared soap with RPC, XML-RPC, and RMI and studied the differences between them as well as their advantages and disadvantages. Now is not the end; I still need to consider some issues about soap itself. So far, the discussion about soap has been focused on the "conceptual implementation" of technology. I have demonstrated how API behavior works if standards are implemented by "as is. In reality, there is no perfect implementation. Remember, the toolbox is developed by people! Remember, in the next section, I checked the actual soap implementation-What is "work-level soap" to see how it looks, and if it delivers soap promises.

Practice vs Outlook: soap for IBM and Microsoft

How can implementation and specifications be mutually compatible? Two major soap implementations are under development. One is from Apache, as part of the IBM Apache XML project, and the other is from Microsoft, as part of its. NET platform. In both cases, the public release is less than a year old, leading to the maturity of implementation.

Perhaps from the most desired release of Apache XML, Apache SOAP work is an extension of IBM's original work on soap4j. The soap version given to Apache is "2.0". It is difficult to compare it with many other 2.0 products, which are usually very robust. The specification contains a large number of items not added to soap 2.0; however, most of these items are not required in most applications. The disadvantage is that these minority and infrequently used items must be supported in order to comply with the specifications. You will not use them until they are implemented. The soap toolbox may not make performance adjustments because the work is still on the features. Unfortunately, you have paid for the less common features.

The core part of Microsoft's SOAP implementation and. NET platform is almost committed to W3C soap in terms of soap functionality and compliance. This will very likely continue to be true, because soap is the method that most communication will appear in. Net platforms. The ability of components to communicate with each other through soap-in development and production-is one of the main features of. net, so do not look forward to Microsoft's SOAP implementation. At the same time, you should also look forward to implementing many proprietary features in Microsoft. With these "hooks", Microsoft-driven products will be able to take advantage of shortcuts specific to the. NET platform. If you are using all Microsoft products, these hooks will be very useful. However, if you are trying to implement with common soap, please note!

The bottom line is that soap is still in its rapid development stage, and today's soap is not exactly the soap promised in the future: Soap implementations from IBM and Microsoft are still being developed and completed. Do not expect to start using soap now (through one of these projects) and seamlessly upgrade to a new version within a few months. features will change, functionality will change, and confusion will arise, this usually results in modifications to the rest of the application. In addition, if W3C accepts soap as a new specification, there will be several revisions before the final proposal is delivered. These revisions will cause additional changes to the SOAP implementation, which of course means more upgrades to your development environment.

In short, there is still a lot to do with the current SOAP implementation. If you are not stuck in implementation details and are willing to be flexible when an upgrade is available, you can learn a lot from the current SOAP implementation using IBM and Microsoft. You can investigate how RPC works, how remote methods are located, and how soap envelopes and fault mechanisms work. In other words, when the complete and stable implementations of soap come true, you can well stay ahead of this competition.

Description of XML: all you need?

With regard to soap providers, the final warning is: do not place a bet on XML. I am sure I have quoted this sentence by mistake, so I have finished listening. XML is still here. However, XML is most suitable for large application environments and supports it in real programming languages such as Java. Some people say, "XML is enough ." With the addition of soap, XML-RPC, RSS (RDF Site Summary) and other XML words in practical application fields, XML itself is a programming language. Using Apache cocoon, XSL, XSLT, soap, and an XML database makes it possible to run the entire application without writing a line of Java code. (To be fair, no one in cocoon actually recommends this; it is just an example .)

This premise is only required by XML, and this premise is inherently flawed. There is a price to use XML: encoding takes longer than binary format, and it is larger when it is sent over the network. XML can be understood across programming languages and platforms. However, if you do not need such a comprehensive function, XML does not make much sense! For example, using XML between Servlet and EJB in the same application is a bad idea. It takes time to process XML and to transmit XML resources, and nothing can be done.

Soap is a tool. It should be used only as a tool to help applications transmit messages and represent data. These applications require more than XML. I can understand that some people advocate not to be bound by Java-especially when sun has shown that he is unwilling to create an open standard process for the language-it is impractical to try to use XML as a substitute for Java. Therefore, use soap and XML as more tools in the toolbox. Although it is a versatile and powerful tool, it is still a tool.

Conclusion

In one or two articles, I have studied the high-profile soap. I analyzed it and compared it with its predecessors RPC and XML-RPC, and compared it with its main competitor RMI. I also checked the available SOAP implementation and the actual W3C soap description ). Even if you have not made a decision on soap, you should be able to recognize its advantages and problems.

I hope that you will begin to form your own opinion on the soap status. If you wait for a command to tell you whether soap is "good" or "bad", this will not happen. Frankly speaking, I cannot tell you whether you should use soap. But I can tell you that today, in many cases, developers are using soap, while switching to XML-RPC may be adequate and easy to program. In addition, the XML-RPC library is much more sophisticated than the SOAP library. At the same time, some programmers struggle to communicate with Perl and C components, C and Java components every day. These developers can benefit from switching to soap-based or XML-RPC-based communication models. On the other hand, Java developers who never turn to languages other than Java can turn to RMI rather than soap, and they will see significant performance improvements.

I will leave you with the following basic suggestions: "Go to Taobao ". Before you are too excited about soap, make sure it meets your business needs. If it does not match, do not be afraid that the technical "current" will be less than the colleagues; satisfaction with simple and successful applications far outweighs the hassle of using technology such as soap to use the most fashionable Technology in applications. In any case, follow the developerworks XML area because I will closely monitor and cover any new development related to soap. Other developers will take turns standing on the temporary podium.

References

You can join the Forum at the top or bottom of this article.

Read W3C instructions: Soap 1.1 note to concentrate on soap.

Get the implementation from XML Apache on xml.apache.org.

In the MS soap SDK vs IBM soap4j and MS soap SDK vs. IBM/Apache XML-SOAP, the ibm soap implementation is compared with Microsoft's SOAP implementation.

Learn about the XML-RPC on the userland XML-RPC website, where you can find several XML-RPC libraries.

Please read more about XML and related technologies in brett's Java and XML book.

The IBM soap Security Extension page describes recommendations for adding security measures to the SOAP implementation (including links to note to the W3C) and a SOAP envelope API with extensions.

The IBM Web Service fact table briefly illustrates how soap complies with Web service initiatives and provides other resource links.

At the IBM Solution 2001 Developer Conference in London, Thursday, May 17, 2001, the soap, Web Services and MQSeries series were mentioned.

 

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/xuhaipeng/archive/2009/03/12/3984260.aspx