WS-Discovery Setup

The material in this section relates to the WS-Discovery specification.

To use the wsdd library:

Define WS-Discovery event handlers in your code, see Section WS-Discovery Event Handlers.
Use the wsdd API functions as described below.
(Re-)compile and link stdsoap2.c/pp or libgsoap, (dom.c/.cpp when needed), wsddapi.c, wsaapi.c and the soapcpp2-generated source files. Compile and link with plugin/threads.c when needed.

The material in this document pertains to the WS-Discovery protocol and model and assumes that the reader is familiar with the WS-Discovery protocol, its terms and definitions, and the WS-Discovery model. This document describes the WS-Discovery interface to invoke and handle WS-Discovery events, while the higher-level logic remains application-specific. Especially the mode of operation, ad-hoc or managed with a Discovery Proxy, depends on the application deployment and WS-Discovery support requirements.

The following assumptions are made. A Client (C) is an endpoint that searches for Target Service(s). A Target Service (TS) is a service endpoint that makes itself available for discovery. A Discovery Proxy (DP) is an endpoint that facilitates discovery of Target Services by Clients. The interfaces defined in the wsdd library can be used to implement Client, Target Service, and Discovery Proxy operations.

WS-Discovery ad-hoc and managed modes are supported by the wsdd library. In an ad-hoc mode discovery messages are sent multicast and response messages are sent unicast. In a managed mode discovery messages are sent unicast to a Discovery Proxy.

Note: The wsdl2h tool uses typemap.dat to auto-generate a gSOAP service definitions header file that imports wsdd.h to support WS-Discovery 1.1 with WS-Addressing 2005/08. The tool imports wsdd10.h to support WS-Discovery 1.0 with WS-Addressing 2004/08. To use WS-Discovery 1.0 with WS-Addressing 2005/08, you will need to change typemap.dat to let wsdl2h import wsdd5.h (see comments in typemap.dat).; The WS-Discovery protocol does not use SOAP-RPC encoded id-ref attributes. To remove id-ref serialization e.g. when using document/literal SOAP/XML messaging, use the runtime SOAP_XML_TREE flag or compile the source code with WITH_NOIDREF.

WS-Discovery Event Handlers

The following event handlers MUST be defined by the user to handle inbound WS-Discovery messages. The event handlers receive notifications (Hello, Bye, ProbeMatches, and ResolveMatches) or receive requests to provide data (Probe and Resolve).

The event handlers to define are:

See the documentation provided with each of these functions in wsddapi.h.

WS-Discovery Event Listener

Inbound WS-Discovery multicast messages are handled via a listener on a port. The user-defined event handlers are invoked when WS-Discovery messages arrive on the port.

The soap_wsdd_listen function listens on the current port opened with soap_bind for WS-Discovery messages for a brief time period as specified by a timeout value in seconds (negative for micro seconds). The function allows for periodically polling the port as shown:

#include "wsddapi.h"
int port = 8080;
struct soap *soap = soap_new();
soap->user = (void*)&my_state;
if (!soap_valid_socket(soap_bind(soap, port, 100)))
{
  soap_print_fault(soap, stderr);
  exit(0);
}
soap_wsdd_listen(soap, -1000); // listen for messages for 1 ms
...

WS-Discovery messages are relayed to the event handlers. The soap->user pointer can be used to point to a state object that is updated by the event handlers as per desired behavior at the Client side, the Target Service, or the Discovery Proxy implementation.

Invoking WS-Discovery Operations

A Client may invoke the following WS-Discovery operations:

soap_wsdd_Probe
soap_wsdd_Resolve

A Target Service may invoke the following WS-Discovery operations:

soap_wsdd_Hello
soap_wsdd_Bye
soap_wsdd_ProbeMatches (e.g. via soap_wsdd_listen)
soap_wsdd_ResolveMatches (e.g. via soap_wsdd_listen)

A Discovery Proxy can perform all operations listed above, and should use "wsdd:DiscoveryProxy" as the Type with the Hello, Bye, and ProbeMatches.

To send a Hello message to join a network:

