Deployed Services

Service Groups Services Policies Parameters WSDL files Try It
The Service List page allows you to manage different kinds of services and service groups. If your service is successful, it will appear on this page. If not, it will be indicated by the Faulty Service Groups link (which appears in red.)

Figure 1: The List of Deployed Services

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>

The WSO2 Carbon provides the following functions to manage the service groups.

  1. Managing the parameters of the service group
  2. Managing the module engagements
  3. Creating the archive file

Figure 2: Service group dashboard

Manage Service Group Parameters

We can define parameters 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) or AxisService or AxisOperation. A parameter has one mandatory attribute and one optional attribute. The mandatory attribute is the name of the parameter while the optional attribute is the locked 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 we add a parameter in the axis2.xml file setting the locked attribute to True, then if a service tries to add another parameter with the same name, it will give an exception .

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

Figure 3: Adding service group parameters

Manage Module Engagements

There may be some instances where we cannot run our 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.

The WSO2 Carbon provides the following modules which you can engage into your service.

  1. WSO2xfer-2.2
  2. Rampart-1.00
  3. Rahas-1.00
  4. Savan-1.00
  5. Sandesha2-1.00
  6. WSO2mex-2.2
  7. Addressing-1.41

Figure 4: Engaging a module

You can see further details here.

Create Service Archive 

When you click Create Service Archive on the Service Group Dashboard page for your service, it will create the service archive file. You will be prompted to save the file somewhere else in your machine.

Services

The WSO2 Carbon provides many tools to manage the services that have been deployed successfully with WSO2Server. When you deploy a single service in a service archive, the archive file name will always be used as the service file name, unless you have a name attributed to the service file. If the name of the service archive file is Test.aar, then the name of the service will be Test.

Figure 5: Service Dashboard

Service Details

The Service Details panel provides the details of the service.

  1. Service Name
  2. Service Description
  3. Service Group Name
  4. Deployment Scope
  5. Service Type

Figure 6: Service Details

Service Statistics

The Statistics panel provides statistics of the service.

  1. Request Count
  2. Response Count
  3. Fault Count
  4. Max,Min,Average Response Times

Figure 7: Service Statistics

You can find further details here.

Response Time

The WSO2 Carbon provides a graphical view of the system response time.

Figure 8: Response Time vs Time

Endpoints

The WSO2 server is set to two endpoints by default.

  1. https://10.100.1.147:9443/services/HelloService/
  2. http://10.100.1.147:9763/services/HelloService/

Quality of Service Configuration

The WSO2 Carbon provides a number of tools to manage the service quality. You can activate the tools individually as required.The tools incorporated into Carbon are:

  1. Security
  2. Reliable Messaging
  3. Response Caching
  4. Access Throttling
  5. Policies
  6. Transports
  7. Modules
  8. Operations
  9. Parameters
  10. MTOM SOAP Message Transmission Optimization Mechanism (MTOM) is a widely used mechanism for sending attachments with SOAP. By default, MTOM is set to optional. You can set it to True or False.

Figure 9: Quality of Service Configuration

Note: Help files for each tool are available from their respective pages.

Client Operation

WSO2 Carbon provides two client operations. They are, Try this service and Generate the Client.

Try this service

Figure 10: Client Operations

When you click Try this service, you will be directed to the page where the operations available for your service will be displayed. When you give the parameters for the operation, a button corresponding to your service appears. (Refer to Figure 11: the greet button) When you click this button, you will get the output.

Figure 11: Check the Service

Generate the client for your service

You can easily generate the client for your service using the WSO2 Carbon. The WSDL2 code options are available on the WSDL2 page.

You will see the links to the WSDL 1.1 and the WSDL 2.0 files in the browser.

Policies

WS-Policy Attachment specification defines a set of policy subjects that can be used when we want to attach or apply security policies. For example, we can attach security policies either at service-level, operation-level or even at message-level.

WSO2 Carbon has the power of Axis2 to apply WS-Policy for your services at different levels such as service, service operation, service operation message, binding, binding operation, binding operation message, etc..

Defining Policies at Bindings

The WSO2 Carbon has the ability to apply policies at the binding hierarchy. You can apply policies at three different policy subjects in the binding hierarchy. They are;

  1. Binding level
  2. Binding operation level
  3. Binding message level

If you want to add a policy to SOAP 1.1 and SOAP 1.2 bindings at Binding level, you can define it in the services.xml by adding the following code. 

<wsp:PolicyAttachment xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">

<wsp:AppliesTo>

<policy-subject identifier="binding:soap11" />

<policy-subject identifier="binding:soap12" />

</wsp:AppliesTo>

<wsp:Policy wsu:Id="binding_level_policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

</wsp:Policy>

</wsp:PolicyAttachment>

For the Binding Operation level, the <wsp:AppliesTo> element is used to define the scope of the policy.

The XML snippet is as follws.

<wsp:PolicyAttachment xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">

<wsp:AppliesTo>

<policy-subject identifier="binding:soap11/operation:Echo" />

<policy-subject identifier="binding:soap12/operation:Echo" />

</wsp:AppliesTo>

<wsp:Policy wsu:Id="binding_level_policy"

xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

</wsp:Policy>

</wsp:PolicyAttachment>

For the Binding Message level for the out message, the configuration is similar. The identifier attribute of the <policy-subject/> element in <wsp:AppliesTo> changes to "binding:soap11/operation:echo/out". 

The XML snippet is as follws.

<wsp:PolicyAttachment xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"><wsp:AppliesTo>

<policy-subject identifier="binding:soap11/operation:secureEcho/in" />

<policy-subject identifier="binding:soap12/operation:secureEcho/in" />

</wsp:AppliesTo>

<wsp:Policy wsu:Id="binding_level_policy"

xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

</wsp:Policy>

</wsp:PolicyAttachment>

Note: Further details can be found at,

Parameters

The Service Parameters page is used to add service parameters to your service.xml. Click Add New and enter the parameter name. In the TODO section of the parameter that was added, enter the value for your parameter.Click Update to add your newly created parameter into your service.xml file.

Figure 12: Service Parameters

WSDL Files

You will be able to get the WSDL 1.1 and WSDL 2.0 files from the Deployed Services panel. When you click the particular WSDL link, the WSDL file of your service in the browser.

Try It

You can check whether your (successful) service provides the desired output using this option. When you click Try It,you will be directed to another page where you give the parameters for the operations. When you give the parameters for the operation, a button corresponding to your service appears. (Refer to Figure 11: the greet button) When you click this button, you will get the output.

You can find further details here.