Difference between revisions of "Scout/SDK/JAXWS-SDK/Create webservice provider"

Revision as of 05:25, 10 November 2011

The Scout documentation has been moved to https://eclipsescout.github.io/. 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 [1].

Create webservice provider from scratch or based on a WSDL file

First, you are asked whether to create the webservice provider from scratch or based on an existinig WSDL file [2]. Depending on your choice, the next wizard step differs.

Please note
Depending on your choice on this wizard step, the next step differs. By any choice you configure the endpoint and an alias in the next step - meaning at which URL the webservice is to be published (URL pattern) and what would be the name of your webservice provider (alias).

Create webservice provider from scratch

When choosing the option from scratch, you are asked to specify properties to create the WSDL file [3] 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 [4]. 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 [5].

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 [6]. 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 [7]. By default, such a file is created. In the default binding-file, there is a global binding configured to unmarshall any xsd:date, xsd:time and 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 [8].

Furthermore, you configure the authentication mechanism to be installed and how the request's credentials are to be validated. By default, The Scout documentation has been moved to https://eclipsescout.github.io/. 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 The Scout documentation has been moved to https://eclipsescout.github.io/.. To validate the user's credentials, by default the The Scout documentation has been moved to https://eclipsescout.github.io/. is used, meaing 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:

org.eclipse.scout.jaxws216.security.provider.ConfigIniCredentialValidationStrategy#credentials=sean\=XXXX;jack\=XXXX;kimberley\=XXXX</code>

If you'd like to validate the user's credentials against something else than config.ini (e.g. a database), feel free to use your own The Scout documentation has been moved to https://eclipsescout.github.io/. (e.g. DatabaseCredentialValidationStrategy).

Also, you can configure the session factory to be used. By default, a new The Scout documentation has been moved to https://eclipsescout.github.io/. 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.

Create Webservice Provider

Choose to create the webservice provider from scratch or based on an existing WSDL file

Specify WSDL and endpoint publish properties

Choose exising WSDL file

Specify endpoint publish properties