Accountable objects: Modeling Liability in Open Distributed Systems

Accountable objects: Modeling Liability in Open

Distributed Systems

Antonio VallecilloUniversidad de MálagaVienna, January 28, 2013

[Joint work with Peter F. Linington and Hiroshi Miyazaki at ISO/IEC]

The Supply of Olive Oil

We use a very simple e-commerce example to explore these ideas:

A business (The Modern Oil Store) acts as a supply channel from producers to customersIt uses external contractors to perform deliveriesThe buyer pays on receipt of theoil

Vienna, 2013A.Vallecillo: "Accountable Objects: Modeling Liability in Open Distributed Systems" 2

Main Characters (Roles)

Customer Supplier

Producer Carrier


The Supply of Olive Oil

Imagine that at one given moment in time, the supply process does not work as specified by the contract, e.g., the olive is not delivered to the customer

Maybe the supplier forgot toinstruct the producer;Maybe the producer did not produce the goods;Maybe the carrier could not pickup from the producer;…

Who is accountable for what? Who is to be sued in case of losses?


Use of Deontic Logic in system specs

Allows us to deal with norms and expectations:Obligations to perform specified behaviourPermissions to perform such behaviourProhibitions of certain behaviours

We shift to a style of specification where the focus is not only on the concrete steps and processes, but on

a set of obligations that must be discharged;who is responsible for discharging them;who is allowed to do that, and when;Delegation of obligations and permissions is possible

Liability can be traced in case of problems, and parties become accountable for their [in]actions


Background

Activity within the ODP family of standards

Work is centred within ISO as an extension to the ODP Enterprise Language and UML4ODP standards

Improve support for deontic concepts


Timeline

Based on ideas published in 2003 (Linington & Neal)Project to incorporate into the ODP standards first mooted in 2007Initial study phase to scope and set directionFull project approval 20111st full draft for revised Enterprise Language balloted June 2012

ISO Standards take upward compatibility very seriouslyChanges must be made in such a way that other standards in the family are not invalidatedRevisions of particular standards may motivate alignment changes in dependent or supporting standards


A.Vallecillo: "Accountable Objects: Modeling Liability in Open Distributed Systems" 8

ODP Framework

The Reference Model of ODP (ITU-T Rec X.901-904 | ISO/IEC 10746) defines a framework for system specification, covering all aspects of ODS:

“enterprise”, data, functionality, distribution, technologyIt comprises

A structure for system specifications in terms of a set of viewpointsA set of object-oriented foundation modeling concepts common to all viewpoint languagesA viewpoint language (concepts and rules) for expressing each viewpoint specificationA set of correspondences between the viewpointsA set of common functionsA set of transparenciesA set of conformance points

Vienna, 2013


ODP Viewpoints

Different abstractions of the same systemeach abstraction focuses on different concerns each abstraction is achieved using a set of viewpoint concepts and rules(the viewpoint language)

A viewpoint specification isthe specification of a system from a specific viewpointexpressed in terms of the viewpoint language to describe the concerns and decisions covered by the viewpoint specificationrelated to, and consistent with, other viewpoint specifications (correspondences)

Vienna, 2013


An ODP system specification

- object configuration- Interactions between objects at interfaces

Computational

Enterprise- business aspects- What for? Why? Who? When?

- information- changes to information- constraints

Information

- hardware and software components implementing the system

Technology

Engineering

- mechanisms and services for distribution trans- parencies and QoS constraints.

- and correspondences between specifications Vienna, 2013

The “Enterprise” Viewpoint

The enterprise viewpoint focuses on the specification of the business constraints and the environment within which an ODP system is to operateIt describes the business entities and the processes to be considered.It provides a place to express general organizational policies that constraint the other viewpoints and stakeholdersOne “enterprise”…

…may be a single organization…may be describing an ad hoc grouping…may be a loose social group…may be a legal jurisdiction…may be a federation



The enterprise language

Specifies the roles played by the system in its organizational environment

An object model of, for example, part of some social/commercial organization in terms of:

Communities (of enterprise objects) with objectivesEnterprise objectsBehaviour

Roles (fulfilled by enterprise objects in a community) Processes (leading to objectives)

PoliciesAccountability

The IT system is just another object

Vienna, 2013

Communities

Configuration of objects with a stated purposeObjects participate by filling typed rolesCommunity behaviour is expressed as recursive composition of interactions between rolesConstraints on role filling can be used to express e.g. dynamic separation of dutiesCommunity type seen as the community “contract”

