One of the unique features of Soaplab is its generic interface that makes it possible to use one single interface when accessing any Soaplab Web Services regardless of the command line interface of underlying programs. However, it is not possible to specify input/output data types as part of Soaplab generic WSDL; instead the interface accommodates methods to query this information. This difference from common WSDL interfaces, for example, doesn't allow standard Web Services clients to check/validate input data before sending a request or output data after a response has been received. There was a growing concern in Bioinformatics Web Services community that Soaplab should include input/output type descriptions at WSDL level. To address this concern, starting with version 2.2, Soaplab includes an interface called typed interface (sometimes typed services that includes input output type definitions at WSDL level. This document describes how to create and deploy such services.
The typed services are just additions to existing, non-typed (regular) Soaplab services. Once you make them available, they will co-exist with the regular services on the same server. You cannot have only typed services (unless you manually edit some configuration files in WEB-INF directory - but it is not covered by this document).
In order to access typed services you use a slightly different URL, using the /typed/services instead of just /services. For example, an endpoint of the strongly typed classic.helloworld service is (using the default host, port and context names) is:
http://localhost:8080/soaplab2/typed/services/classic.helloworldFor the same service, you can also use an alias:
http://localhost:8080/soaplab2/typed/services/classic.helloworld.saindicating that the WSDL for this service is semantically annotated (see more about WSDLs in the document Using strongly typed services).
The regular services can be deployed using either jaxws or axis1 protocol (see more in the deployment guide). By contrast, the typed services use always only jaxws protocol. But they can still co-exist with regular services deployed by the axis1.
There is no strongly typed equivalent of the list service (that would provide a list of available typed services) but there is a web page (default name: http://localhost:8080/soaplab2/services/list) that lists all WSDLs (well, this is true when deploying regular services using jaxws protocol).
The services with strongly typed interfaces are relatively easy to create - by providing just one additional property in the build time. Everything else is done automagically.
The typed services are created from data (rather metadata) available from the regular services. Therefore, you need first to have regular services (as described elsewhere in the Soaplab documentation). The regular services can be either first deployed, or you can deploy both, regular and typed, services, in the same time.
The typed services are created by generating WSDL files and some Java code in the generated directory. This happens when the property typedinterface.enable is set to true. For example, you can create a war file with both regular and typed services by:
ant -Dtypedinterface.enable=true jaxwarThe above line creates a war file with both types of services - but in order to do it it uses existing regular services. And to access them, it uses protocol defined in soaplab.client.properties file (because it gets services metadata like any other regular Soaplab client). Therefore, if you have not yet deployed your regular services you need to use the local protocol (a protocol that uses directly Soaplab classes without any Web Service ornamentation). In such case, edit your soaplab.client.properties first:
# ------------------------------ # how to access service/services # ------------------------------ protocol = localor use a slightly cumbersome Ant invocation:
ant -Dtypedinterface.enable=true '-Dargs=-protocol local' jaxwarThe resulting war file can be deployed to your Soaplab server as usual (by using the Tomcat manager or by using Ant's task jaxdeploy instead of jaxwar). Only expect slightly longer start-up time of the Soaplab web application after deployment.