Scout/SDK/JAXWS-SDK/Create webservice provider
|Download • Git|
|Forums • Blog • Twitter|
On server node, go to the node 'Webservices (JAX-WS RI 2.1.6)' | 'Provider' | 'Services'. Right-click on that node to create a new webservice provider .
Create webservice provider from scratch or based on a WSDL file
Create webservice provider from scratch
When choosing the option from scratch, you are asked to specify properties to create the WSDL file  and to configure the endpoint. When entering the WSDL name, the other fields get auto-completed due to naming convention rules. That is if the checkbox
Derive other names from WSDL file name is checked. Nevertheless, the value for those derived fields can be overwritten to your taste.
Create webservice provider based on an existing WSDL file
When choosing the option to use an existing WSDL file in the first wizard step, you are asked to choose the WSDL file either from the filesystem or an URL . If the WSDL file consists of multiple files such as separate files for Port and Binding definitions as well as separate files for XSD Schema types, use the first option and specify those files as related files. If you choose the WSDL from URL, press TAB or click somewhere outside the URL field to validate and download the WSDL file.
Click next to continue. Here you are asked to configure the endpoint - that is which PortType you'd like to publish and at which URL it should be accessible .
Control the Stub Generation Process
In the next wizard step, you have the possiblity to specify a custom package name for the stub files to be generated . Please note, that the stub is generatged into a separate JAR-file, so the package name is not that important.
In general, you should not set a custom package because this instruments JAX-WS builder to not apply the default package name algorithm and to ignore any WSDL and schema binding customization for package name. Typically, the default package name algorithm derives the package name based on the targetNamespace of the webservice to be built. In some situations, this name might not be a valid Java package name and requires you to specify a custom package name.
Also, you can specify to create a binding file to customize JAX-WS default bindings . By default, such a file is created. In the default binding-file, there is a global binding configured to unmarshall any
xsd:dateTime to a
java.util.Date represented as UTC time. If you do not choose to create such a binding-file, you can do it anytime later in Scout SDK. Please note that changes in the binding-file are to instrument the stub build process, meaning that changes require are rebuild of the webservice stub.
Implementing Port Type
Finally, you configure the name and location of the implementing port type. That is the class to process webservice requests, meaning that you implement the business logic of the webservice in there .
Also, you configure the authentication mechanism to be installed and how the request's credentials are to be validated. By default, BasicAuthenticationHandler is used as authentication mechanism. Basic Access Authentication means, that the caller must provide his credentials within HTTP headers. Currently, Scout is shipped with two authentication mechanism, BASICand WSSE. Other mechanism can easily be plugged-in by creating your own IAuthenticationHandler. To validate the user's credentials, by default, the ConfigIniCredentialValidationStrategy is used, meaning that username and password are validated against valid credentials configured in config.ini.
In order to work, configure the valid credentials in config.ini as follows:
If you'd like to validate the user's credentials against something else than config.ini (e.g. a database or LDAP), feel free to use your own ICredentialValidationStrategy (e.g. DatabaseCredentialValidationStrategy).
Furthermore, you can configure the session factory to be used. By default, a new ServerSession is created for each request. That might result in a bad performance depending on the amount of data to be loaded when creating the server session. In such situation is might cheaper to always use the same session for each request again and again . For this purpose, create an own session factory (e.g. BackendSessionFactory) to simply return a cached backend session. Even though sharing the same session instance, all actions are run on behalf of the authenticated subject within a respective doAs-call.