Common interface-based specification techniques are limited in their ability to deal with dynamics, architecture, and quality of service. An interface alone defines only ``syntactic'' conformance: Implementations must respond to the listed operations. An interface adorned with descriptions of the nature of operation arguments and results defines per-operation functional conformance. But even this does not always provide sufficient information for designers and implementors to ensure that components in open systems behave as desired. A new interface-compatible component may not actually interoperate with an existing one if it fails to send the same kinds of messages to other components in the course of providing services. Such concerns often overwhelm those surrounding service functionality[21,20,27].
The remainder of this paper describes PSL, a framework for specifying the dynamic and architectural properties of open systems. An associated technical report [39] contains additional syntactic details, examples, and elaborations omitted from this paper because of space limitations.
PSL adds four kinds of specification constructs to interfaces: Abstract attributes are descriptions of properties that may vary across time. These include the special properties in and out describing the reception and issuance of messages. Situations are contexts in which attributes assume particular values. Protocols describe required temporal relationships among the instances (``realizations'') of situations. Constraints describe invariant relationships among the values of attributes.
PSL differs from most other approaches to specification (see Section 12) by mirroring the intrinsic incompleteness of open systems. PSL specifications document sets of properties and constraints without claiming that these fully describe a system, or ruling out the existence of unmentioned components, situations, or events. Thus, PSL lacks some familiar constructs found in ``closed-world'' formalisms. In particular: (1) PSL does not support the use of frame axioms asserting that properties that are not otherwise mentioned in one situation are not changed from those in predecessors. (2) PSL does not contain step operators asserting that given states occur at the ``next time step'' after others; thus that there are no intervening situations. ( Step is also implicit in the description of transitions in most state models.) (3) PSL does not support leaf interfaces asserting that interfaces have no possible extensions; thus that instances do not support additional operations. (4) PSL does not contain any notion of a leaf state asserting that a situation has no possible subsituations; thus that no further state decomposition or unmentioned events exist. These omissions make way for the kinds of refinement and extensibility necessary in the development of open systems.
Types and Interfaces in PSL.
As a basis for specification, PSL relies on any framework for
declaring interfaces, operations, and pure value types such as
integers, records, etc. Rather than establishing a novel syntax, we
illustrate using PSL/IDL, a concrete syntax for PSL with CORBA IDL
value and interface types and C++-style expressions. All PSL/IDL
constructs appear as annotations within protocol module
declarations. Protocol modules have the syntactic properties of IDL
modules but contain only type declarations, attribute function
declarations, and/or rules declarations that consist of an
optionally named parameterized scope containing one or more rules.
Because textual representations of even simple protocol rules stretch
the limits of readability and writability, we simultaneously define
PSL/IDL-G, a semigraphical form corresponding in simple ways to the
textual version.
PSL/IDL uses C++ expression syntax over CORBA IDL value types. Predicates are boolean expressions. For convenience, we add the logical implies operator (`` -->'') and its left-sided version, is implied by (`` <--'') to the list of boolean operators. Within expressions, commas may be used as low-precedence and separators. To make them more useful in specifications, PSL/IDL predefines common pure value functions ( head, tail, empty, contains, prepend, append, concat, equal, remove) on IDL sequence and string types.
Handles.
A role may have finite temporal existence. However, the lifetime of a
role need not be coextensive with that of any given implementation
object. Instead, lifetime properties are described with respect to
the liveness of handles used to access instances. In PSL,
each distinct instance of a role is ascribed a unique handle. Handle
types are abstractions of names[47], references[51],
ports[63], and static labels used to identify role instances
and message destinations. Handle types may include values that do not
provide access to implementations (as in the case of ``null'' and
``dangling'' references), in which case we say that the handle is not
live. The relation `` =='' among handle values denotes
only (``shallow'') value equality, not necessarily identity or
equality of implementation-level components. PSL/IDL handle values
are expressed using the syntax of IDL objrefs. These serve as
both references to instances of IDL interfaces ( not
necessarily their implementations) and destinations of CORBA messages.
However, as discussed in [39], PSL handle values need not
bear a one-to-one relation with CORBA objref implementations.