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

[Asa Hardcastle]

Cool, I see what you're saying Conor.

So integrating what you've done in your client (payload,  
inResponseTo) then a request could be created with:

WSFServiceRequest request =
	serviceInstance.createServiceRequest(
		SomeServiceType, // static type
		inResponseTo, // WSFServiceResponse
		payLoad
	);

inReponseTo might be empty if this this the first interaction.  The  
action EPR would be automatically discovered simply by setting the  
service type, a table of EPRs would be managed by the ServiceInstance  
based on the transactions already completed.  So those who are  
curious could look at the table like this (or something).

You could if curious, look through the list:
eprList = myServiceInstance.getStoredEndpointRefs();
WSFEndpointReference anEPR;
loopOverTheTable
{
	anEPR.getUrl();
	anEPR.getServiceType();
}

This would enable a curious user to choose a service from multiple  
selections.

By not executing the request immediately, it allows the end user to  
set the EPR directly if they please, and other settings for the  
request.   But, I can see where someone not interested in specific  
config of the request (where details are stored in the  
ServiceInstance) would do the following:

1. create a serviceinstance and configure it, if needed
2. use the service instance to get a response
response=si.performService(
			serviceType, // sttic type
			inResponseTo, // WSFServiceResponse
			payLoad)

then for the next xyz uses the user would simply do #2 over and over.

asa



On Feb 10, 2007, at 12:30 AM, Cahill, Conor P wrote:

>
>
>> /**
>>   *  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