A Peek into the WSO2 WSAS Architecture
By Afkham Azeez
- 25 Feb, 2007
WSO2 WSAS for Java is an Open Source project that is licensed under the
WSO2 WSAS for Java, packages a number of popular Apache Web services components. Seamlessly integrating these components in not a trivial task for a Web service developer. WSO2 WSAS for Java takes this burden off the shoulders of the Web service developer and provides a clean and simple interface. By using WSO2 WSAS for Java, developers can create Web services from very simple Plain Old Java Objects (code first development approach) or even start with a WSDL document (contract first development approach). In addition, the AJAX based Management Console simplifies the development, deployment, and management of Web services. An understanding of the WSO2 WSAS architecture helps the Web service developer to appreciate the functionality provided by WSO2 WSAS for Java, as well as use it more effectively as a tool for building Web services. It also helps contributors to make more effective contributions.
WSO2 WSAS and Apache WS Components - How are they related?
Fig. 1- WSO2 WSAS Components
Fig. 1 above clearly shows the relationship between WSO2 WSAS and other Apache WS Components, as well as some other popular Open Source components.
At the core of WSO2 WSAS for Java is the popular Apache Axis2/Java Web services engine, which has proved to be one of the fastest Java Web service engines. Apache Axis2 has an extensible messaging engine architecture, which enables plugging-in of other quality of service modules (QoS).
In addition to the above, there are several other QoS modules that are included with WSO2 WSAS for Java. viz.,
- WSO2 Mex - This is the implementation of WS-MetadataExchange. The WS-MetadataExchange specification describes a metadata retrieval protocol for Web services.
- WSO2 XFer - This is the implementation of WS-Transfer. The WS-Transfer specification describes a general SOAP-based protocol for accessing XML representations of Web service-based resources.
- WSO2 Throttle - This module is used for controlling client access to Web services. Access throttling can be configured at a global level, service level, or operation level.
- WSO2 Statistics - This module is used for gathering system, service, and operation level statistics.
- WSO2 Tracer - This module is used for capturing incoming and outgoing SOAP messages.
Apache AXIOM is the default XML Infoset representation used both in WSO2 WSAS and Apache Axis2. One of the reasons for the high performance of WSO2 WSAS is the usage of a pull-based XML object model.
An Apache Derby embedded RDMBS ships with WSO2 WSAS for Java. This includes a database which stores:
- System configuration information
- Service information
- QoS module information
- Transport information
- Security information
- User information
Initially, the above information is gathered from the static descriptors such as axis2.xml, services.xml, module.xml and the WSO2 WSAS for Java server.xml. Using the Management Console, one can easily tweak the system, and these changes are persisted in the database.
The Hibernate Object-Relational Mapper facilitates the switching of the underlying database. In order to switch to a different RDMBS, or database, the wso2wsas.hibernate.cfg .xmlfile has to be changed appropriately, and WSO2 WSAS has to be restarted.
WSO2 WSAS for Java comes in two flavors. That is, a stand-alone edition,which embeds a Jetty servlet container, and a servlet edition, which can run within any J2EE servlet container. Therefore, it caters to users who simply require a lightweight Web services container, as well as to users who already have some infrastructure in place and wish to extend their containers to support fast, secure, and reliable Web services.
Top Level Architecture
Fig. 2 Top Level Architecture
Fig.2 above depicts the top level architecture of the components which are specific to WSO2 WSAS for Java. The relationships to third party components have been intentionally left out in order to focus on the WSO2 WSAS for Java specific architectural design. We will discuss each of the components in detail.
When WSO2 WSAS for Java starts up for the first time (virgin boot-up), the Configurator will pickup static data from two XML files, viz., axis2.xml and the WSO2 WSAS server.xml. This data will be communicated to the Data Access component so that the database can be populated. During subsequent boot-ups, the Configurator will pick up most of the configuration from the database. Some of the configuration details will be picked up from the XML configuration files. Note that, in general, subsequent changes to theXML configuration files will not be reflected in the database. The principal concept behind this design is that the database overrides the static configuration files. The Configurator will feed in the configurations to the Axis Config and WSAS Config components, which can be accessed by Axis2 modules and services during different operations.
The WSO2 WSAS deployment mechanism is invoked whenever Axis2 modules or services are added to the system or are removed from the system.
When a service is deployed for the first time, the Deployment component will be notified by the Axis2 deployment engine, and the Deployment component will extract information from the AxisService object, and will pass this information to the Data Access component, which will keep this information in the database. Some of the information extracted from AxisService include, service parameter, service policies, and engaged modules. On subsequent deployments of this service, the relevant information is extracted from the database and injected into the AxisService object. Once again, the principal to keep in mind is: Database overrides the XML configuration file, in this case, the Axis2 services.xmlfile. When a service gets removed from the system, the Deployment component will once again be notified by the Axis2 deployment engine, which will in turn, notify the Data Access component to remove the service from the database.
Similarly, when a quality of service module gets deployed, the Axis2 deployment engine will notify the WSO2 WSAS Deployment mechanism, passing it an AxisModule object. Some information extracted from the Axis Module is module policies and module parameters. Again, the database overrides the XML file, in this case, the Axis2 module.xml file.
In order to understand the Axis2 deployment architecture, see
Fig. 3 Data Access Architecture
The Data Access component consists of three layers. At the lowest layer, Hibernate Data Objects (DO) can be found. In the case of WSO2 WSAS, these DOs are directly mapped to database tables and constraints. Since DOs are plain old Java objects (POJO), they are used by other layers as well as components in WSO2 WSAS. Above the DO layer is the Data Access Object(DAO) layer. This layer manages the Hibernate session and transactions. In general, for each major Hibernate DO such as ServiceDO or ModuleDO, a corresponding DAO can be found. A DAO may be responsible for handling several DOs, e.g., the ServiceDAO handles ServiceDO, ServicePolicyDO and ServiceParameterDO. Therefore, DAOs are coarse grained while DOs are fine grained. The DAO layer is supposed to be accessed only by the Persistence Manager layer. Other components should never access these DAOs. This way, the rest of WSO2 WSAS is independent of Hibernate and other database related technologies.
The idea is that, the current Data Access layer can be easily removed from WSO2 WSAS and replaced with a different data handling mechanism, without having a major impact. Also, different data access implementations can be easily plugged in with this design. The Persistence Manager layer completely abstracts the database and related technologies from the rest ofWSO2 WSAS, and exposes a business interface. For example, getUser(username) is one of the methods in Persistence Manager. It is transparent to the caller how the Persistence Manager gets the user information. Currently it is from the database, but it could be easily changed to get this information from an LDAP server.
Fig. 4 AJAX Client Architecture
WSO2 WSAS for Java includes the Admin module, which handles authentication and authorization for the Management Console, the Tracer module, which traces incoming and outgoing SOAP messages, and a Statistics module, which gathers system and service statistics. These modules are generally transparent to the Web service developer.
These services provide back-end functionality for the Management Console. For each identified area of administration, a service has been defined. For example, ServiceAdmin handles all administration functionalities pertaining to Axis2 services, and ModuleAdmin handles all administration functionalities related to Axis2 modules. Some admin services, such as the StatisticsService, are not directly called by the Management Console front-end. They are helper services for other front-line Admin services. One thing to note is that all the Admin services require the Apache Addressing module to be engaged to facilitate asynchronous communication with the AJAX clients.
WSO2 WSAS for Java is an Open Source Web services Application server that enables developers to write secure and reliable Web services effectively and efficiently. This article described the architecture of WSO2 WSAS, and therefore, you can take a look at the source code and make contributions to make WSO2 WSAS for Java an even better tool.
Afkham Azeez, Product Manager, WSO2 WSAS for Java, WSO2 Inc. azeez at wso2 dot com