[wsf-dev] ID-WSF Stack, starting point
Scott Cantor
cantor.2 at osu.edu
Sat Feb 10 01:06:19 EST 2007
> 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.
> > 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 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).
-- Scott
More information about the wsf-dev
mailing list