Use Case Title: SOA Execution Context
Version |
|
Date/Time |
3 February 2008 |
Original author |
Ken Laskey |
Current lead |
|
Last Modified By |
Ken Laskey |
Primary Actors |
service provider, service consumer |
Secondary Actors |
|
Application domain |
Service oriented architecture |
Triggering event |
Service consumer initiates interaction |
Purpose/Goals (Summarize what the use case is to accomplish)
Establish the set of conditions that ensures a prospective consumer of a SOA service has identified the appropriate service to address its needs and to ensure for a possible provider of a SOA service that the consumer is authorized to use the service. In addition, the consumer and provider must agree on specifics of message exchange and the semantics of the exchanged messages, both message type and content.
Issues and Relevance to Uncertainty (Summarize how relevant to uncertainty reasoning and representation?)
Service consumer may have insufficient information about provider's capabilities and associated requirements to ascertain whether service provider can meet needs at acceptable cost. (UncAnn - UncertaintyNature: Epistemic; UncertaintyType: could be Ambiguity or Vagueness)
Service provider may have insufficient information about consumer's need to know whether the functionality it provides can meet that need. (UncAnn - UncertaintyNature: Epistemic; UncertaintyType: could be Ambiguity or Vagueness)
Assumptions/Preconditions (List the preconditions necessary for this use case to occur, including description of necessary context)
- The service provider has made visible a description of the functionality that results from interacting with the service.
- Both consumer and provider have made visible descriptions of their assumptions, technical and business requirements, and policies under which an interaction can proceed.
Required resources (List resources, such as data sources, ontologies, needed for scenario)
- Service descriptions created and made visible to consumer.
- Provider and consumer reference functionality, technical conditions, policies, etc. that have descriptions which are visible to each other.
- Mechanisms exist to facilitate matching alternatives in functionality, technical conditions, policies, etc.
Successful End (Describe what happens if this use case is successful)
The service consumer is satisfied that the service provides the required results (i.e. real world effects) and the consumer and provider have aligned their assumptions, technical and business requirements, and policies so that use of the service may proceed.
Failed End (Describe what happens if this use case fails)
The service interaction will not proceed but in the best case the consumer and provider have sufficient information to know what broke down in establishing the execution context.
Main Scenario (List the sequence of events for the basic course (numbered))
- Consumer compiles or otherwise accesses a list of services whose descriptions indicate certain business functionality.
(Uncertainty in whether list is complete, whether list is appropriate as match to desired need UncertaintyNature: Epistemic; UncertaintyType: could be Ambiguity or Vagueness)
- Consumer compares described functionality of each service against his/her needs.
(Uncertainty as to whether description is complete enough, i.e. has covered sufficient aspects of consumer needs; are semantics aligned so terms mean same thing or consumer knows correspondence when terms different. UncAnn - UncertaintyNature: Epistemic; UncertaintyType: could be Ambiguity or Vagueness)
- Consumer takes subset for which functionality match is most promising and compares other assumptions, technical and business requirements, and policies. For example, consumer may have policy that if s/he provides contact information, the service provider must not use the information for a purpose other than this interaction.
(Uncertainty same as for step 2. UncAnn - UncertaintyNature: Epistemic; UncertaintyType: could be Ambiguity or Vagueness)
- Consumer engages with provider to resolve any disconnects. Either consumer or provider may decide to proceed even if not satisfied that all disconnects are completely resolved.
(Uncertainty in that consumer and provider may not have complete understanding of resolutions, e.g. a number of circumstances are covered in resolutions and one party not sure how all the permutations work but does not feel further delay is justified in to work more details. UncAnn - UncertaintyNature: Epistemic; UncertaintyType: could be Ambiguity or Vagueness)
- Service used and interaction completed.
(Uncertainty as to whether consumer needs have been satisfied. UncAnn - UncertaintyNature: Epistemic; UncertaintyType: could be Ambiguity or Vagueness)
Additional background information or references (Summarize/provide references to information to further describe or characterize use case)
As defined in the OASIS Reference Model for Service Oriented Architecture (SOA-RM), the execution context of a service interaction is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction, and thus forms a path between those with needs and those with capabilities.
As discussed in SOA-RM, the service description (and a corresponding description associated with the service consumer and its needs) contains information that can include preferred protocols, semantics, policies and other conditions and assumptions that describe how a service can and may be used. The participants (providers, consumers, and any third parties) must agree and acknowledge a consistent set of agreements in order to have a successful service interaction, i.e. realizing the described real world effects. The execution context is the collection of this consistent set of agreements.
Variations (List the alternatives that will not be further decomposed at this time)
Open Issues