Student: Popa Andrei-Sebastian Windows Web Services Student: Popa Andrei-Sebastian

Purpose WWSAPI is a native-code implementation of SOAP which provides core network communication functionality by supporting a set of the WS-* and .NET-* family of protocols. WWSAPI is designed to be used by components/applications which fall into one of the following categories: Native code mandate Require minimal dependencies Require minimal startup time Memory constrained environments  

Developer audience Windows Web Services API (WWSAPI) offers C/C++ application programming interface (API) for building SOAP based web services and clients to them. A basic understanding of web services and protocol associated with them is important to use this API.

Run-time requirements Windows Web Services API (WWSAPI) is an operating-system component of Windows 7 and Windows Server 2008 R2 or later versions of Microsoft Windows.

The Networking APIs enable communication between applications over a network. You can also create and manage access to shared resources, such as directories and network printers.

The Windows Web Services API is a layered API and it may be pictured as follows

The WWSAPI is a layered API The WWSAPI is a layered API. We expect most developers to target the Service Model, which is a method-based programming model. In the Service Model, the Service Host provides the server side programming model, while Service Proxy provides the client side programming model. Every layer exposes a set of APIs and types that can be used with APIs of that layer.

Service Model The top level layer called the Servic Model provides a method-based programming model and it is the easiest model to use. In the Service Model, the Service Host provides the server side programming model, while the Service Proxy provides the client side programming model. Context is used within the Service Model to pass in a relevant state available to the service operation and/or the callback when it is invoked. And Service Contract is used to specify a service contract on an endpoint exposed on the service.

XML Layer The Channel Layer is in turn built upon a lightweight XML framework, which includes deserialization of C data types. The following components and operations are part of the XML Layer: XML Writer XML Reader XML Buffer Serialization XML Language Support

Channel Layer The Service Model is built upon a Channel Layer, which provides full flexibility but is more difficult to use. The following components and operations are part of the Channel Layer: Message Channel Listener Faults Url Security Metadata Import

Common to all layers The following are topics that apply to any of the three layers Errors Asynchronous Model Thread Safety Tracing Cancellation Utilities Debugging Wsutil Compiler tool Heap

The Windows Web Services Functions support the method-based programming model of the Windows Web Services API. The Service Host runtime environment of the Service Model API layer provides the server side programming model. A server-side application opens, closes, and frees a service host resource as needed to process client requests. The Service Proxy provides the client-side API programming model. Client-side applications can send and receive messages over a channel through the service proxy as method calls.

Callback Functions Callbacks enable an application to call a function defined at another layer or level. The application registers the function argument as a handler that is to be called asynchronously at a later time as required. The callback is invoked if the function completes asynchronously indicating function success or error.

Windows Web Services Return Values E_INVALIDARG 0x8007000E The common name of the certificate does not match the value specified by the application. CERT_E_CN_NO_MATCH 0X800B010F One or more arguments are invalid. WS_E_ENDPOINT_UNREACHABLE 0x804d0010 There is no route or network connectivity to the endpoint. WS_S_ASYNC 0x4d0000 A function is completing asynchronously. 

Example of Asynchronous Function The example consists of the following parts: The Add function which will add two numbers synchronously or asynchronously. It creates a thread as an implementation detail for the asynchronous case. The CallAddSync function invokes the Add functions synchronously. The CallAddAsync function invokes the Add functions asynchronously. finman.html

In conclusion I do agree that all these proxies, having to create/free structures, handling HRESULTs etc. may seem a tad foreign if you are coming from a pure C# or VB.NET world. But if you are not put off by C++, and keeping your service or client code native is important to you, then WWS sure seems to be a great way to do it.

References https://docs.microsoft.com/en-us/windows/desktop/wsw/portal https://www.codeproject.com/Articles/38535/A-first-look-at-the-Windows-Web-Services-API https://docs.microsoft.com/en-gb/windows/desktop/wsw/windows-web-services-reference