Examples The Olive Oil communityA UniversityA Library


Roles

Roles provide an essential way of expressing the way in which fragments of specification are composed to form a whole

Particularly as an aid to the reuse of a fragment in a number of situations within the specificationUnderlying metaphor is the filling of roles defined in a script to describe a performance……or filling formal parameters with actual terms in a language – e.g. in a procedure

Active roles (actors), passive roles (artefacts)Examples

Customer, Supplier, Carrier, Goods,…Teacher, Student, Classroom, …Librarian, Library member, Book…


Interactions

• Interactions involve a number of participants

• Model as the filling of action-roles by objects

• Express action types using action roles as their formal parameters


How to deal with Obligations, Permissions and Prohibitions?

Dynamics of Obligations

• The main idea is that systems evolve by interactions resulting in the creation, transfer or destruction of obligations

• Reify obligations as deontic tokens, which are first-class objects held by actors in the system

• Tokens can be used in expressingObligations (Burdens)

Permissions (Permits)

Prohibitions (Embargos)



The Enterprise specification

The e-commerce system will be specified by one single community

Its goal is to “act as supply channel from producers customers”

Its objects model the community entities: people (“Joe Smith”, “Lucy Brown”), companies (“LaEspañola”), items (olive oil bottle#123), purchase order#999, etc.

Its basic roles are: Customer, who wants the oil and will pay for itSupplier, the Modern Oil CompanyProducer, one of a group of participating farmersCarrier, who take the oil from supplier to customer

Its processes include Purchase, Return defective lot, etc.

Vienna, 2013

Enterprise specification (ct’d)

Assignment policies (e.g., the requirements of a person or a company to become a customer)

Policies:Permissions: what can be done, e.g. the customer can buy from the supplierProhibition: what must not be done, e.g. individual customers must not buy directly from the producerObligations: what must be done, e.g. the supplier must deliver the goods to the customer; the customer must pay 30 days after delivery of goods.Authorizations: regular customers are entitled to have discounts and to pay up to 60 days after deliveryDelegations: suppliers can use external carrier companies to deliver the goods to the customers


The Basic “Purchase” Process

Community Roles in an individual purchase transaction:

Customer, who wants the oil and will pay for itSupplier, the Modern Oil CompanyProducer, one of a group of participating farmersCarrier, who take the oil from supplier to customer


Tokens Involved

At each stage in a transaction tokens may be:Needed from some roles as inputCreated by an interactionPassed to roles in the interactionDischarged or cancelledMaintained

These changes can capture the details we want to specify in a concise way

Authorization to proceedDelegations of responsibilityDischarge of obligationsRelease of duties


The “Order” Interaction

Permit supplied by customer, burdens created


order()

customer customersupplier supplier

pay ondelivery

supplyoil

Placeorder

The “InstructProducer” Interaction

Subcontracting moves tokens, creates others


instruct()

producersupplier

produce oil

supplier

supply oil

producer

pay producer

monitor delivery

produceoil goods

produceoil goods

supply oil

The “InstructSupplier” Interaction


[Note: payment extends behaviour given]

instruct()

carriersupplier carriersupplier

monitordelivery

deliver oil

pickup oil

Deliver oil

monitordelivery

collect oil

pay carrier

The “Report” Interaction

Finalizes both subcontracts; some permits remain


report()

carriersupplier

deliver oil

carriersupplier

charge customer

supplyoil

Deliver oil

Deliver oil

The “Charge” Interaction

[Note: The charge interaction is seen here as binary; there is probably a hidden involvement of a bank]


charge()

customercustomer suppliersupplier

pay ondelivery

charge customer

transactioncomplete!

Patterns of Token Use

Unique tokens for individual actions/artefacts vs. Universal tokens for types of actions/artefacts

Permit to deliver one box of olive oilPermit to carry goods (in general)

Implicit tokens vs. Explicit tokensPermits by default and explicit prohibitions vs.Explicit permits and prohibitions by defaultEconomy of the language/”By default” policy

Full delegation vs. No delegation vs. MonitoringWe can model different strategies depending on the system we want to represent/specifyDelegation may require permissions, too


Simple Tokens

Consider one active object and the tokens it carries:

object

burden

permit


More Complex Situations

There may be many tactics:


Community Burdens

• Need to have a compact way of showing how tokens pass to objects filling community roles

• Need to show recovery from exceptions

object fills role,inherits burden

community has burden

enterprise object

community assignsburden to role

community

object’sother burdens

role


Inheritance of Tokens

One of the open issues is whether it is more powerful to talk of assigning tokens to roles rather than objects

Token automatically reverts to community, associated with empty role, if role-filling object fails

But is this too abrupt?Is it too complex?


Notations and tools

How to express these concepts and mechanisms in the specification of systems?

The real issue is what the tools available in practice will support!

Different options still being studied to see what practitioners find acceptable


UML Mapping

ISO 19793 – UML4ODP provides a concrete representation for ODP models

Each viewpoint language has a profile defined in terms of a set of UML stereotypes

We extend this to add the new concepts, e.g.Deontic TokensActive ObjectsConditional Actions


Changing The Enterprise Language Metamodel

Placing the specification in context.


Core Community Definitions


Behavioural Definitions


Deontic Framework


Token Lifecycle

Most behaviour is enterprise-specificProvide minimal lifecycle behaviour as root


The Olive Oil Community


The “Purchase” Process


The “Order” interaction


The complete community


The “Order” interaction


The “InstructProducer” interaction


Issues of Style

Flexible and Expressive approachStill many open ways to model liability in UML4ODP

No approach fits all purposesDifferent ways to model obligations, depending on the particular systemDelegations and monitoring of responsibilities depends on the kinds of analysis to be conducted

Usability and Readability of diagrams and specifications essential for proper specification and maintainability

UML tool support for analysis and simulation still insufficient


A BPMN Mapping?

UML is not the only show in town

Interest in mapping the same conceptual structure onto other languages and notations

Primary candidate for a second mapping is BPMN

Progression depends on the level of support and contribution

Likely to need a new project in ISO


Rule-based DSLs

DSLs can provide more effective solutions

Such as eMotions…


Simulations

[Spanshot after 50 simulation steps]


The Importance of Tools

There is a symbiotic relationship between users, standardizers and tool vendors

Often the tool vendors lag behind current modelling ideas

But without tools, ideas cannot be used in practice

Validation of additional semantic constraints can be added via plug-ins, but this is a single tool solution

Tool support for Behavioural Specifications still in its infancy


Further Questions


What is an Obligation?

So far, we have assumed it is obvious what a deontic constraint, such as an obligation means

Need to establish a formal semantic basis

Other views, e.g. Computational, have used correspondences to a labelled transition system

This focuses on correctness of a move to the direct successor state


Providing a Broader View

Deontic concepts need to be defined in terms of properties of possible successor traces

Need to evaluate across properties of sequence of successor worlds (trace)

One approach is to base interpretation on correspondences to a set of Kripke frames

But can this be normative? Currently included as an informative discussion


Next Steps

ISO 15414 – The Enterprise LanguageCD Ballot complete, comments resolved at November meetingFCD in preparationNo obvious show-stoppers

19793 – UML4ODPStart November 2012, offset by 12 months from 15414Preliminary planning and directions document producedWD in preparation

Currently internal ISO draftsContact [email protected] or [email protected] for copies


mailto:[email protected]

mailto:[email protected]

References

P. F. Linington, H. Miyazaki and A. Vallecillo. “Obligations and Delegation in the ODP Enterprise Language.” In Proc. of VORTE 2012 (EDOC Workshops), IEEE Computer Society, Sept 2012, pp. 146-155. http://www.lcc.uma.es/~av/Publicaciones/12/edoc-tokens.pdf

P. F. Linington and S. Neal, “Using policies in the checking of business to business contracts.” In Proc. of the 4th IEEE Int. Work. on Policies for Distributed Systems and Networks (POLICY’03). Lake Como, Italy: IEEE Computer Society, Jun. 2003, pp. 207–218. http://www.cs.kent.ac.uk/pubs/2003/1636/content.pdf

P. F. Linington, Z. Milosevic, A. Tanaka and A. Vallecillo “Building Enterprise Systems with ODP — An Introduction to Open Distributed Processing.” Chapman & Hall/CRC Press, 2012. http://theodpbook.lcc.uma.es/


http://www.lcc.uma.es/~av/Publicaciones/12/edoc-tokens.pdf

http://www.cs.kent.ac.uk/pubs/2003/1636/content.pdf

http://www.cs.kent.ac.uk/pubs/2003/1636/content.pdf

http://theodpbook.lcc.uma.es/

http://theodpbook.lcc.uma.es/

Accountable objects: Modeling Liability in Open

Distributed Systems

Antonio VallecilloUniversidad de MálagaVienna, January 28, 2013

[Joint work with Peter F. Linington and Hiroshi Miyazaki at ISO/IEC]