soap_wsdd_Hello(soap,
  SOAP_WSDD_MANAGED,    // or SOAP_WSDD_ADHOC for ad-hoc mode
  "to address",         // "http(s):" URL, or "soap.udp:" UDP, or TCP/IP address
  soap_wsa_rand_uuid(soap), // a unique message ID
  NULL,
  "my address",         // where they can find me for WS-Discovery
  "wsdd:DiscoveryProxy",// Types: I'm a DP
  NULL,                 // Scope
  NULL,                 // MatchBy
  NULL,                 // XAddrs
  75965);               // MDVersion

Note that Types above is a string with namespace-qualified names (QNames). These should be qualified as in "namespace":name or you can use a namespace prefix that is part of your namespace table (in the .nsmap). So you can use "wsdd:DiscoveryPRoxy" as a QName in Types because wsdd is a namespace prefix with a defined binding in the namespace table.

For UDP multicast, use

soap.connect_flags = SO_BROADCAST;

and optionally set the interface and TTL settings:

in_addr_t addr = inet_addr("1.2.3.4");
soap.ipv4_multicast_if = &addr; // see setsockopt IPPROTO_IP IP_MULTICAST_IF
soap.ipv6_multicast_if = addr; // multicast sin6_scope_id
soap.ipv4_multicast_ttl = 1; // see setsockopt IPPROTO_IP, IP_MULTICAST_TTL

Please refer to the socket options for IPPROTO_IP IP_MULTICAST_IF to specify the default interface for multicast datagrams to be sent from. Otherwise, the default interface set by the system administrator will be used (if any).

Please refer to the socket options for IPPROTO_IP IP_MULTICAST_TTL to limit the lifetime of the packet. Multicast datagrams are sent with a default value of 1, to prevent them to be forwarded beyond the local network. This parameter can be set between 1 to 255.

To send a Bye message to leave a network:

soap_wsdd_Bye(soap,
  SOAP_WSDD_MANAGED,    // or SOAP_WSDD_ADHOC for ad-hoc mode
  "to address",         // "http(s):" URL, or "soap.udp:" UDP, or TCP/IP address
  soap_wsa_rand_uuid(soap), // a unique message ID
  NULL,
  "my address",         // where they can find me for WS-Discovery
  "wsdd:DiscoveryProxy",// Types: I'm a DP
  NULL,                 // Scope
  NULL,                 // MatchBy
  NULL,                 // XAddrs
  75965);               // MDVersion

To send a Probe message (see WS-Discovery 1.1 Section 1.7) and then listen to ProbeMatches:

struct soap soap = soap_new(); // to invoke messages
struct soap serv = soap_new(); // for the listener and event handlers
soap_bind(serv, port, 100);
const char *id = soap_wsa_rand_uuid(soap);
serv->user = (void*)&my_state;
my_state.probe_id = id;
soap_wsdd_Probe(soap,
  SOAP_WSDD_ADHOC,      // ad-hoc mode
  SOAP_WSDD_TO_TS,      // to a TS
  "to address",         // address of TS
  id,                   // message ID
  NULL,                 // ReplyTo
  "\"http://printer.example.org/2003/imaging\":PrintBasic",
  "ldap:///ou=engineering,o=examplecom,c=us",
  "http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/ldap");
soap_wsdd_listen(serv, -1000);

The id above is the WS-Addressing message ID that will be included in the ProbeMatches RelatesTo WS-Addressing header. As an example, my_state is set to this id so that when the wsdd_event_ProbeMatches event handler is invoked it can find the id in the current state that is pointed to by serv->user (soap->user in the handler).

To send a Resolve message and then listen to ResolveMatches:

struct soap soap = soap_new(); // to invoke messages
struct soap serv = soap_new(); // for the listener and event handlers
soap_bind(serv, port, 100);
const char *id = soap_wsa_rand_uuid(soap);
serv->user = (void*)&my_state;
my_state.resolve_id = id;
soap_wsdd_Resolve(soap,
  SOAP_WSDD_ADHOC,      // ad-hoc mode
  SOAP_WSDD_TO_TS,      // to a TS
  "to address",         // address to send to
  id,                   // message ID
  NULL,                 // ReplyTo
  "endpoint");          // EndpointReference of TS
 
