Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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,

Code Block
languagehtml/xml
<serviceGroup>
   <service name=Test1>
     ...
   </service>
   <service name=Test2>
     ...
   </service>
</serviceGroup>

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

  1. Log in to the m anagement 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:

Services

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

From here you can:

Actions  

The following functions are available to manage service groups:


Managing the parameters of the service group
Anchor
Managing the parameters of the service group
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 - The mandatory 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.

AnchorManaging the module engagements

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

Managing the Module Engagements


Managing the module engagements

 

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

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

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

Image Removed

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

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

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

Image Removed
Creating the Archive File
Anchor
Creating the archive file
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.