WSO2 products are managed internally using SOAP Web services known as admin services. WSO2 products come with a management console UI, which communicates with these admin services to facilitate administration capabilities through the UI.
A service in WSO2 products is defined by the following components:
- Service component: provides the actual service
- UI component: provides the Web user interface to the service
- Service stub: provides the interface to invoke the service generated from the service WSDL
There can be instances where you want to call back-end Web services directly. For example, in test automation, to minimize the overhead of having to change automation scripts whenever a UI change happens, developers prefer to call the underlying services in scripts. The topics below explain how to discover and invoke these services from your applications.
Discovering the admin services
By default, the WSDLs of admin services are hidden from consumers. Given below is how to discover them.
- Set the
<HideAdminServiceWSDLs>element to false in the
- Restart the server.
- Start the WSO2 product with the
-DosgiConsoleoption, such as
sh <PRODUCT_HOME>/bin/wso2server.sh -DosgiConsolein Linux.
- When the server is started, hit the enter/return key several times to get the OSGI shell in the console.
- In the OSGI shell, type:
- The list of admin services of your product are listed. For example:
To see the service contract of an admin service, select the admin service's URL and then paste it in your browser with ?wsdl at the end. For example:
In products like WSO2 ESB and WSO2 API Manager, the port is 8243 (assuming 0 port offset). However, you should be accessing the Admin Services via the management console port, which is 9443 when there is no port offset.
Note that the admin service's URL appears as follows in the list you discovered in step 6:
Invoking an admin service
Admin services are secured using common types of security protocols such as HTTP basic authentication, WS-Security username token, and session based authentication to prevent anonymous invocations. For example, the
UserAdmin Web service is secured with the HTTP basic authentication. To invoke a service, you do the following:
- Authenticate yourself and get the session cookie.
- Generate the client stubs to access the back-end Web services.
To generate the stubs, you can write your own client program using the Axis2 client API or use an existing tool like SoapUI (4.5.1 or later) or wsdl2java.
The wsdl2java tool, which comes with WSO2 products by default hides all the complexity and presents you with a proxy to the back-end service. The stub generation happens during the project build process within the Maven POM files. It uses the Maven ant run plug-in to execute the wsdl2java tool.
You can also use the Java client program given here to invoke admin services. All dependency JAR files that you need to run this client are found in the
Authenticate the user
The example code below authenticates the user and gets the session cookie:
To resolve dependency issues, if any, add the following dependency JARs location to the class path:
AuthenticationAdminStub class requires
org.apache.axis2.context.ConfigurationContext as a parameter. You can give a null value there.
Generate the client stubs
) in the
service.xmlfile in the
META-INFfolder in the respective bundle that you find in
The following sample code lists the back-end Web services: