Shulou(Shulou.com)06/02 Report--

This article will explain in detail what common mistakes to avoid when implementing XML and Web services, Xiaobian thinks it is quite practical, so share it with you as a reference, I hope you can gain something after reading this article.

Kyle points out that Web services developers often start experiencing "memory overflow" errors or strange "performance issues" when they find servers with extremely high processing loads, CPU usage approaching 100 percent, and low throughput and high network latency. Typical causes of these symptoms are very large (sometimes 50 MB or larger) messages. Moreover, these large messages often contain very large binary encoded information encoded in base-64 as the body of the XML message. The reasons for this are usually:

Developers don't understand the limitations of technology: XML processing is useful for solving many problems, but you have to recognize that messages are parsed--and in most products, that means many or all messages reside in memory.

Kyle suggests the following ways to improve the situation:

Do not send redundant messages. In many cases, when sending binary data, you may find that messages are highly repetitive. If so, you might want to consider using compression techniques at the HTTP level to improve your network latency. While this won't help you handle the load, it may help alleviate one of the problems. Do not embed binary information at all in the XML message body. This is a good solution, and there are several different ways to achieve this effect. For example, you can bypass the parsing overhead using SOAP with attachments or Message Transfer Optimization Mechanism (MTOM), although this does not help the network latency problem. A better approach would be to use SOAP without sending large binary blobs at all. Alternatively, use an "out-of-band data" transfer... or a "claim check (see EIP schema or here)" pattern via a controlled file transfer system to avoid sending large binary files over SOAP and HTTP.

Sorry, your data is showing. According to Kyle, another typical "performance problem" with Web services is that the level of use of Web services is very, very low--usually Web services are associated with an SQL statement because:

Misinterpreting SOA architecture principles. A key principle of a good SOA architecture is that your services should be highly reusable.

According to Kyle, these situations usually occur when:

... services arise if the design is derived from existing code "top-down"; typically, developers look at their existing architecture diagram and decide to transform each layer of the architecture, including the presentation layer, into a service set. Instead, coarse-grained Web services are better used in the right place in the SOA architecture. Again, examining the standard hierarchical model of an architecture, there is usually a well-defined place in the architecture where the business logic of the system has been encapsulated. These services can be wrapped using a Remote Facade Pattern to expose model-based services in an appropriate way.

The schema? We don't need any stinky patterns! Kyle points out that often developers try to reuse existing code to generate and parse XML as the basis for Web service implementations. These implementations typically use XML parsers to group/ungroup messages and Java HTTP classes to send and receive XML documents. When working with Web services, the common approach is to create WSDL documents that use schema elements, let XML pass unimpeded, and then parse them in existing code.

A symptom of this problem is that organizations don't see the benefits of SOA promise, and it seems harder (not easier) to maintain their solutions than it used to be when using Web services

The simple solution is that whenever you write a Web service, whether you use WS-* standards or REST methods, make sure you create a complete and accurate XML schema that represents the structure of your document.

If you are building WS-* Web services, this XML should be included in the WSDL describing your Web services. Even if you are using the REST approach, having an easily accessible XML schema will encourage reuse of your services.

Avoiding the pitfalls Kyle describes seems like common sense. Unfortunately, our industry has proven that unless SOA implementations are well understood and governed, we will continue to make the same mistakes over and over again.

About "What are the common mistakes to avoid when implementing XML and Web services" This article is shared here, I hope the above content can be of some help to everyone, so that you can learn more knowledge, if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.