There are many options for defining Service-Oriented Web Services within the Microsoft environments. The main areas that require consideration are:
WebMaker supports a number of these mechanisms, but there are limitations / considerations in some of these areas.
Publicly Exposed Web Services
If a Web Service is created that is "publicly available", then the WebMaker Design Studio can access and query the Web Service contract and the actual runtime web service. This is important, as the Design studio consumes the WSDL and Schema contracts to provide details of the request and response message structures available.
The Design Studio provides the ability to consume the WSDL contract remotely if required.
Locally Secured Web Services
However, WebMaker Design Studio is not currently able to access any WSDL that is behind an authentication mechanism. If you type the URL that accesses the WSDL into a Browser, if it asks for username and password then WebMaker Design Studio cannot access the details. Please note that this may also apply to Schemas (XSDs) that are nested within the WSDL contract.
In this situation, the only option available is to manually copy the contract details and then import locally. The "How to Import a WSDL Manually" section below explains the detailed steps.
It may be worth checking the security settings for the Web Service with the security administrator. It may be possible that the security authentication for the WSDL contract elements can be removed?
Important: WebMaker developed applications are able to process Web Services that are authenticated, but there may be some limitations to types of security. Please refer to "Authentication access for a SharePoint service" FAQ entry for an example.
How to Import a WSDL Manually
The WebMaker Design Studio feature that attempts to "Upload from URL" is not able to handle windows authentication.
WebMaker Design Studio assumes that the WSDL and Schemas are "publicly available".
However, the web applications built with the Design Studio can use some of the authentication mechanisms such as Basic, Digest and so on.
The only way to work-around this limitation at present, is to manually download the WSDL and the imported XSDs (if embedded in the WSDL) to a local directory before loading them into WebMaker.
The following steps are done outside of WebMaker:
Return to WebMaker and use the +?+?-?Upload File+?+?+? option for the Service Definition option rather than the +?+?-?Upload from URL+?+?+? option. Then select the WSDL file created in the temporary directory above.
This will then look through the import definitions within the WSDL, and for each schema referenced it will pull each one in automatically. Note: It is important to make sure that all the file-names are correct.
It should now be possible to continue to work with WebMaker Design Studio in the normal manner.
As the URL for the actual service call in the WSDL has not been altered, then the calls to the web service in the created web application should work when tested.
You may then find that when building the application to access the service, you will need to define additional +?+?-?Remote Service Authentication e.g. SharePoint+?+?+?. Please refer to the product documentation for further details on this topic.
- Windows Communication foundation (WCF) e.g. .svc extension[/*]
- .NET Framework standard services e.g. .asmx extension [/*]
- Authentication considerations[/*]
WebMaker supports a number of these mechanisms, but there are limitations / considerations in some of these areas.
Publicly Exposed Web Services
If a Web Service is created that is "publicly available", then the WebMaker Design Studio can access and query the Web Service contract and the actual runtime web service. This is important, as the Design studio consumes the WSDL and Schema contracts to provide details of the request and response message structures available.
The Design Studio provides the ability to consume the WSDL contract remotely if required.
Locally Secured Web Services
However, WebMaker Design Studio is not currently able to access any WSDL that is behind an authentication mechanism. If you type the URL that accesses the WSDL into a Browser, if it asks for username and password then WebMaker Design Studio cannot access the details. Please note that this may also apply to Schemas (XSDs) that are nested within the WSDL contract.
In this situation, the only option available is to manually copy the contract details and then import locally. The "How to Import a WSDL Manually" section below explains the detailed steps.
It may be worth checking the security settings for the Web Service with the security administrator. It may be possible that the security authentication for the WSDL contract elements can be removed?
Important: WebMaker developed applications are able to process Web Services that are authenticated, but there may be some limitations to types of security. Please refer to "Authentication access for a SharePoint service" FAQ entry for an example.
How to Import a WSDL Manually
The WebMaker Design Studio feature that attempts to "Upload from URL" is not able to handle windows authentication.
WebMaker Design Studio assumes that the WSDL and Schemas are "publicly available".
However, the web applications built with the Design Studio can use some of the authentication mechanisms such as Basic, Digest and so on.
The only way to work-around this limitation at present, is to manually download the WSDL and the imported XSDs (if embedded in the WSDL) to a local directory before loading them into WebMaker.
The following steps are done outside of WebMaker:
- Download the WSDL file to a temporary directory on your machine.
Name the WSDL something like: YourServiceName.wsdl[/*] - Then you need to take each of the URL references that are defined in the <xsd:import schemaLocation=+?+?+?http://+?+?-?+?+?+?/> in the WSDL file, and download those XSD documents to the same location.
Name the schemas something like: YourServiceName_xsd1.xsd
Note: The file names do not have to follow the suggested pattern if alternative names are preferred.[/*] - Check each of the Schema files above to see if there any further nested import XSD definitions.
If there are download and name those files in the same manner.[/*] - Now edit the WSDL and change the <xsd:import schemaLocation=+?+?+?http://+?+?-?+?+?+?/> schemaLocation attribute to be the name of the Schema filename in the local directory e.g. schemaLocation=+?+?+?YourServiceName_xsd1.xsd+?+?+?...[/*]
- This last step will need to be repeated for any of the Schemas that included imports of other schemas.
At the end of this step the WSDL and the nested Schema definitions are all relative local path names.[/*]
Return to WebMaker and use the +?+?-?Upload File+?+?+? option for the Service Definition option rather than the +?+?-?Upload from URL+?+?+? option. Then select the WSDL file created in the temporary directory above.
This will then look through the import definitions within the WSDL, and for each schema referenced it will pull each one in automatically. Note: It is important to make sure that all the file-names are correct.
It should now be possible to continue to work with WebMaker Design Studio in the normal manner.
As the URL for the actual service call in the WSDL has not been altered, then the calls to the web service in the created web application should work when tested.
You may then find that when building the application to access the service, you will need to define additional +?+?-?Remote Service Authentication e.g. SharePoint+?+?+?. Please refer to the product documentation for further details on this topic.