Page Comparison

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 is <serviceGroup>, and we have multiple multiple <service> elements  elements inside the the <serviceGroup> element element. For example,

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

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

Accessing Service Groups

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

Image Removed

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)

1.  link to access the

1. groups.

1. Image Modified  

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

Image Removed

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

Image Removed

1. The Deployed Service Groups window opens. Click a group to go to its dashboard.  
2. A typical service group dashboard  contains three panels as follow:

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

Image Removed

• Service Group Details
• Services
• Accessing Service Groups

• Actions 
  

Services

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

From here you can:

• Click a service's name and view its dashboard.View a service's WSDLs.and  /wiki/spaces/DSS400/pages/31293830  
• View the /wiki/spaces/DSS400/pages/31293830
• Test the service using the "Try this service" link.

•  using the /wiki/spaces/DSS400/pages/31293830 link

Actions  

The following functions are available to manage the service groups: HERE

Image Added 

• Managing the parameters of the service group  
• Managing the module engagements.Accessing Service Groups.
• 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.

Image Removed

Managing the

parameters of the

service group

Anchor
Managing the parameters of the service group Managing the parameters of the service group

 

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

Image Removed

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

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

Click on the "You can add a new service group parameters using the Add New..." button to generate a new service parameter.

Image Removed

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

Image Removed

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

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

Image Removed

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

Image Removed

There may be some instances where it's impossible to run the service without engaging the WS-Security module into the service button.

Managing the module engagements

Anchor
moduleEngagement moduleEngagement

  

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 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

1. the Actions

1.  panel,

1. select Modules.

Image Removed

1.    
2. S elect a module

1. and

1. click engage .

1.  WSO2 DSS provides the following modules

1. for service groups.
   
   • WSO2Caching - Provides server-side and client-side caching implementation. See Configuring the wso2caching Module. 
   • W SO2xfer  - 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

1. • to
     

1. • rampart  - Provides WS-Security

1. •  and WS-SecureConversation

1. •  functionality for Axis2

1. • and is based on Apache WSS4J, Apache XML-Security and Apache Rahas implementations

1. • 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.

Image Removed

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

Image Removed

Creating an archive file

Anchor
Creating the archive file Creating the archive file

  

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

Image Removed

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

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

However, currently this feature can archive This feature archives 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 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 a service group.