soap_wsdd_listen(serv, -1000);

Again, the id and my_state are used to associate the asynchronously received ResolveMatches response that is handled by the wsdd_event_ResolveMatches for the original request.

In managed mode with unicast messages (request-response messages), the soap_wsdd_Probe and soap_wsdd_Resolve are sufficient to invoke without setting up a listener. The event handlers are invoked when the unicast response message arrives.

In managed mode, the ProbeMatches and ResolveMatches are automatically sent via soap_wsdd_listen and the event wsdd_event_Probe and wsdd_event_Resolve handlers. These event handlers should set the matches to be returned.

In ad-hoc mode, ProbeMatches or ResolveMatches responses are NOT sent automatically. In ad-hoc mode the responses can be returned by adding code to the event handler or from anywhere in the main program, for example after soap_wsdd_listen. When responses are to be returned from the event handler or from the main program, you should invoke soap_wsdd_ProbeMatches and soap_wsdd_ResolveMatches to explicitly send unicast messages with the match(es) back to the clients. The WS-Addressing ReplyTo address can be used as the return address (when not anonymous), or by using the peer's host information that is accessible in the soap->peer and soap->peerlen members. For example:

char host[1024], port[16];

getnameinfo((struct sockaddr*)&soap->peer, soap->peerlen, host, sizeof(host), port, 16, NI_DGRAM | NI_NAMEREQD | NI_NUMERICSERV);

The soap_wsdd_ProbeMatches function takes an array of wsdd__ProbeMatchesType matches to transmit. This array is created by calling functions soap_wsdd_init_ProbeMatches and then soap_wsdd_add_ProbeMatch multiple times. Each call adds an element to the matches:

const char *endpoint, *types, *scopes, *matchby, *xaddrs;
unsigned int version;
const char *relatesto, *to;
struct wsdd__ProbeMatchesType matches;
soap_wsdd_init_ProbeMatches(soap, &matches);
...
// repeat this to add multiple matches:
if (soap_wsdd_add_ProbeMatch(soap, &matches, endpoint, types, scopes, matchby, xaddrs, version))
  ... // out of memory
...
// send the ProbeMatches message
if (soap_wsdd_ProbeMatches(soap, endpoint, soap_wsa_rand_uuid(soap), relatesto, to, &matches))
  ... // an error occurred

After calling soap_wsdd_add_ProbeMatch it is possible to add additional WS-Addressing header values to this matches array element. For example the WS-Addressing reference parameters channel instance:

if (soap_wsdd_add_ProbeMatch(soap, &matches, endpoint, types, scopes, matchby, xaddrs, version))
  ... // out of memory
// now allocate and add the WS-Addresssing reference parameters
struct wsa5__EndpointReference *ref = &matches.ProbeMatch[matches.__sizeProbeMatch - 1].wsa5__EndpointReference;
ref->ReferenceParameters = (struct wsa5__ReferenceParametersType*)soap_malloc(soap, sizeof(struct wsa5__ReferenceParametersType));
if (ref == NULL)
  ... // out of memory
soap_default_wsa5__ReferenceParametersType(soap, ref->ReferenceParameters);
ref->ReferenceParameters->chan__ChannelInstance = ...

See also the Data binding documentation on allocating and initializing C/C++ data in managed memory, managed by the soap context.

Generating C++ Server Objects

The WSDD plugin is developed to support C and C++. To support C++ server objects generated with soapcpp2 option -j (or -i), run soapcpp2 again:

soapcpp2 -a -j -Iimport import/wsdd.h

You should define in your C++ code the following wrappers (use this instead of this->soap below with soapcpp2 option -i):

