[wsf-dev] ID-WSF Stack, starting point

[Cahill, Conor P]

> /**
>   *  SSO
>   *
>   **/
> ...
> 
> /**
>   * instantiate a WSFServiceInstance
>   *
>   **/
> // OPTION 1: Get the needed bits, and create a service instance 
> WSFEndpointReference disco_epr = new WSFEndpointReference (  
> [extracted from the attributes of some SSO response] ); 
> WSFIdentityToken token =  new SOME_CLASS_IMPLEMENTING_WSFIdentityToken
> (  [extract parameters from some SSO response] );
> 
> WSFServiceInstance si = new WSFServiceInstance(); 
> si.setDiscoveryServiceEndPointReference(disco_epr);
> si.setIdentityToken(token);
> // set more things, add certificates, etc...
> ...
> 
> // OPTION 2: use a utility that understands a SAML assertion to 
> extract the needed bits - in essence hiding the DS EPR?
> // WSFServiceInstance si =
> WSFServiceInstance.serviceInstanceFromSAMLAssertion
> (assertion_object_or_string);

I could also see it as:

WSServiceInstance si = new WSServiceInstance( SAML_SSO_Assertion,
serviceType );

where SAML_SSO_Assertion is the SSO assertion 
and   serviceType is the service URI for the service that is to be
accessed.

This would pull the DS EPR from the Assertion, build and invoke the DS
request for the service and build the invocation model for the service
from the results of the discovery request.

Of course there could be options for more complex service controls (such
as selection of the security mech, multiple service types, actions,
etc., etc. 

> /**
>   * configure a WSFServiceRequest
>   *
>   */
> WSFServiceRequest request = si.creatServiceRequest 
> (WSFServiceInstance.SomeServiceType);
> 
> // optional settings
> //request.setEndPointReference(some_epr);
> //request.setPayload(some_payload_based_on_service_type_needs);
> //request.OPTIONALLY_SET_THINGS_THAT_MAKE_YOU_HAPPY;
> // optionally play with the request as an XML document 
> //request.getRequestDOMToPlayWithAndHopefullyNotMangle();

The Serivce EPR should not be set for each request.  In my WSF client I
found it necessary to have the following parameters:

	payload
	inRespTo - message ID that this message is in response to
	Request & Response Action URIs
	
I also found it useful to pull out the status from the response message
and make it available as a separate return component.

Not also that the EPR may change during communications with the WSP
(through the use of the EndpointReferenceUpdate header in a response)
and I think this should be processed at the framework level, not at
the application level (so the WSC application doesn't see this unless
they want to look into it -- it just works magically).


> /**
>   * execute the request
>   *
>   */
> WSFServiceResponse response = request.makeItSoNumberOne();	
> // lots of  
> stuff done here

I did this directly off the service instance rather than creating
a separate request element.  So, my si.Request(parametsrs) actually
submits the request (and has a flag to allow the request to be 
synchronous or async, although currently only sync is supported)

Conor