For commercial application of web services various constraints must be applied to enable control, management, and monitoring. These constraints are applied sometimes as single constraints, such as requiring that the service be monitored, or as multiple constraints such as requiring authentication and encryption before accessing the service.
These separate and independent constraints need to be described for both the service provider as well as the service consumer. Constraints may be applied as rules, policies and policy sets such as what the eXtensible Access Control Markup Language (XACML) standard specifies. These constraints need to be specified and applied in a form neutral to both platform and domains enabling interoperability.
For a company such as Boeing Commercial Airplanes, with customers, suppliers and partners scattered around the world, working with both governments and commercial enterprises, interoperability and neutrality is a key issue to enable our applications to be successful. Web services may have this potential, but progressing from "may have potential" to "does have this capability" takes some effort..
Describing a web service requires describing not only the basic information of where and how, but also under what conditions it can be used. These constraints and capabilities provide the capability as well as the protection needed for the commercial application of web services. These conditions can be specified through descriptions such as UDDI and WSDL. These conditions can be satisfied by a number of means, technical, process, or manual. HTTP and SOAP headers allow specific information to be inserted into the request and response to determine if the constraints are satisfied before extensive processing begins. Constraints need to be specified, enabled, processed and verified. The question becomes one of how can these be specified. These constraints should be communicable in multiple ways, and to satisfy them in ways suitable for the web services "platform".
There are a number of means to specify and satisfy basic constraints of security and connectivity. What is needed beyond this are further constraints of authentication, confidentiality, and reliability. Specifications for these need to be platform and transport independent for developers to use and applications to access. It is vital that this information is accessible to development environments at design time, and available to applications at run time to increase the capability of developers to deal with these and applications to respond to them.
First there is a need to express constraints in a way that is flexible and communicable to a broad range of platforms and systems. Just as the promise of web services is to provide a platform independent means to specify and use interfaces to services, so do constraints also need to be articulated and evaluated in a way that continues this capability.
Second constraints need to be combined in ways similar to XACML combining algorithms - deny override, permit override, first applicable, and only one. For"permit override" if several rules are in place and if one has the state of "permit" then the constraint is satisfied.; For"deny override" several rules are in place and just one is "deny" then the result is to deny use. There is the combining algorithm of "only one" but this has more to do with maintaining a consistency check of the rules rather that be directly applied to the rules. These as a starting point and not an exhaustive list of how constraints should be evaluated and combined. From this description there are many uses of these beyond security to constraints in general.
Constraints need to address not just those relating to security, including authentication, confidentiality, and integrity; we also need to address monitoring and availability; orchestration and dependencies.
In applying process constraints one could use the concepts of Business Process Modeling Notation (BPMN) . For a process, a service may be an explicit step of a process, or it may be a message to effect a process. In this context there may be dependencies that this service is appropriate for a specific portion of a process, but for other purposes. An example of this would be notification to a production system of inventory at a number of locations. This takes the form of a message that in turn provides status to a production manufacturing process, thus triggering production if inventory falls below a certain point. The result of this service is not the requestor directly, but as part of an overall system of other steps. In other instances a service would be used as a step in a process, receiving information and then spawning other requests as a result. In this later case there may be requirements to a specific interaction of a number of services for the request, confirmation, and result as part of a larger process.
The use case in the call for papers stated:
A Web service wishes to stipulate that clients are required support a reliable messaging protocol, and encrypt a specific header with WS-Security using a X.509 or user name security token in order to send an acceptable request message. Furthermore, the service has a P3P policy associated with its operations. Such constraints and capabilities might be associated with the Web service via a SOAP header or a WSDL file.
In this case the basic constraints of authentication, confidentiality, and reliability are communicated via a WSDL description, and accomplished through the SOAP header of the request. Specifying these constraints for developers to use and application to access needs to be platform and transport independent. This information is important to have accessible to development environments at design time, and available to applications at run time.
An extension of this could be:
A Web service wishes to stipulate that clients are required support a reliable messaging protocol, and encrypt a specific header with WS-Security using a X.509 or user name security token in order to send an acceptable request message. Furthermore, the service has an availability policy associated with its operations. The request is required to sign specific portions in order to maintain integrity and verify that these portion have not been altered for both safety and regulatory audit reasons. Such constraints and capabilities might be associated with the Web service being specified as an extension to a WSDL specification. These constraints may be satisfied through the XML-DSig specification. In addition this service has the constraint that is is available only as a specified step as part of a larger orchestrated process and a request to this service will result in other services being requested. Without these dependent services being available the service will return a "no result" response.
In specifying constraints for web services there needs to be a mechanism that can be used by development environments to automate satisfying them so that development can proceed without having extensive development. This linkage between the specification and development as is now exhibited with UDDI registries, now needs to be taken further to not just enable using the web services specified, but also to establish a context where the service can be used. This context of constraints can be used both to use the service in a commercial environment requiring some degree of security, as well as where the web service may fit best in the case of process or orchestration constraints establishes the context for a service that in enables a developer to determine if the service is appropriate.
Constraints are a very broad area to address, but in any operation they are an expected part of business. There are few services that are open to anyone that makes a request. The constraint may be as simple as what form the request is made and the response given, or it may go beyond that to include possessing an identity that van be verified for authentication, securing a portion of the request through encryption, requiring a reliable means for the request as well and verifying that the data will be treated properly through a stated privacy policy,. Mechanisms to satisfy these constrains may vary, the platforms used to make the request as well as servicing it will be different, but if we can articulate the constraints it becomes less important how they are dealt with than that fact that they exist and WILL be dealt with.
As a commercial airplane manufacturer we deal with a wide range of constraints. Without some means to articulate them it becomes more difficult to automate the process of application integration across systems and organizations. This effort is needed to make services and processes easier to deal with. Web services and it's associated specifications are a start, and this can be seen as a needed further step.
Gerald Edgar
gerald.edgar@boeing.com
$Date: 2004/10/05 16:39:30 $