int wsddService::Hello(struct wsdd__HelloType *hello)
{
  return __wsdd__Hello(this->soap, hello);
}
int wsddService::Bye(struct wsdd__ByeType *bye)
{
  return __wsdd__Bye(this->soap, bye);
}
int wsddService::Probe(struct wsdd__ProbeType *probe)
{
  return __wsdd__Probe(this->soap, probe);
}
int wsddService::ProbeMatches(struct wsdd__ProbeMatchesType *matches)
{
  return __wsdd__ProbeMatches(this->soap, matches);
}
int wsddService::Resolve(struct wsdd__ResolveType *resolve)
{
  return __wsdd__Resolve(this->soap, resolve);
}
int wsddService::ResolveMatches(struct wsdd__ResolveMatchesType *matches)
{
  return __wsdd__ResolveMatches(this->soap, matches);
}

Note that soapcpp2 option -a may be needed to enable automatic service dispatching of WS-Addressing services based on the SOAP Action value instead of the SOAP/XML request operation.

Another approach to generate the WSDD service operations is to run soapcpp2 separately on wsdd.h (or wsdd5.h or wsdd10.h for WS-Discovery 1.0) by:

soapcpp2 -a -L -pwsdd -Iimport import/wsdd.h

Now with this approach you must chain the service operations at the server side as follows:

if (soap_begin_serve(service.soap) == SOAP_OK)
  if (service.dispatch() == SOAP_NO_METHOD)
    soap_serve_request(service.soap);

where the service object is an instance of the application services generated by soapcpp2 -j.

Then compile the generated wsddClient.cpp file with the macro -DSOAP_H_FILE=wsddH.h to specify that wsddH.h should be used instead of `soapH.h.

To combine WS-Security with WS-Discovery, please see the next section.

Miscellaneous

You must generate client-side operations that the WSDD library expects to be linked with, by executing:

soapcpp2 -a -L -pwsdd -Iimport import/wsdd.h

Then compile the generated wsddClient.cpp file with the macro -DSOAP_H_FILE=wsddH.h to specify that wsddH.h should be used instead of `soapH.h.

If WS-Security is used with WS-Discovery, then create a file imports.h with the following two lines:

// file: imports.h
#import "wsdd.h" // or wsdd10.h, wsdd5.h
#import "wsse.h"

Then execute:

soapcpp2 -a -L -pwsdd -Iimport imports.h

This generates wsddC.cpp and wsddClient.cpp, which should be compiled together with plugin/wsddapi.c, plugin/wsseapi.c, plugin/mecevp.c, and plugin/smdevp.c. All files should be compiled with -DSOAP_H_FILE=wsddH.h, i.e. macro SOAP_H_FILE set to wsddH.h. WS-Security requires OpenSSL and linkage with libssl and libcrypto.

For server-side projects, also compile and link the generated wsddServer.cpp code. You will also need to implement the WS-Discovery Event Handlers.

Because WS-Addressing may relay faults to a FaultTo service, when implementing a service you will also have to define a SOAP Fault service operation to accept and handle these:

int SOAP_ENV__Fault(struct soap *soap, char *faultcode, char *faultstring, char *faultactor, struct SOAP_ENV__Detail *detail, struct SOAP_ENV__Code *SOAP_ENV__Code, struct SOAP_ENV__Reason *SOAP_ENV__Reason, char *SOAP_ENV__Node, char *SOAP_ENV__Role, struct SOAP_ENV__Detail *SOAP_ENV__Detail)
{ 
  ... = faultcode; // SOAP 1.1 fault code string (QName)
  ... = faultstring; // SOAP 1.1 fault string
  ... = faultactor; // SOAP 1.1 fault actor string
  ... = detail; // SOAP 1.1 fault detail struct
  ... = SOAP_ENV__Code; // SOAP 1.2 fault code struct
  ... = SOAP_ENV__Reason; // SOAP 1.2 reason struct
  ... = SOAP_ENV__Node; // SOAP 1.2 node string
  ... = SOAP_ENV__Role; // SOAP 1.2 role string
  ... = SOAP_ENV__Detail; // SOAP 1.2 detail struct
  return SOAP_OK;
}

When implementing a WS-Discovery client and/or server without any other XML Web services, the above suffices to generate the required code.