This documentation is for WSO2 Application Server 5.2.0. View documentation for the latest release.
Service Group Dashboard - Application Server 5.2.0 - WSO2 Documentation
Skip to end of metadata
Go to start of metadata

A Service Group is a convenient way of deploying multiple services in one service archive file. There is a logical relationship between the services at runtime. The only difference in the services.xml for a service group and a single service is its root element. For a service group, the root element is <serviceGroup>, and we have multiple <service> elements inside the <serviceGroup> element. For example,

   <service name=Test1>
   <service name=Test2>

The steps below show how to access and manage service groups.  

  1. Log in to the management console and select Services > List under the Main menu . 
  2. In the Deployed Services page that appears, click the deployed service group(s) link to access the groups.
  3. The Deployed Service Groups window opens. Click a group to go to its dashboard.  
  4. A typical service group dashboard contains three panels as follow:


The Services Panel lists all the services included in the group. For example,

From here you can:


The following functions are available to manage service groups:


Managing the parameters of the service group   

Parameters can be defined inside the service's XML as an immediate child element of the service element. These parameters can be accessed using the message context (at the runtime), AxisService or AxisOperation. A parameter has two attributes:

  • name - Mandatory attribute that specifies the name of a parameter
  • locked - Optional attribute. A locked attribute specifies whether we allow the parameter value to be overridden by a child node in the hierarchy

For example, if a parameter is added in the axis2.xml file with the locked attribute set to True, then at the even of a service trying to add another parameter with the same name, it throws an exception.

You can add a new service group parameters using the Add New... button.

Managing the module engagements   

Sometimes, you want to engage the WS-security module into a service in order to run it. Engaging a module is just a matter of adding a module tag into the service's XML. If the module is available, it will be engaged, else it will be a faulty service.

Follow the steps below to engage a module into a service group.

  1. In the Actions panel, select Modules.  
  2. Select a module and click engage . WSO2 DSS provides the following modules for service groups.
    • WSO2Caching - Provides server-side and client-side caching implementation. See Configuring the wso2caching Module. 
    • WSO2xfer - Provides an implementation of WS-Transfer
    • WSO2Throttle - Provides facility to control client access to web service engine. See Configuring the wso2throttle Module.
    • WSO2mex - Provides MetadataExchange services for any services that the module is engaged to
    • rampart - Provides WS-Security and WS-SecureConversation functionality for Axis2 and is based on Apache WSS4J, Apache XML-Security and Apache Rahas implementations
    • addressing - Provides an implementation of WS-Addressing
    • sandesha2 - Provides an implementation of WS-ReliableMessaging. See Configuring the sandesha2 Module.
    • rahas - Provides capability to enable STS in a service. It adds the Request SecurityToken operation to the service that the module is engaged to.

Creating an archive file   

Using the Create Service Archive option, you can create an Axis2 archive file out of all the configurations available to a given service group. Before deploying the service in a production environment, you can test the validity of its functions such as parameters, module engagement, polices etc.

This feature archives only an .aar service at the moment. Also, it only creates an archive to a service group; not to an individual service. Because a service group is mapped to a physical .aar, it is logical to create an archive to an entire group.

  • No labels