This article is a film (the original text is in Devx, which can be remembered), and some friends who want to know about WebService may be some help. Among them, there are some models of the application, but individuals feel too simple, forget everyone to think about it, publish some opinions.
As a new technology, WebService appears in front of us, it is used to solve the collaboration of applications under different platforms. At present, almost every vendor has to develop WebService applications, however, if it lacks a deeper understanding of WebService, it is impossible to deal with some important issues in the design phase, then the ultimately completed system is inevitably efficient, no reliable products . When designing the WebService application, the following points must be considered: l Management Good synergy with external systems L Mastering the underlying transmission model L provides information about the security policy L planned to apply to the application below, this will be Several related design needs and some common modes are applied to the WebService model deployment detailed discussion. In the discussion, you will find how the new technology of WebService is combined with us in previous software development. L The standard provides a collaborative ability WebService's most basic purpose is to provide synergistic work capabilities of different application systems in various platforms. In order to make a company's network application to achieve the highest efficiency, there is a seamless interaction between its own and its partners, suppliers, and customers. If you don't easily interact between many WebServices, the efficiency of the application will be greatly reduced. However, this situation is very likely to appear in reality. Since each company understands the business understanding, it is understood that the same concept may also be manifessed in different forms, in particular, for the same data, different XML representations. Due to the above reasons, the problem of synergy should be considered when designing the application architecture, rather than left later. WebService is mainly composed of the following techniques, 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 considered in the design of WebService. WSDL is the key to achieving collaborative capabilities, providing a contract for interaction between new and old applications. This technology enables individual organizations to set standards to the external interface of the service without considering the specific implementation of organizations. Briefly, it achieves the separation of the interface and implementation of WebService. This makes it easier for standard development. Also, based on this interface description, many tools can automatically generate client code, reduce the developer's workload, and make most developers get rid of writing the SOAP messaging code process. SOAP is a transport layer that implements a message between each WebService component. Therefore, SOAP should be a transparent synergistic technology. However, due to many SOAP implementation methods, it is either a new extension feature either deletes some standard functions. Since the support level of SOAP standards is different, it makes it difficult for WebService's collaborative capacity to achieve collaborative difficulties. Based on this situation, when the developer needs WebService running on different platforms, it is necessary to understand and correspondingly encoded and corresponding to this inconsistency. If all SOAP implementations can follow standards, then WebService developers do not need to consider using the underlying platform for this Webservice. Despite this, different SOAP achievement is quite difficult because there is a lot of differences in the formulation of collaborative standards, and some organizations are currently developing, such as SOAP Builders and WS-I.
However, the WebService developer is now improving to different implementations for different platforms, making the development cost and burden. L Understanding the Transport Model SOAP is not a completely transparent solution, which hides some complex implementation details. WebService developers must understand SOAP, understand the underlying transport mechanism and model, so that SOAP is implemented. In some simple applications, some tools can help webservice developers generate the code passed by SOAP messages, but this is only valid in the simplest application. The real situation cannot be as simple as possible, you may have special processing in some ways (this situation is very common in actual development), this time you need to directly manipulate SOAP messages, and some underlying XML content. Therefore, WebService developers need to deepen the content of the SOAP and XML layers. When developing WebService interface, don't think that using XML technology, collaborative problems will be solved, XML is not a spiritan medicine that solves the integrated problem. It also needs a standard development here, requiring a glossary recognized in the industry. Introducing XML technology only in your design framework does not guarantee that the system has synergy, XML is just a language used to describe data, and XML does not provide semantics to understand data. Just as English and German use Latin letters, but their semantics are not the same. Even if you use the same language, you can't guarantee good collaboration. For example, your company may use ORDER to describe a order, but your partner may use Purchase_order, and another partner may not be the same. You can't force your partners to use the same vocabulary as you. It is therefore necessary to have a technique that can act as a translated role between many descriptions. XSLT is such a technology that is used for conversion of different languages. With XSLT, use XML to solve the problem of synergy. L DOM vs. SAX Many WebService development environments, liberate developers from the underlying XML document parsing and processing, they provide automation or very convenient tools, making this process simple. However, for some of the WebService applications with special requirements, such as a better flexibility or special use of speed requirements, you need to manually process XML documents. At this time, two XML parsed models - Dom and SAX selection will become an important issue. The DOM uses a tree map to parse the XML document, while SAX is more use of an event-driven model. The DOM first maps the XML document into a tree and then processes this document by using a series of operations related to the tree. This approach has a lot of benefits, first developers easy to understand, using a tree This is the most common for developers. DOM is most commonly used in XML to require frequent modifications in Service. Of course, DOM also has its shortcomings. When processing XML documents, it needs to load the entire document, regardless of whether you need to modify it is just a small part. Therefore, its operating efficiency and the use of memory are obviously unacceptable, especially in the face of large XML documents. SAX uses an event-driven model to process an XML document. Through the trigger of a series of events, complete the parsing of XML, you can only care about the event you want to process, when these events occur, call to the corresponding callback function to notify you. This way can greatly improve the efficiency of XML document parsing to a large extent. However, its disadvantage is that it is difficult to use, and there are some problems with multiple processing of the same document. All in all, DOM is more suitable for processing the document type XML file, while SAX is suitable for the operation of an object that wants to map the XML structure into an object in your system. (For example, a class of XML structures directly mapped into Java) or the operation of special TAG for XML files.
l Document exchange vs. RPC model These two interactions should be in addition to the application of the application architecture, as it will determine the degree of coupling of the system to a large extent. RPC (Remote Procedure Call) is essentially a call of remote methods. Although WebService is based on XML, you can still call this mode using a remote method to perform WebService implementations, especially in the simple request corresponding model. During this process, more of the XML files in the transmission is information about the remote method, such as method name, method parameters, and the like. And the document switching method, compared to the RPC in the XML file is not a map of the remote method, but a complete self-contained business document, when the service is received, advances, advances (such as vocabulary) Translation and mapping) and then construct a return message. During this configuration returns a message, it is often no longer a way to simply call, but multiple objects collaborate to complete the processing of a transaction, and then return the result. The difference between these two methods, similar to different processing methods with calling and email. At present, a number of automated tools provide a lot of automated tools for the first method, making it easy to complete, and the lack of methods lack support for a series of tools, requires developers to complete. Despite this, it is also recommended to use documentation. Because it has the advantages that RPC has RPC in the following aspects. With documentation, you can take advantage of the functionality of the XML file to describe and verify a business document, and XML in the RPC model is only used to describe the information. Using documentation, the RPC model needs to be closely connected between the client's service provider, and the RPC model requires the client and service provider to closely connect, once the method changes, the client needs to do corresponding changes. This does not meet the requirements of the low coupling system, and in the document switching mode, it is much flexible. Since business data is self-contained, it is clear that the document model is more beneficial to use asynchronous processing. L Using the design mode design mode, it is obviously a considerable role when designing WebService. The main purpose of the design model is to address some of the more mature designs in some similar environments. Here, only simply refer to some common modes, let us know the role that the mode can play in WebService. Adapter: Provides a different interface façade: package complex internal implementation, providing a series of simple interface proxy: as a proxy for other objects, instead of providing service Adapter mode to convert a component interface into a customer The look, the customer here is WebService. A common situation is to package the original old system into a WebService. For example, now use J2EE platform, and there is a C system that implements some functions. Now you need to release it as a webservice, then you need to use JNI technology to make an adapter, provide a Java interface for the original C component. Then transform to WebService. The Façade mode is used to build a coarse granular service, which is packaged in fine-grained services, providing a simple interface for complex systems. In J2EE, session bean is like a façade, and Entity Bean is a fine-grained service. Like the WebService, using the Façade mode can play the function of the existing components. The Proxy mode is used to act as an agent of other objects, similar to the role of the intermediary, and pass the process from an object to another. In WebService, it is mainly used to hide the process of SOAP messaging.
