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

[Cahill, Conor P]

> 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
> 	);

Not exactly.   I'd have the SomeServiceType in the creation
of the serviceInstance rather than in the creation or 
invocation of the request.

That way a serviceInstance is usable for multiple 
request to the same service endpoint, but you would 
create different serviceInstance objects to talk to
different service instances (e.g. profile and DS).

> 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).

As scott said, there probably should be several ways to
instantiate a service instance (and my client library does
have several for various reasons).  The easiest for many
WSCs in an environment where there's a DS would be to use
the serviceType(s) of the service they want to talk to.

But also supporting instantiation using and EPR is also 
very useful if the WSC has some other means of obtaining
the EPR.  I actually did this in my client library in order
to support the instantiation of the DS service instance from
the EPR in the SSO token, but it also helps a lot for 
testing since I can run a series of independent service
tests from a single discovery operation.

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

I just don't see the value of magically dealing with 
different service types internally within a single
serviceInstance object.

There is a real shortcomming in that model -- the WSC
would not be able to talk to multiple service
instances of the same service type (e.g. I had 2 
profile services).

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

To me, a WSC that wants to talk to multiple service instances
should create multiple serviceInstance objects and can therefore
do the user management themselves.

> 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:

Again, I think that you should be able to define all of the
serviceInstance interaction parameters in a serviceInstance
object.  Then use serviceInstance.SendRequest(payload, other parametsrs)
to send the request and obtain the response.

Conor