WebService design and Pattern

Posted on idior category: design, Web Services & SOA This article is a translation (originally in devx). It may be helpful for anyone who wants to know about WebService.

As a new technology, WebService emerged in front of us. It was born to solve application collaboration on different platforms. At present, almost every vendor wants to develop WebService applications. However, if they lack a deeper understanding of WebService, they cannot solve some important problems well in the design phase, the final system will inevitably be a product with low efficiency and no reliability.

When designing a WebService application, consider the following: l manage the synergy with external systems l master the underlying transmission model l provide security policies suitable for applications l plan the deployment of the following issues, we will discuss in detail how these design requirements and some common patterns are applied to the WebService model. During the discussion, you will find out how the new WebService technology is combined with our previous software development. L The most basic purpose of the standard to provide collaborative capabilities WebService is to provide collaborative capabilities for different application systems on different platforms. In order to make a company's network application achieve the highest efficiency, it should be able to achieve seamless interaction with its partners, suppliers and WebServices between customers. If interactions cannot be easily implemented between many WebServices, the efficiency of the application will be greatly reduced. However, in reality, this situation is very likely to happen. Different companies have different understandings of their businesses, that is, when they have the same understanding, they may also express the same concept in different forms, specifically, the same data may be represented in different XML. For the above reasons, the coordination problem should be considered when designing the application architecture, rather than waiting for future changes. WebService consists of the following technologies: SOAP (Simple Object Access Protocol), WSDL (Web Service Description Language), and UDDI (Universal Description, discovery and integration ). Here we will not study these technologies in detail, but reveal some of their important features. These features need to be carefully considered in the design of WebService. WSDL is the key to implementing collaboration. It provides a contract for interaction with new and old applications. This technology allows organizations to set standards on external interfaces of services without considering the specific implementation of each organization. In short, it implements the separation of WebService interfaces and implementations. This makes it easier to develop standards. In addition, based on this interface description, many tools can automatically generate a client Code This reduces the workload of developers and frees most developers from writing SOAP message passing code. Soap is the transmission layer for message transmission between various WebService components. Therefore, soap should be a transparent collaboration technology. However, because many SOAP implementation methods are contrary to the standard, either new extended functions are added or some standard functions are deleted. Due to different levels of support for the soap standard, the collaboration capability of WebService is greatly reduced, making it more difficult to achieve collaboration. Based on this situation, when developers need to run WebService on different platforms, they need to understand the specific situation and encode it to solve this inconsistency. If all SOAP implementation organizations can follow the standards, developers of WebService do not need to consider using the underlying platform of the WebService. Even so, the collaboration between different soap implementations is quite difficult, because there are a lot of differences in the formulation of collaboration standards, and some organizations are currently working on standards, such as soap builders and WS-I. However, currently, WebService developers only implement different implementations for different platforms, increasing the development cost and burden. L understanding the transmission model soap is not a completely transparent solution. It hides some complicated implementation details. WebService developers must have a deep understanding of soap, the underlying transmission mechanism and model, and how soap is implemented. In some simple applications, some tools can help WebService developers generate SOAP message passing code, but this is only effective in the simplest applications. The real situation cannot be so simple, and you may need to handle it in some aspects (this is common in actual development). At this time, you need to directly manipulate the SOAP message passing code and some underlying XML content. Therefore, WebService developers need to have a deep understanding of the content at the soap and XML layers. When developing WebService interfaces, do not think that XML technology is used. The collaboration problem is solved. XML is not a panacea for solving integration problems. Standards are also required here, and an industry-recognized vocabulary is required. The introduction of XML technology in your design framework alone does not guarantee the coordination of the system. XML is only a language used to describe data. xml itself does not provide semantics to understand data. Just as English and German both use Latin letters, but their semantics is different. Even if you use the same language, you cannot guarantee good collaboration. For example, your company may use order to describe an order, but your partner may use purchase_order, and another partner may not. You cannot force all your partners to use the same words as you. Therefore, a technology is required to act as a translation between numerous descriptions. XSLT is a technology used for conversion in different languages. XML can be used with XSLT to solve the coordination problem. L Dom. many of the web service development environments of sax free developers from parsing and processing underlying XML documents. They provide automated or convenient tools to make this process very simple. However, for some WebService applications with special requirements, such as applications with better flexibility or high speed requirements, XML documents must be processed manually. At this time, the choice of Dom and sax, the two XML parsing models, will become an important issue. Dom uses a tree chart to parse XML documents, while sax uses more event-driven models. Dom maps the XML document into a tree, and then processes the document through a series of tree-related operations. This method has many advantages. First, developers can easily understand it. Using a tree is the most common method for developers. Dom is most commonly used when XML needs to be modified frequently in the service. Of course, Dom also has its disadvantages. When processing XML documents, it needs to load the entire document, regardless of whether or not you need to modify it is only a small part. Therefore, its running efficiency and memory usage are obviously unacceptable, especially for large XML documents. Sax uses an event-driven model to process XML documents. Through a series of events to complete XML parsing, you can only care about the events you want to handle. When these events occur, the corresponding callback function will be called to notify you. This method can greatly improve the efficiency of XML document parsing. However, its disadvantage is that it is difficult to use and there may be some problems in handling the same document multiple times. All in all, Dom is more suitable for processing XML files of the document type, while Sax is suitable for operations that want to directly map the XML structure into an object in your system. (For example, you can map an XML structure directly to a class in Java) or perform operations that target special tags in XML files. L document exchange vs. RPC model the two interaction modes should be carefully considered in the initial design of the application architecture, because it will largely determine the System Coupling Degree. Remote Procedure Call is essentially a call to a remote method. Although WebService is XML-based, you can still use the remote method to call this mode to implement WebService, especially in the simple request model. In this process, the XML file in the transmission describes more information about remote methods, such as method names and method parameters. The document exchange method is not a remote method ing in XML files, but a complete self-contained business document compared with rpc. When the Service side receives this document, perform preprocessing (such as vocabulary translation and ing) first, and then construct the returned message. In the process of constructing the returned message, it is often no longer a simple method call, but multiple objects collaborate to complete the processing of a transaction and then return the result. The difference between the two methods is similar to the different handling methods for making calls and sending emails. Currently, many automated tools are provided for the first method so that remote method calls can be easily completed. The latter method lacks the support of a series of tools and needs to be manually completed by developers. However, we recommend that you use document exchange here. It has the advantages that RPC does not possess in the following aspects. By using the document method, you can fully use the functions of the XML file to describe and verify a business document. In the RPC model, XML is only used to describe method information. In document mode, there is no need for close conventions between the customer's service providers, while the RPC model requires the customer to be closely connected with the service provider. Once the method changes, the client needs to make corresponding changes. This does not meet the requirements of low coupling systems, but is flexible in document exchange. Because business data is self-contained, it is obvious that the document model is more conducive to asynchronous processing. L using the design pattern can obviously play a considerable role in designing WebService. The main purpose of the design model is to provide existing mature design solutions to solve the similarity problem in a similar environment. Here, we will only mention some frequently-used modes, so that we can understand the role of the pattern in WebService. Adapter: provides a different interface for the internal system. Fa C Ade: encapsulates complicated internal implementations and provides a series of simple interface proxies: as proxies for other objects, instead of providing the service adapter mode, it is used to convert the interface of a component into what the customer needs. Here the customer is WebService. A common situation is to package an old system into a WebService. For example, we are using a J2EE platform, and a C ++ system has implemented some functions. Now we need to publish it as a WebService, therefore, we need to use JNI technology to create an adapter, provide a Java interface for the original C ++ component, and then convert it to WebService. The fa c Ade mode is used to build coarse-grained services. It encapsulates fine-grained services and provides a simple interface for complex systems. In J2EE, Session Bean is like a fa C Ade, while Entity Bean is a fine-grained service. In the same way in WebService, you can use the fa-ade mode to fully utilize the functions of existing components. The proxy mode is used to act as a proxy for other objects. Similar to the intermediary, it transfers processing work from one object to another. In WebService, it is mainly used to hide the SOAP message construction process. It can also be used to create a simulated object (Mock object. The above are just some patterns that can be used for WebService development. If you are skilled in applying these models to WebService development, you will find that developing WebService applications will look like a special object-oriented design. L Security WebService is used in a wide range of fields as a convenient service and has also become a good dish for hackers. Here, this article will briefly introduce the improvements that can be made to WebService security. Security in WebService is divided into the following three aspects. Transmit SSL/HTTPS encrypt the connection, not transmit data message data encryption (XML encryption) digital signature (XML-DSIG) the underlying architecture is most likely to be added to your WebService application when using the Application Service Security Mechanism for transmission. It uses the existing SSL and HTTPS protocols, you can easily obtain the security during the connection process. However, this security implementation method has two weaknesses. First, it can only ensure the security of data transmission, rather than the security of data itself. Once data arrives somewhere, it can be viewed by anyone. In WebService, a piece of data may arrive at multiple places, but the data should not be viewed by all recipients. Second, it provides either full or no protection. You cannot choose which part of the data to be protected. This kind of selectivity is also frequently used in WebService. The second layer protects messages. You can use the existing XML security extension standard to implement the digital signature function, so that your message is not modified by a specific party. XML file encryption technology enhances the security of WebService to a greater extent. It can customize whether the data can be viewed by the recipient after transmission, further improving the security after transmission, the industry is constantly developing security standards for WebServices, such as SAML and WS-Security. The last layer of protection relies on the security of the underlying architecture, which is more from the protection of the operating system and some middleware. For example, in J2EE, the Web service application server is hosted. Currently, many J2EE application servers support Java authentication and authorization Service (JAAS), which was recently added to j2se 1.4. It is natural to use the server hosting WebService to implement some security mechanisms. Another security method that uses the underlying architecture is to create an independent server responsible for security, and users and creators of WebService need to gain security trust.

Recommended Materials
Web Services Security