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

[Cahill, Conor P]

> > 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.
> 
> I would build that up from a primitive that would invoke a 
> service at a particular EPR with credentials, etc. Then you 
> can wrap that with an API that can do the DS lookup 
> internally and use that to feed the EPR to the lower level call.
> 
> That way I can utilize the SSOS to get my credentials if I 
> have the EPR already, but the same code is used underneath.

I'm fine with that.  That's what I do internally anyway (the
different methods of initializing the service connection use
each other as necessary).

> 
> > > 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)
> 
> I would probably advocate for separating the object being 
> passed in the request (the payload) from the service 
> instance, but that's how I model the XML information. Though 
> that's somewhat more critical in, say, SAML protocol since 
> the payload often needs to be signed itself.

I'm all for separating the object passed in the request (payload
as well as, say, Action URIs) from the service instance.   I
just saw this as:

	response = si.SendRequest(payload, other parameters).

> I would tend to see a service instance as a type-safe API 
> (payload objects in and out) on top of some transport layer 
> (i.e. a SOAP client).

Absolutely.  The serviceInstance object should do all of the 
id-wsf management for the WSC (such as processing the 
EndpointReferenceUpdate, validating the inRespTo in the
response message (paring it to the request id), etc.).

I also found it quite helpful for the WSC if the id-wsf layer
looked into the first child of the response and examined the 
Status element since that was consistent across services (so 
each WSC didn't have to do that).

Conor