Specification - Plastic
$Header: /cvsroot/ist-plastic/Plastic/web/docs/plastic0_5.html,v 1.1 2006/08/11 14:28:04 jwskene Exp $
$Log: plastic0_5.html,v $
Revision 1.1 2006/08/11 14:28:04 jwskene
Updated with new release
Revision 1.14 2006/08/11 13:41:11 jwskene
Documented and compiled.
Revision 1.13 2006/08/11 11:34:40 jwskene
Comments done
Revision 1.12 2006/08/10 17:06:18 jwskene
More documentation.
Revision 1.11 2006/08/10 16:32:48 jwskene
Compiles, 50% documented
Revision 1.10 2006/08/07 16:29:23 jwskene
PLASTIC conceptual model as redeveloped by Autili, Di Ruscio and Skene. Some comments done.
Revision 1.9 2006/08/03 09:00:50 jwskene
Updates to plastic conceptual model
Revision 1.8 2006/07/04 14:05:02 francoraimondi
revision of all comments in conceptualmodel
Revision 1.7 2006/06/28 12:59:39 jwskene
Preliminary merge of conceptual model with technology-independent concepts from SLAng.
Revision 1.6 2006/06/28 02:50:14 francoraimondi
End of comments from D1.1
Revision 1.5 2006/06/27 01:51:52 francoraimondi
More documentation included
Revision 1.4 2006/06/23 16:23:13 francoraimondi
Some corrections from latest version of deliverable
Revision 1.3 2006/06/22 15:48:43 francoraimondi
Initial documentation
Revision 1.2 2006/06/21 16:29:07 francoraimondi
Added CVS fields
This is the EMOF translation of the conceptual model for PLASTIC, based on
Deliverable 1.1
(see http://www-c.inria.fr:9098/plastic/deliverable/year-1).
This preamble establishes the basis for interpreting the specification.
The specification is written in a combination of three languages:
English, a concrete syntax for EMOF, and OCL2.
EMOF and OCL are defined respectively by the following specifications:
- The OMG MOF 2.0 Core Final Adopted Specification
Available: http://www.omg.org/cgi-bin/doc?ptc/2003-10-04
- The OMG UML 2.0 OCL Final Adoped Specification
Available: http://www.omg.org/cgi-bin/doc?ptc/2003-10-14
The relationship between the EMOF concrete syntax and the EMOF abstract
syntax is straightforward. It is implemented in the JavaCC grammar
contained in the UCL MDA Tools project on sourceforge.net in the file
EMOFOCL/uk/ac/ucl/cs/emofocl/parser/emof.jj
The language definition consists of a model of SLAs and the service
environment that forms their context. The part of the model that models
SLAs defines the abstract syntax of the language. The relationships between
the syntactic part of the model and the part of the model modelling services
define the semantics of the language.
Disregarding any statement to the contrary made in the MOF or
OCL2 specifications, this is a model of real-world objects and
relationships, at a particular level of abstraction. The types of services,
parties and data described in the model are descriptions of these things as
they exist in the real world. The types of specification artifacts such
as SLAs, and parts of these artefacts, are descriptions of concrete
artefacts in the real world.
This specification offers several things:
1. A model of the commonly understood reference concepts for the Plastic
project and architecture.
and 2. A definition of when a scenario can be considered to be an instance
of this Plastic model, and therefore a Plastic scenario.
and 3. A definition of how the parties interacting with the Plastic
architecture should behave, for example when they are bound by SLAs.
and 4. Informal comments on the use of the model and its meaning, which
are not definitive.
A scenario in the real world can be considered to be a Plastic scenario
under the following conditions:
1. All objects in the real world relevant to the scenario conform to
one of the concrete types defined in this specification, according to
the definition of type conformance given below.
For every type of real-world object relevant to scenarios, we offer:
1. A definition of the type in our concrete syntax for EMOF, including a
name (in English), properties with names (in English), and a full type
definition according to the EMOF specification.
and 2. A comment on the type, in English, that is labelled "Definitive:"
and 3. A comment on each property, in English, that is labelled
"Definitive:"
and 4. Possibly one or more type invariants expressed using OCL2, labelled
"Wellformedness:". These constraints must always hold true in any
situation in which an agreement on a SLAng SLA can be said to exist. The
English description accompanying these constraints is not meaningful for the
purposes of determining type conformance, but is intended to assist human
interpretation of the accompanying OCL constraint.
and 5. Any number of comments on aspects of the type labelled "Informal:".
These comments are not definitive of the language, but are intended to
aid comprehension of the definitive parts of the specification.
A real-world object under inspection can be interpreted as conforming to a
type described in this model if:
a. It is compatible with the definitive description of objects of this type
given in this specification.
and b. It has all of the properties of objects of this type, and all
those properties are compatible with the definitive descriptions of the
properties given in this specification, and the values of
those properties conform to the definitions of the types of the respective
properties given in this specification, per the definition of compatibility
defined here.
and c. It meets all "Wellformedness" constraints on those objects defined
in this specification, as per the semantics of OCL2, and the
interpretation of all properties as objects conforming to types
described in this specification.
How parties should behave:
Parties and their behaviour are construed as objects conforming to types in
the model. They should therefore behave according to the descriptions
and constraints associated with the model. If parties violate these
constraints, for example by refusing to participate in the administration
of an SLA, then a scenario may no longer be considered to be a normal
Plastic scenario, and the Plastic project will not formally address these
cases.
Informal advice:
Non-definitive comments in this specification are labelled as "Informal:".
Contents:
Informal: Contains types used in both the syntactic or semantic model.
Definitive: An enumeration type used to indicate a unit of time
associated with some quantity in the model.
- S
Definitive: Seconds.
- mS
Definitive: Milli-seconds.
- nS
Definitive: Nano-seconds.
- min
Definitive: Minutes.
- hr
Definitive: Hours.
- day
Definitive: Days (24 hours).
Definitive: Identifies the type of an AccessDevice.
Definitive: Identifies the type of an execution environment.
Definitive: Identifies the type of a network.
- WIRELESS
- LAN
- GPRS
- UMTS
- WAP
Definitive: In the syntactic model, indicates a percentage written in
an SLA. In the services model, this is the type of features of an
object that can be interpreted as a degree of completeness of some
totality.
Properties:
Operations:
Invariants:
-
Wellformedness: Percentages are expressed as a value greater
than 0.
value >= 0
Definitive: In the syntactic model a duration is the specification of
a length of time. In the services model, a duration is either an
actual length of time, or a record of a length of time.
Properties:
Operations:
- inMs() : ::types::Real
Informal: Converts this duration to a number of milliseconds.
Evaluates to:
if unit = TimeUnit.mS then value
else
if unit = TimeUnit.nS then value / 1000
else
if unit = TimeUnit.S then value * 1000
else
if unit = TimeUnit.min then value * 1000 * 60
else
if unit =
TimeUnit.hr then value * 1000 * 60 * 60
else
value * 1000 * 60 * 60 * 24
endif
endif
endif
endif
endif
- eq(s : ::types::Duration) : ::types::Boolean
Informal: Defines non-object equality for duration objects.
Evaluates to:
inMs() = s.inMs()
Invariants:
-
Wellformedness: Durations should never be negative.
not (value < 0)
Definitive: In the syntactic model a date is the specification of
an instant in time. In the services model, a duration is either an
actual instant time, or a record of an instant of time.
Properties:
Operations:
- inMs() : ::types::Real
Informal: Converts this date to the number of milliseconds that the
date is after 00:00 Jan 1, 2000, UTC+0.
Evaluates to:
sinceJan12000.inMs()
- eq(d : ::types::Date) : ::types::Boolean
Informal: Defines non-object equality for date objects.
Evaluates to:
sinceJan12000.eq(d.sinceJan12000)
Invariants:
Definitive: A value is a piece of specification information. It may
have a unit, allowing it to denote a physical quantity. It may have
one of a number of concrete types, extending the abstract notion of
value.
Properties:
Operations:
Invariants:
Extends: ::types::Value
Definitive: A concrete type of value, expressed as an integer.
Properties:
Operations:
Invariants:
Extends: ::types::Value
Definitive: A concrete type of value, expressed as a real.
Properties:
Operations:
Invariants:
Extends: ::types::Value
Definitive: A concrete type of value, expressed as a string.
Properties:
Operations:
Invariants:
Definitive: A user-defined unit. Units may be associated with
numerical values to denote a physical quantity.
Properties:
Operations:
Invariants:
Definitive: A user-defined relationship between units.
Properties:
Operations:
Invariants:
Definitive: In the syntactic model, indicates real numbers written into
SLAs. In the service model, this is the type for attributes of an
object that can be interpreted as having a value within a continous
range.
Equivalent to the OCL real type.
Definitive: In the syntactic model, indicates a value of true or false
written into SLAs. In the service model, this is the type for
attributes of an object that can be interpreted as being either true
or false.
Equivalent to the OCL boolean type.
Definitive: In the syntactic model, indicates an whole number
written into an SLA. In the service model, this is the type for
attributes of an object that can be interpreted as being a natural
quantity.
Equivalent to the OCL integer type.
Definitive: In the syntactic model, indicates some text included in
an SLA. In the service model, indicates some information present
in the domain.
Equivalent to the OCL string type.
Informal: The conceptualmodel packages groups types from the PLASTIC
conceptual model.
Informal: The specifications package groups all specification types.
Specification types either model documents and their syntactic
components in the PLASTIC domain.
Informal: The service package contains types used to describe
services.
Definitive: A service description is the description of a
concrete service held in a PLASTIC repository.
Properties:
Operations:
Invariants:
Definitive: A function service specification defines all
invariant aspects of a service.
Properties:
Operations:
Invariants:
Definitive: A signature specification defines the signature
of a service interface.
Properties:
Operations:
Invariants:
Definitive: An operation specification is part of an interface
specification and defines an operation that a particular
service exposes.
Properties:
Operations:
Invariants:
Definitive: An exception specification describes an exception
thrown by a service.
Properties:
Operations:
Invariants:
Definitive: Pre- and post-conditions define conditions on
the state of a service that should hold before and after
an operation invocation.
Properties:
Operations:
Invariants:
Definitive: A semantics specification defines aspects of the
semantics of a service using invariant properties.
Properties:
Operations:
Invariants:
Definitive: A service invariant is an observation regarding
the state of a service that always holds true in conforming
services.
Properties:
Operations:
Invariants:
Definitive: Consumer-side additional information is auxillary
service description information maintained by PLASTIC
repositories, and contributed by service consumers.
Properties:
Operations:
Invariants:
TODO: What should usage histories contain? Why are they
useful?
Properties:
Operations:
Invariants:
TODO: What should user profiles contain? Why are they useful?
Properties:
Operations:
Invariants:
TODO: How should service ratings work?
Properties:
Operations:
Invariants:
Definitive: A capability specification defines a capability
of a service in terms of a number of conversations.
Properties:
Operations:
Invariants:
Definitive: A conversation specification is the specification
of one or more conversations, which are templates for component
interaction.
Properties:
Operations:
Invariants:
Informal: The adaption package contains types describing
adaption specifications.
Definitive: An Adaption Specification defines one way that an
adaptive service or component should adapt itself.
Properties:
Operations:
Invariants:
Informal: The component packages contains types describing
component specifications.
Definitive: A component specification contains the logical
definition of a component.
Properties:
Operations:
Invariants:
Definitive: A component interface specification defines the
the structure of an interface of a conforming component.
Properties:
Operations:
Invariants:
Properties:
Operations:
Invariants:
Definitive: A component implementation specification specifies
the implementation of a component.
Properties:
Operations:
Invariants:
Informal: The sla package contains types describing the syntax
of SLAs used in the PLASTIC project.
Definitive: A context aware SLA is the concrete record of an
agreement between two parties on the performance of some
service. In PLASTIC it is the result of accepting an offered
SLS.
Properties:
Operations:
Invariants:
Informal: The context package contains types describing
specifications of the physical and logical context of components
and applications.
Definitive: At an abstract level, all context specifications
consist of a set of attributes which describe the specifics
of the context.
Context specifications may also describe a set of qualities that
pertain to the specification itself.
Properties:
Operations:
Invariants:
Definitive: Context attribute specifications are parts of
context specifications that describe particular aspects of a
context.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::specifications::context::ContextAttributeSpecification
Definitive: A location specification specifies a single real
location.
Properties:
Operations:
Invariants:
Definitive: Context specification may have any number of
qualities that define characteristics of the context
specification itself.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::specifications::context::ContextAttributeSpecification
Definitive: A number of types of context attributes define
available resources for an application or service component.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::specifications::context::AvailableResourcesSpecification
Definitive: A memory specification specifies how much
memory is available to a consumer device.
TODO: Add attributes capable of defining some memory.
What type of memory is being describe, and for what
purpose?
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::specifications::context::AvailableResourcesSpecification
Definitive: A processor specification defines a processor
made available in a consumer or provider context.
TODO: How should this be defined?
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::specifications::context::AvailableResourcesSpecification
Definitive: A battery specification defines the amount of
power available to a consumer application or service.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::specifications::context::ContextAttributeSpecification
Definitive: An execution environment specification defines
the execution environment available to a consumer application
or service.
Properties:
Operations:
Invariants:
Informal: The consumerside package contains types that are
exclusive to specifying consumer-side context.
Extends: ::conceptualmodel::specifications::context::ContextSpecification
Definitive: A consumer-side context specification
records details of the context of a consumer application.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::specifications::context::ContextAttributeSpecification
Definitive: A consumer connection specification describes
the network link providing access to the consumer.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::specifications::context::AvailableResourcesSpecification
Definitive: A screen specification defines the
characteristics of a screen on a consumer access device.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::specifications::context::AvailableResourcesSpecification
Definitive: An input device specification defines the
characteristics of an input device on a consumer access
device.
TODO: How should this be specified.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::specifications::context::ContextAttributeSpecification
Definitive: An access device specification defines the
type of device available in a consumer access context.
Properties:
Operations:
Invariants:
Informal: The package networkside contains types exclusive to
defining network-side context.
Extends: ::conceptualmodel::specifications::context::ContextSpecification
Definitive: A network-side context specification defines
details of a network.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::specifications::context::ContextAttributeSpecification
Definitive: A network specification defines the type of
network in a network-side context.
Properties:
Operations:
Invariants:
Informal: The providerside package contains types exclusive to
defining provider-side context.
Extends: ::conceptualmodel::specifications::context::ContextSpecification
Definitive: A provider-side context specification describes
a context in which services may execute.
Properties:
Operations:
Invariants:
Informal: The testing package contains specification elements
related to testing services.
Definitive: A test suite is the specification of some tests that
a service is presumed to be able to execute successfully?
TODO: What should this contain?
Properties:
Operations:
Invariants:
Informal: The sls package contains specification elements used to
specify service levels.
Informal: A service-level specification is a set of constraints
over the performance of a service.
Properties:
Operations:
Invariants:
Informal: A non-functional service specification defines
a set of constraints over the performance of a service.
TODO: Maybe NFSS and SLS should be combined?
Properties:
Operations:
Invariants:
Definitive: A version specification specifies the version
of a service.
Properties:
Operations:
Invariants:
Definitive: Pricing information is associated with a
service offer and SLA. It defines all financial matters
related to the use of a service.
TODO: Pricing information should include SLA penalties.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::specifications::sls::SLS
Definitive: A requested SLS is submitted by a service consumer
to a repository in the hope of matching an offered service. It
contains both functional and non-functional descriptions of the
service on offer.
TODO: This should be called requested SLA because it includes
pricing information.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::specifications::sls::SLS
Definitive: An offered SLS is part of a service description. It
defines a set of behavioural constraints on a service that
a provider is prepared to guarantee in return for payment.
TODO: This should be called OfferedSLA.
Properties:
Operations:
Invariants:
Definitive: QoSAttributeSpecification specify particular
constraints on the behaviour of a service.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::specifications::sls::QoSAttributeSpecification
Definitive: A metric value specification specifies the value
of some measurement of a service that should always hold for
a conforming service.
Properties:
Operations:
Invariants:
Definitive: A matching policy defines an approach that a
repository may take when matching request SLSs to offered
SLSs.
TODO: How should this be specified?
Properties:
Operations:
Invariants:
Definitive: Allows compatibility with existing standards to
be described, for conforming services.
Properties:
Operations:
Invariants:
Informal: The domain package contains types for all objects in the
domain that are not used to specify other elements in the domain.
Informal: Contains all types of domain objects that are services
or parts of services.
Definitive: The archetypical notion of service.
TODO: Do we really need this as well as adaptive service? And
as well as service specification. If two services have the
same service specification, then they implement the same
archetypical service.
Properties:
Operations:
Invariants:
Definitive: An adaptive software service is a concrete instance
of a service, provided in a particular location.
Properties:
Operations:
Invariants:
Definitive: A service interface is a point of access to a
service. It consists of a set of operations.
TODO: How should service interfaces be identified? What
different sorts of service interface should be described?
Properties:
Operations:
Invariants:
Definitive: A service operation is an identified function
of a service that can be used on the request of a service
consumer.
TODO: Semantics of service operations.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::services::AdaptiveSoftwareService
Definitive: A composite software service is a software
service that makes use of other software services to perform
parts of its functionality.
Properties:
Operations:
Invariants:
Definitive: A capability of a service is a subset of its
functionalities, exploitable by a variety of protocols embodied
by conversations.
TODO: Conversations are instances not archetypes. Do we need
an architypical conversation type to refer to, rather than
a set of concrete conversations?
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::services::Capability
Definitive: a composite capability is a capability composed of
other capabilities. All conversations of the composed
capabilities are conversations of the composite capability.
Properties:
Operations:
Invariants:
Definitive: Contains all domain model elements that are components
or parts of components.
Definitive: A software component is a unit of functionality
deployed in some context.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::components::SoftwareComponent
Definitive: A composite component is a component that uses
other components in the same context to provide part of its
functionality.
TODO: Components may communicate with each other locally. When
does this constitute a composition, and when merely a
cooperation?
Properties:
Operations:
Invariants:
Definitive: A component interface exposes part of the
functionality of a component to other components locally, or
in order to implement a service operation.
Properties:
Operations:
Invariants:
Definitive: A component operation is a unit of functionality of
a component that can be invoked synchronously and locally by
other components or used to implement a service operation.
Properties:
Operations:
Invariants:
Informal: Contains all types of domain objects forming consumer,
provider or network contexts.
Definitive: A context is an environment in which applications,
services, components and elements of the PLASTIC middleware
reside, or interact.
Properties:
Operations:
Invariants:
Definitive: A characteristic of a context that can be
described seperately from other characteristics.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::context::ContextAttribute
Definitive: Location is an attribute of some types of context.
TODO: Should contexts have more than one location? What about
network contexts?
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::context::ContextAttribute
Definitive: The availabilities of certain types of resources
are context attributes.
Properties:
Operations:
Invariants:
Definitive: Some domain mechanism may measure a context
attribute for the purpose of specifying it in a context
specification.
TODO: Need some concrete subtypes here.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::context::AvailableResources
Definitive: The amount of memory available to a processing node
is an attribute of consumer and provider contexts.
TODO: Add attributes to define specification semantics.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::context::AvailableResources
Definitive: The type and power of an available processor
is an attribute of consumer and provider contexts.
TODO: Add attributes to define specification semantics.
Should contexts have multiple processors? What about virtual
or threaded execution environments? What is the intent in
describing processors in a context?
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::context::AvailableResources
Definitive: The remaining battery life of a processing node
is an attribute of consumer and provider contexts.
TODO: Useless to know remaining battery life if we can't
predict how execution will use power.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::context::ContextAttribute
Definitive: The execution environment on a processing node
is an attribute of consumer and provider contexts.
TODO: Add attributes to define specification semantics.
Can nodes have several execution environments?
Properties:
Operations:
Invariants:
Informal: Contains all types of domain objects which only
ever form part of a consumer-side context.
Extends: ::conceptualmodel::domain::context::Context
Definitive: A consumer-side context is the enviroment in
which a consumer application executes.
TODO: Specify attributes for the context attributes that
are required.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::context::AvailableResources
Definitive: An attribute of a consumer-side context is the
screen available to interact with a consumer.
TODO: Can contexts have multiple screens? Refine to
describe specification semantics.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::context::AvailableResources
Definitive: An attribute of a consumer-side context is the
input device available for the consumer.
TODO: Multiple devices? Semantics.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::context::ContextAttribute
Definitive: An attribute of a consumer-side context is the
type of processing node (access device) being used.
TODO: Semantics.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::context::ContextAttribute
Definitive: An attribute of a consumer-side context is the
first hop network link.
TODO: Should this really be separate from network context?
Can we have multiple networking options? Semantics.
Properties:
Operations:
Invariants:
Informal: Contains all types of domain objects which only
ever form part of a network-side context.
Extends: ::conceptualmodel::domain::context::Context
Definitive: The network-side context is the environment
that conveys messages between the consumer and the provider.
TODO: Add attributes for context attributes.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::context::ContextAttribute
Definitive: The type of a network being used is an attribute
of network-side context.
TODO: Semantics. What if there are multiple types of
network in sequence? What if there are multiple choices?
What if the network provides differentiated services?
Properties:
Operations:
Invariants:
Informal: Contains all types of domain objects which only
ever form part of a provider-side context.
Extends: ::conceptualmodel::domain::context::Context
Definitive: The provider-side context is the environment in
which components implementing services execute.
TODO: Will we eventually find that there is no difference
between client and provider-side contexts, because most
devices can offer and consume services? Add attributes
for context attributes.
Properties:
Operations:
Invariants:
Informal: Contains all types of domain object contributed by the
PLASTIC project.
TODO: Refine all the types in this package as details of the
PLASTIC architecture become apparent. Capture protocols in the
events package.
Definitive: The PLASTIC middleware provides runtime support
for the deployment and use of PLASTIC services.
TODO: Is this definition archetypical or does it represent
running instances of the middleware? Same for provider
and consumer-side middlewares.
Properties:
Operations:
Invariants:
Definitive: Part of the PLASTIC middleware will support the
use of services on the consumer's side.
TODO: Archetype or instance?
Properties:
Operations:
Invariants:
Definitive: Part of the PLASTIC middleware will support the
use of services on the service provider's side.
TODO: Archetype or instance?
Properties:
Operations:
Invariants:
Definitive: Service registries will be either a component of
the PLASTIC middleware, or a special type of service, that
maintains a database of service descriptions, and performs
matching between request SLSs, and provided SLSs.
TODO: Archetype or instance? Should be request and provided
SLAs. Should this be a subclass of AdaptiveSoftwareService?
Properties:
Operations:
Invariants:
Definitive: Using the middleware implies that components must
meet some set of requirements.
TODO: This is an archetype and can be removed when the
requirements can be expressed directly in this model.
Properties:
Operations:
Invariants:
Definitive: A role identifies a participant in certain
types behaviour.
TODO: Events should refer to parties, not roles. Roles are
only useful for defining event types (architypes).
Properties:
Operations:
Invariants:
Definitive: A party is an individual, agent or organisation that
can take action in plastic scenarios.
TODO: Parties should be associated with the events that they
perform.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::parties::Role
Definitive: ServiceProvider is a type of role for parties who
provide services.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::parties::Role
Definitive: ServiceIntegrator is a type of role for parties
that integrate services (resulting in composite services).
TODO: Why is this not called ServiceComposer, like
ComponentComposer?
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::parties::Role
Definitive: ServiceDeveloper is a type of role for parties that
develop services.
TODO: Should service developers also develop components, as
components implement services?
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::parties::Role
Definitive: ServiceConsumer is a role for parties that
consume services.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::parties::Role
Definitive: ComponentAssembler is a type of role for parties
that assemble components.
TODO: Why should there be seperate roles for implementing
components and assembling components? In fact, where is
the ComponentDeveloper role?
Properties:
Operations:
Invariants:
Definitive: An event is a change of state in the domain that
occurs at a particular time.
Properties:
Operations:
Invariants:
Informal: The negotiatesla package contains all protocol events
related to negotiating an SLA.
Extends: ::conceptualmodel::domain::events::Event
Definitive: The create offer event occurs when an offered
SLS is added to a service description in a service
registry.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::events::Event
Definitive: A request policy match event occurs when a
service consumer provides a requested SLS to a service
registry and specifies the policy by which the requested
SLS should be matched to offered SLSs in the repository.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::events::Event
Definitive: A policy match event occurs when a registry
matches a requested SLS to the SLSs contained in the
registry.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::events::Event
Definitive: A negotiation is a composite event, denoting the
culmination of a sequence of offers and requests.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::events::Event
Definitive: An SLS request is made directly to a service
provider by a consumer. It contains a revised offer SLS
that the consumer wishes the provider to offer.
TODO: The whole dichotomy between request and offer SLSs
needs to be revisited, as does policy. Requests may
contain ranges and options. Offers should eventually
contain only concrete values. Both should be associated
with functional descriptions but may be considered to be
separate from functional descriptions. Both may contain
pricing information, so should be considered SLAs, or
potential SLAs, not SLSs. SLSs may still be needed in
adaption specifications.
Where is the reference to the consumer here?
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::events::Event
Definitive: An offer made by a service provider directly
to a service consumer.
TODO: How are consumer and provider referenced by this
event?
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::events::Event
Definitive: AcceptSLS occurs when a client accepts an
offered SLS. It results in an SLA.
Properties:
Operations:
Invariants:
Informal: The conversation package contains all events occuring
during a conversation between a consumer application and a
service.
TODO: The application isn't explicitly modelled as distinct
from the consumer role. This probably needs fixing.
Extends: ::conceptualmodel::domain::events::Event
Definitive: A conversation is initiated by a consumer.
TODO: Conversations may be initiated by consumer
applications.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::events::Event
Definitive: A send consumer context event occurs when
the consumer-side middleware inspects the consumer's context
in order to produce a consumer-side context specification,
which is sent to a service with which a conversation is
starting.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::events::Event
Definitive: The provider-side middleware will notify
a service provider that a conversation is about to start,
so that the provider has the opportunity to initiate
adaptions. In doing so, the middleware will also retrieve
specifications of network and provider-side contexts so
that these may be used to guide adaption.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::events::Event
Definitive: A provider may choose to adapt a service in
response to a notification that a conversation will
shortly begin.
TODO: Signal to client that conversation is ready to begin
(maybe send client adapted components). Adaption may
be automatic and managed by middleware.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::events::Event
Definitive: A conversation is a sequence of operation
usages.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::events::Event
Definitive: An operation usage consists of a request
being sent to a service, processed, and a
result returned.
TODO: Refine this with details of parameter values,
return values etc. Also need to deal with error cases.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::events::Event
Definitive: A send request event occurs when a consumer
submits an event to a service.
TODO: Remodel this to include network events.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::events::Event
Definitive: A service request event occurs when a service
performs so processing in response to a request.
TODO: Refine. Link to request probably.
Properties:
Operations:
Invariants:
Extends: ::conceptualmodel::domain::events::Event
Definitive: A send response event occurs when a service
returns a response to a client following a request.
TODO: Remodel this to include network events.
Properties:
Operations:
Invariants:
| 
as a STREP.