OCCI Notification

Augusto, Andy, Thijs

Problem statement

• We need to tell WHAT and when to send (state changes, ...)
• We need to tell HOW we send it �(Email, Pigeons, RSS, …)
• The transport of the notification itself is considered out-of-scope

This needs to be discoverable for the client of an OCCI implementation.

Considerations - options

• We use a notification link where the target is an OCCI entity:
• source is OCCI resource
• target is OCCI resource/URI
• Requires: definition of target kind - need to change core spec
• We user a notification link with generic target:
• with mixins on link to define what kind of notification protocol/transport (email, ping) - define a set of basics for not extension
• target is free definable
• with mixin indicating the type of notification (e.g. state changes)
• The “transport way” of the notification can be defined by a mixin applied to a OCCI resource.
• Define a set of mixins for email, http etc notification...

Option 1

Entity

Sink

target

source

NotProtMixin

NotTypeMixin

has disadvantages: specifics on client

​

Note: based on inputs from WG:

we do not take this approach!

applies

Option 2

Entity

“Sink”

target

source

Link

Notification�Protocol�Mixin

Notification�Type�Mixin

“Send Pigeon”

“On state change”

applies

aka: “State changes of the entity will appear in an out-of-bound notification sys over there”

Option 3

Entity

Sink

target

source

Link

NotProtMixin

applies

NotTypeMixin

applies

Option 3b

When the StateFul mixin is added, the provider adds to the service anything needed to notify registered targets about state changes.

Targets are registered with the creation of a link.

This is the case of internal notifications, so no notification protocol is specified

Entity

Sink

target

source

Link

StateFul Mixin

state: String, mutable

applies

Relating to Infrastructure

Only notifications that can be raised:

• state model changes
• inactive, active, error etc.
• implementers can extends as they wish

Will not specify a transport type and mappings to that transport.

Option 3c

Entity

Sink

target

source

Notify Link

StateFul Mixin

state: String, mutable

Record Link

Message Resource

content: string

issued: timestamp

expires: time interval

….

It may be appropriate to define a way to add an informational part to the notification.

Not strictly needed, since resource attributes may be sufficient.

One way to do this is by defining a specific resource for the message.

There may be many, and they may expire.

Linked to the source with a Record link.

They can be discovered

​

Option 3d (agreed?)

Same as 3b, but the recommendation contains also the message and the timestamp.

Slightly less powerful than 3c, but simpler.

The content of the message SHOULD be defined in the specs of the associated entity.

The content of the state MUST be that defined in the specs, lowercase.

Timestamp format to be defined.

Entity

Sink

target

source

Link

StateFul Mixin

state: String

message: String

timestamp: String

applies

Notes to 3d

StateFul mixin: contains three String attributes: a State, a Message and a Timestamp.

• All of them can change dynamically (which may interfere with caching).
• The user cannot change them (they are not mutable).
• The content of the String is under a MUST.
• The content of the Message is under a SHOULD.

Notify link: no attributes

The provider is allowed to (MAY) sub-type the StateFul mixin to introduce the specification of the way to deliver the notification outside the system, or anything else it likes.

The provider that offers the (optional) notification extension MUST allow the association of the StateFul mixin to ALL the entity kinds.

​

3d: three use cases

The user applies a StateFul mixin to an entity: it will be able to observe the state through the State attribute (poll needed).

The user applies a Publish mixin, a subtype of the Steteful: the state transitions will be rendered according with the mixin semantic (no poll needed).

The user applies a StateFul mixin to a resource and creates a Notify link towards another resource: state changes will be asynchronously notified to the target (no poll needed).

---

The user or the entity controller finds in the message the reason of the last state transition, and when it happened.