Web Service Framework. It also demonstrates the experience gained from the axis 1.x series and the development in the Web service field in the last two years. One of the main reasons for introducing axis2 is to get better performance in terms of speed and memory-but some new features and features have been added. Most of the new features are designed to improve the ease of use of axis2, while retaining the space for extended functions in various ways. Most of the new functions are added to the following main areas:
New XML Object Model (axiom)
Compared with Axis 1.x, axis2 is built on a brand new architecture. One of the main reasons for introducing axis2 is to obtain an appropriate XML processing model. Axis 1.x uses dom as its XML representation mechanism, but the disadvantage of Dom is that the complete object hierarchy needs to be saved in the memory (corresponding to the incoming message ). This is not a problem for small messages, but it is a problem for large messages. To overcome this problem, axis2 introduces a new XML representation as its basis.
Message-based core
The core of axis2 is the pure soap processing engine, which does not know data binding, transmission, and WSDL. The core function of axis2 is to process and deliver messages to the target application. Like axis 1.x, axis2 also has the concept of a handler that extends its main functions.
Axis 1.x does not have the concept of asynchronous web service calling. It is completely bound to request-response calling, but it is another scene in axis2. The axis2 architecture supports both client and server support asynchronous calls. At the same time, axis2 also supports request-response style calls, but this will be done in two asynchronous calls. In axis2, messages that enter the system may or may not respond. You should note that aixs2 supports all eight message exchange patterns (MEP) defined in WSDL 2.0 ).
Axis2 has the concept of stream. A stream is a collection of stages, and a stage is a collection of processing programs. The number of associated streams of the MEP called Based on the given method may change.
Deployment model
In axis 1.x, you must manually call the management client, update the server class path, and restart the server to apply changes. This troublesome deployment model is definitely an obstacle for beginners. Axis2 has been well designed to overcome this disadvantage and provides flexible, user-friendly, and easy-to-configure deployment models. Axis2 deployment introduces a concept similar to the Java 2 Platform Enterprise Edition (J2EE) deployment mechanism, developers can package all class files, library files, resource files, and configuration files together as archive files and place them in the specified location in the file system.
Module Architecture
In axis 1.x, to add a handler, you must first change the global configuration file and then restart the system without changing the dynamic method of the handler chain at runtime. To overcome this problem and add new features, axis2 introduces the concept of Web Service extension or module. The main task of the module is to expand the core functions. In axis 1.x, you can add a handler to the handler chain to achieve this goal. Compared with the axis 1.x handler chain, the advantage of using modules is that you can add new modules without changing the global configuration file. At the same time, the module is a self-container that can contain processing programs, third-party libraries, module-related resources, and module configuration files.
Xfire vs axis
Xfire is a new-generation WebService platform tied with axis2. This is also called the next generation because it:
1. support a series of new Web service standards, such as jsr181, wsdl2.0, jaxb2, and WS-Security;
2. Use Stax to explain XML, which improves the performance. Xfire uses woodstox for Stax implementation;
3. Easy to use and quick service release from pojo;
4. Spring combination;
5. Flexible binding mechanisms, including the default aegis, xmlbeans, jaxb2, And Castor.
Performance Comparison Between xfire and axis1
Xfire is 2-6 times faster than axis1.3
The xfire response time is 1/2 to 1/5 of axis1.3.
Comparison between xfire and axis2
Although xfire and axis2 are both new-generation WebService platforms, version 1.0 of axis2 is not a stable version. After xfire donated Apache, someone thought axis2 would kill. In the eyes of many people, axis2 is not in the pojo format. Dan diephouse proves that xfire is more market-ready than axis. Using xfire for WebService development is much easier than axis2.
Axis vs cxf
In the SOA field, we believe that Web Service is the building block of the SOA system ). For service developers, neither axis nor cxf is unfamiliar. Both products are open-source Web service development tools under the Apache incubator. The latest version of axis2 is 1.3.cxf and has now reached version 2.0.
Both frameworks are developed from existing open-source projects. Axis2 is developed from the axis1.x series. Cxf is a combination of xfire and celtix projects. Axis2 is re-implemented from the underlying layer, using a new scalable and better module architecture. Cxf has also deepened the xfire and celtix development tools.
The exit of the new product caused several problems. Is it possible to migrate existing applications using axis 1.x, xfire, and celix to a new version. If a developer is sure to migrate its application to the new framework, which one should he choose? On the contrary, if a developer decides to develop a new Web service from scratch, which one should he use? Which of the two frameworks is better?
For system migration, it may not be difficult to migrate to the new framework. Both axis and cxf provide migration guidance. Provides developers with some migration skills and experience. However, for such migration, neither of the two open-source projects provides a migration tool. For such migration, it is worth looking for all feasible solutions. Both axis2 and cxf have different WebService development methods. Each method has a considerable number of advocates.
Comparing axis2 and cxf with a comparison matrix makes sense. Both projects are not mature enough, but the main differences are as follows:
1. cxf supports WS-Addressing, WS-Policy, WS-RM, WS-Security, and WS-I basic profile. Axis2 does not support WS-policy, but promises to support it in the following versions.
2. cxf supports spring well. Axis2 cannot
3. axis2 supports a wider range of data, such as xmlbeans, jibx, jaxme, and jaxbri, and bind them to ADB. Note that both jaxme and jaxbri are experimental. Cxf only supports jaxb and aegis, and the default value is jaxb 2.0.
4. axis2 supports multiple languages-in addition to Java, it also supports C/C ++.
Comparing the Web service development methods of these two frameworks is equally important as comparing their features. From the developer's point of view, the features of the two frameworks are quite different. The development method of axis2 is similar to that of a small Application Server. The axis2 development kit should be deployed to servlet containers in the form of war, such as Tomcat, these containers can be used to monitor and manage the Web service at work. The Web administrion module of axis2 allows us to dynamically configure axis2. a new service can be uploaded, activated, invalidated, and Web Service parameters can be modified. The management UI can also manage one or more running services. One drawback of this interface-based management method is that all the parameters modified during the runtime cannot be saved, because after the restart, all the modifications you have made will become invalid.
Axis2 allows itself to publish Web services as independent applications, and provides a large number of features and a good model. This model can be implemented through its own architecture (modular architecture) add new features constantly. Some developers think this method is too cumbersome for their needs. These developers prefer cxf.
Cxf focuses more on the developer's efficiency (ergonomics) and embedded capabilities (embeddability ). Most configurations can be completed through APIS, replacing the complicated xml configuration file. Spring integration is often mentioned, cxf supports spring, cxf's API, and spring configuration files. Cxf emphasizes the code-first design (Code-first design) and uses simple APIs to make it easier to develop services from existing applications.
Whether axis2 or cxf is selected, you can get a lot of help from the open-source community. Both frameworks are provided by commercial companies, wso2 provides axis2 support, and Iona provides cxf support. Both companies have active developer communities. Axis2 appeared earlier, and cxf was catching up quickly. If you need multi-language support, select axis2. If you want to focus on Java and integrate with spring, cxf is a better choice, especially embedding web services in other programs.
This article from: http://blog.csdn.net/jsfn_dai/archive/2009/09/03/4510289.aspx