When designing WebService applications, the following points must be considered:
l Manage synergy with external systems
l Master the underlying transmission model
l Provides security policies that are adapted to the application
l Professionally planned to deploy
Hereinafter, it will be applied to the WebService model to discuss the WebService model on these related design needs and some common modes. In the discussion, you will find how the new technology of WebService is combined with us in previous software development.
l The standard provides collaborative ability
One of the most basic purposes of WebService 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 Understand the transmission 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 the initial consideration of the design of the application architecture, as it will greatly determine the degree of coupling of the system.
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 design patterns
The design pattern obviously can play 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 for the internal system
Façade: Package complex internal implementation, provide a series of simple interfaces
Proxy: As a proxy for other objects, instead of providing services
The Adapter mode is used to transform a component to the customer needs. 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. It can also be used for the creation of the mock object.
The above is just some models that can be used for WebService. If you skilled these modes to WebService development, you will find the development of WebService applications that will seem to be a special object-oriented design. l security
WebService has been used as a convenient service, and it has become a gourmet of hackers. Here, this article will make a brief introduction to the current improvement of WebService security.
Security in WebService is mainly divided into the following three aspects.
Transfer SSL / HTTPS to connect to connection, not transfer data
Message Data Encryption (XML-DSIG) Digital Signature (XML-DSig)
Bottom architecture utilization application service security mechanism
Safety during transmission is the most easily added to your WebService app, which can easily get safety during connection with existing SSL and HTTPS protocols.
However, this safety implementation method has two weaknesses. First, it can only guarantee the security of data transmission, not the security of the data itself, once the data reaches a place, then it can be viewed by anyone. In WebService, a data may reach multiple places, but this data should not be viewed by all recipients. Second, it provides that it is either to protect, and you cannot choose which part of the data is to be protected, and this optionality is also usually used in WebService.
The protection of the second layer is the protection of the message itself. You can use the existing XML security extension criteria to implement digital signatures, thus ensuring that your message is from a specific party and has not been modified. The encryption technology of the XML file enhances the security of WebService to a greater extent. It can customize the data to be transmitted, can be viewed by the recipient, further improve the safety after transmission, the industry is constantly setting WebService security standards For example, SAML and WS-Security.
The last level of protection is to rely on the safety of the underlying architecture, which is more protected from operating systems and certain middleware. For example, in J2EE, host the WebService application server. There are currently a lot of J2EE application servers support Java Authentication and Authorization Service (JaaS), which is recently added to J2SE 1.4. This is a natural practice using the server who hosts WebService. Another safety method using the underlying architecture is to do an independent server, WebService users and creators need to achieve security trust.
