Figure 1: Deployed 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.
The Service Details page provides detailed information about a particular service.Figure 2: Service Dashboard
The Service Details panel provides the details of the service.
Figure 3: Service Details
The Statistics panel provides statistics of the service.
Figure 4: Service Statistics
The WSO2 Carbon provides a graphical view of the system response time.
Figure 5: Response Time vs Time
The WSO2 server is set to two endpoints by default.
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:
Figure 6: Quality of Service Configuration
Note: Help files for each tool are available from their respective pages.
WSO2 Carbon provides two client operations. They are, Try this service and Generate the Client.
Figure 7: Client Operations
You can check whether your service provides the desired output using the TryIt option. 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. You can find further details here.
Figure 8: Check the 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.
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..
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;
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,
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.
Figure 9: Service group dashboard
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 10: Adding service group parameters
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.
Figure 11: Engaging a module
You can see further details here.
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.
You can find further details here.
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
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.