OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

obix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: More detail on Contracts in oBIX 1.1

Some thoughts on pre-defined oBIX contracts.

1)      The entire concept of pre-defined contracts is optional. Any error defining or invoking a pre-defined contract (functionality not available) must be accepted by the client as legal. This protects backward compatibility – and continues forward to devices to lightweight to accept pre-defined contracts.

2)      If a device implements any of the pre-defined contract specification, then it must implement it all. Contract definitions can be refused for any number of reasons, either because a 1.1 device is too lightweight to accept them, or perhaps because the contract space is full up. As above, the client must be able to understand this.

3)      Pre-defined contracts might be the beginning of a security model for oBIX. Delineating devices, installing points, then, is a Configurator role. Pre-Defining a new contract might be limited to programming mode, or to the integrator role. Invoking the contract then might be limited to the Operations role, or even to the End User role. We should begin to imagine roles, even if we are not ready to implement them.

4)      If we have pre-defined contracts at all, then we have defined several meta-behaviors around pre-defined contracts. I think these behaviors can all be defined as instances of already existing behaviors. They include:

1)      List contracts

a)      Invoke existing contract

b)      Invoke existing for time period

c)       List existing contracts in force

d)      Trend log on the meta-trend – contracts invoked

e)      Update existing contract

f)       Delete Existing contract

5)      Contract Invocation nestles nicely in receiving an ICAL from the enterprise. Other use cases include:

a)      Emergency Management CAP interactions

b)      ADR event level 2

c)       Peer to Peer functions in loosely coupled environment. May be cross silo invocations

d)      Conference room occupation

6)      Future issue: Capacity

-          I would like to have a capacity component. “Set table for n” in dining room contract. I do not think we are ready for this level of abstraction/function. For now, this can be handled with a

o   SetTableFor-1-3

o   SetTableFor-4-8

o   SetTableFor-10-15

-          Long term, however, I’d like this too fall into oBIX




"There are a thousand hacking at the branches of evil to one who is striking at the root." -- David Thoreau

Toby Considine

Facilities Technology Office
University of North Carolina
Chapel Hill, NC


Email: Toby.Considine@ unc.edu
Phone: (919)962-9073




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]