Scenarios

In the simplest case, the client (Bob) fetches the WSDL for the service, discovers that no SLAs or tokens are needed, and invokes the service directly:

If the job service requires an SLA, the client will discover this by reading the WS-Policy attached to the WSDL. The client includes a suitable SLA (which it already has available locally) in the message, and the job service calls the SLA service to check that the client is permitted to use it.

In a more complicated case, the client may not have information about the SLA locally, and may need to present additional proof that they are allowed to use it. In this scenario, Bob discovers (from the job service's WSDL) that an SLA is required. He contacts a registry service in his own organisation to find a suitable SLA. The registry returns the SLA, along with the SLA's policy, which is that Bob needs a token from a membership group asserting that he is an engineer. He queries the registry again for information about using the membership group, and discovers that he doesn't need any further tokens, so he contacts the group and gets a signed SAML assertion. Finally, he invokes the job service, which passes both his X.509 identity token and the SAML token to the SLA service for validation.

All of this searching and querying is performed automatically by Bob's client software. For more information, see the client tutorial.