Service List - User Guide

Deployed Services

Service GroupsServicesPoliciesParametersWSDL filesTry 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.

    NOTE : This internal Try it does't work properly when the front end and back end are separated. Therefore, please use the external Try it in that case by providing the WSDL URL of the service that you want to try.

    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.