Accessing Service Groups

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,

<serviceGroup>
   <service name=Test1>
     ...
   </service>
   <service name=Test2>
     ...
   </service>
</serviceGroup>

Follow the instructions below to access and manage service groups. 

Accessing Service Groups

1. Log on to the product's management console and select "Services -> List" under the "Main" menu.

2. The "Deployed Services" page appears. Click on the "deployed service group(s)" link to access the Deployed Service groups.

3. In the "Deployed Service Groups" page, click on the necessary service group. For example,

4. The "Service Group Dashboard" page appears. For example,

It contains three panels as follow:

• Service Group Details
• Services
• Actions

Service Group Details  

The "Service Group Details" panel shows the name of the service group.

Services

The "Services" Panel lists all the services included in the group.

From here you can:

• Click a service's name and view its dashboard.
• View a service's WSDLs.
• Test the service using the "Try this service" link.

Actions  

The following functions are available to manage the service groups:

• Managing the parameters of the service group.
• Managing the module engagements.
• Creating the archive file.
• MTOM - By default, MTOM is set to optional. You can set it to True or False. A change of value causes all underline services and operations to change the way they correspond to MTOM.

Managing the Parameters of the Service Group  

1. In the "Service Group Dashboard", select "Parameters."

2. Parameters can be defined inside the services 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 - The mandatory attribute which specifies the name of a parameter.
• locked - The optional attribute. The idea of a "locked" attribute is to express 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 setting the "locked" attribute to "True," then at the even of a service trying to add another parameter with the same name, it gives an exception.

The WSO2 Carbon provides an easy method to generate the Service Group parameters.

Click on the "Add New..." button to generate a new service parameter.

3. Enter the parameter's name and click "OK" to add the parameter to the list.

4. Enter the parameter's value and click on the "Update."

5. If you want to delete a parameter, click on the "Delete" button.

6. Confirm your request by clicking "Yes" in the message that prompts.

Managing the Module Engagements  

There may be some instances where it's impossible to run the service without engaging the WS-Security module into the service. Engaging a module is just a matter of adding a module tag into the services XML. If the module is available, then the engaging will take place, else it will be a faulty service.

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

1. In the "Actions" panel, select "Modules."

2. Select a module to add and click engage. WSO2 Carbon provides the following modules, which you can engage into your service group.

• WSO2xfer-3.20 - Is an implementation of WS-Transfer.
• WSO2mex-3.20 - Provides MetadataExchange services for any services that the module is engaged.
• rampart-1.61-wso2v1 - Provides the WS-Security and WS-SecureConversation functionalities for Axis2, based on Apache WSS4J, Apache XML-Security and Apache Rahas implementations.
• sandesha1-3.20
• rahas-1.61-wso2v1 - Is used to STS enable a service, where it adds the RequestSecurityToken operation to a service that the module is engaged to.

3. A message appears if the module is successfully engaged. Click "OK."

Creating the Archive File  

Click "Create Service Archive" on the "Service Group Dashboard" page and it will create the service archive file.

You will be prompted to save the file (test.aar in this case) somewhere in your machine.

Using this link, you can create an Axis2 archive file out of all the configurations available to a given service group. Before shipping the service to a production environment, users can test the validity of its functions such as parameters, module engagement, polices etc.

However, currently this feature can archive only an .aar service. The WSO2 Application Server does not support archiving files with XML formatted description, such as POJO. Also, an archive can be created only 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 a service group.