Re: Telecon on new WSPL use-cases

[Frank Siebenlist <franks@mcs.anl.gov>]

Hi all,

To facilitate the use case discussion, here are some words that describe the scenarios:

----------------------------------
Mixture of Tim's use-case 1 and 3
----------------------------------

in 1, the consumer send its request according to its policy, and gets a fault back it that policy was not acceptable with optionally 
the provider's policy attached.

The issue with this scheme is that the consumer has to send/reveal the request data to the provider, which may not be a good thing.

One idea that we were toying with is the use of a generic "ping" interface/porttype that could be used for this purpose.
If the consumer sends the ping request protected with its acceptable policy to the provider, and the provider accepts this, then 
after the return, the consumer  knows that the subsequent application request will be accepted.
If the policy was not acceptable by the provider, it can generate a fault and optionally send its policy with it.

This is similar to 1, but it doesn't reveal application data.
It is similar to 3, but it uses its own policy for the initial request, which when accepted by the provider, the consumer doesn't 
have to combine policies anymore.

Tim brought up the following valid arguments:

 > The difficulty I am having with the "ping" (or "policy probe") use-case is
 > that I can think of one situation where it wouldn't appear to work.  The
 > case I am thinking of is where (in addition to other things) the Provider's
 > service request policy defines the scope of protection (i.e. what contents
 > of the request have to be protected).  If the "probe" doesn't include a
 > reasonable facsimile of a service request, then it can't demonstrate
 > conformance with that aspect of policy.  I am sure there are ways around
 > this.  What did you have in mind?

Maybe we should add some wording about this ping/policy-probe as a possible optimization of Tim's 3rd scenario with the caveat that 
you bring up, which arguably would apply to a small percentage of services.

An additional scenario for a ping/policy-probe that we are facing right now in our implementation, is the "poking" through 
intermediaries. Imagine that there are intermediate routing/forwarding/load-balancing components between requester and provider, and 
each of these has its own policy. The requester may not know all these components in advance (even with ws-routing), but the routing 
elements will enforce their own policy, which may force the requester to deal with multiple "faults" from intermediates.
A ping-like operation could setup the "channels within channels" that are necessary for the ultimate request to pass to the provider.


----------------------------------------------------------------------------------
* The use of (specialized) registries to retrieve policy information (not UDDI...)
----------------------------------------------------------------------------------

One use that we want to explore is domain specific registries, meaning that you will have many different registries out there, and 
they specialize in certain types of information in certain formats.

The general idea is that there is too much choice in policy languages and formats, and that we may never be able to solve that 
problem. If we have a dedicate registry/discovery service that consumers "know" will have policy information of a type and format 
that they can understand.

These registry services will actively go to the consumers and providers to pull the policy information out through a request, and 
then make that policy information available in a format that is understood by those that query.

One could have multiple policy registry services that collect policy information from the same services but present it in different 
formats for their own domain.

The other important point is that these policy registries pull, which implies that the services do not need to be aware of their 
existence and don't have to register. They should register with other registries to publish general info and porttype info, which 
will be used by the policy registries to find the services and query about their policies.

This patttern would solve some of the scalability and knowledge problems that you have and allows you to bootstrap from a generic 
registry with minimal configuration on the service's side.

Some consumers are not capable to speak many of these policy dialects. A group of them come to the agreement to simplify things as 
follows: for their domain of interest, the only supported secure protocol will be ssl with client cert issued by a certain CA. To 
service this domain of interest, a specialized policy registry service is developed that has a porttype where one can ask whether a 
certain service is capable of "talking" ssl and accepts client certs issue by XYZ. This specialized registry service is build to 
translate different policy types and formats to answer the simple question asked. Furthermore, you want the services to be unaware 
of the limited policy negotiation capabilities of these consumers. In essence you try to abstract a world of endless possibilities 
behind an interface that makes sense within your domain of interest.

The philosophy behind this approach is very much responsible for the OGSA service design with its so-called "service data", 
discovery services, and such. It is an acknowledgement that we won't be able to solve the multi-lingo problem, nor the one single 
directory, nor the one-and-only-one schema, etc.

---
Regards, Frank.


Tim Moses wrote:
> Colleagues - I have organized a teleconference to discuss Frank's proposals
> for new use-cases.  Here are the details.  All the best.  Tim.
> 
> Date: Tuesday 8th April.
> Time: 4:00pm EDT (1:00 PDT).
> Duration: 1 hour.
> Tel: 613-688-3270
> Passcode: 890 320#
> 
> -----------------------------------------------------------------
> Tim Moses
> 613.270.3183
> 

-- 
Frank Siebenlist              franks@mcs.anl.gov
The Globus Project - Argonne National Laboratory