Example Scenario of Semantic Firewall Usage
In order to better illustrate the range of issues that need to be resolved to achieve the aim stated above we begin with a basic interaction scenario between two service providers and a client. The scenario aims to highlight the difficulties arising once just two service providers need to interact to achieve a client's goal and the associated delegations that must take place. We illustrate these interactions in Figure 1, through the use of an interaction diagram. In this example, Client A needs to make use of Service Provider B, in order to perform an operation, but requires that the data for the operation is provided to B by Service Provider C. Each party is operating from a different policy domain and B and C have no prior knowledge of the existence of each other. The required interactions begin with A requesting from C that the data is transmitted to B. Then C must notify A that the data is at B (although B could also potentially notify A), so that A can request from B to run the operation on the data and provide the results.
Now, as a means for stimulating debate about how we should resolve the various problems that are raised by a scenario as the one above (which is discussed in more detail in the 3-page abstract for the Web Services Symposium) we take a "walk-through" approach, highlighting and discussing some of the relevant issues and possibilities at each step. First we present some relevant policies, then look at how this policy information can be disseminated between the different domains, what reasoning needs to be done by the different domains, and what resulting "unified" policies may emerge.
We begin by introducing some policies for the different domains.
These policies illustrate a number of relevant issues. The policies imposed by the domain of Service Provider B raise the issue of delegation of rights from A to C so that C can send the data to B (rule 1). At the same time C should be authorised by A to accept the results of the operation (rule 2). Rule 3 imposes a certain flow on the series of interactions where an action before the request for operation should be payment. Rule 4 states that Service Provider b should not bother with complex scenarios (such as ours) because the cost of setting up the scenario is not worth it unless service provision is more than 400 units worth.
With Client A we have policies that limit what Client A can do which are imposed by the domain within which A is operating (rule 1), restrict the kind of services it can access based on their security capabilities (policies 2 and 3).
With Service Provider C, some more necessary steps to any resulting interactions
are added by Rule 1, as well as restrictions on the kinds of services
that can cooperate with Service Provider C. However, the restriction in
this case is more general than in the case of Client A, illustrating the
significance of semantic reasoning.
Policies and ontologies defined by Andrzej Uszok.