Contract Driven Business Applications - PowerPoint PPT Presentation

1 / 37
About This Presentation
Title:

Contract Driven Business Applications

Description:

thus the state changing can be viewed as an effect of events occurring at points in time. ... That the communication and application framework works. ... – PowerPoint PPT presentation

Number of Views:23
Avg rating:3.0/5.0
Slides: 38
Provided by: dme76
Category:

less

Transcript and Presenter's Notes

Title: Contract Driven Business Applications


1
Contract DrivenBusiness Applications
  • Talk slides

2
Talk Outline
  • Introduction
  • Research problem Tenets EDEE / CamPACE
  • Architecture
  • RDF / Semantic Web Event Calculus FLBC
  • Projects and prototyping
  • Multithreaded Prolog servers and other forms of
    madness.
  • Fair and logical trading project
  • The UPenn Bloodbank project
  • Future research directions
  • Conclusion

3
Research Problem
  • Businesses interact under terms and conditions.
  • Set up in written contracts or agreed protocols.
  • Sometimes norms are established implicitly.
  • Computer systems in business are way too brittle.
  • Lack of understanding and ambiguity is an error
    condition,
  • Yet in real-world business it is commonplace.
  • Function of technology-driven optimisation (e.g.
    RDBMS).
  • Striving for a better human/computer separation.
  • Leave computers doing storage and querying.
  • Add more human flexibility in terms of semantics.
  • We are trying to find an always-on solution.

4
Two tenets
  • Business agents react to their environment.
  • We approximate such agents world view as being
    over a finite set of states of affairs.
  • The state of the world changes over time.
  • We approximate time as an integer measure,
  • thus the state changing can be viewed as an
    effect of events occurring at points in time.
  • Some events may refer to derivatives.

5
Fundamental data representation?
  • Given those tenets, how do we represent data?!
  • E.g. a relational schema for purchase orders is
    already way too specific.
  • (although useful for caching currently static
    data)
  • We want to be able to enumerate items (or
    concepts) and the various relationships between
    them.
  • Enter the Resource Description Framework (RDF).
  • (and exit performance)

6
Where do contracts fit in?
  • Brittle operating system software code is
    desirable.
  • (Assuming it is mostly correctly programmed.)
  • This is because such code repeats deterministic
    jobs, operating in a clean, digital world.
  • Successful real world interactions require
    flexibility.
  • Parties may appear to be violating your
    obligations, but who is to say your perspective
    is correct?
  • Need to support agents maintaining different
    world views.
  • Appropriate knowledge representation will allow
    us to handle evidence without fully understanding
    it.
  • All obligations are proposed on the basis of
    evidence.

7
Alans Occurrence Store
  • Alan Abrahams designed a knowledge representation
    framework with RDF-similar expressiveness.
  • Occurrence triples unify storage of
  • Business events / state
  • Queries related to outstanding obligations, etc.
  • Factories that generate new occurrences
  • Basis of the CamPACE implementation
  • Cambridge Policy Analysis and Checking
    Environment.
  • ASP.NET web application with Prolog conflict
    checker.
  • Tag natural language into occurrence forms
  • Runs safety and liveness checks.
  • Follows on from his EDEE implementation.

8
Deontic semantics
  • Alans Ph.D. thesis also examined a comprehensive
    set of deontic terms.
  • Types of obligation, prohibition, power,
    authority, permission, voiding, fulfilment, etc.
  • These terms form the building blocks of
    electronic contracts.
  • Conflicts are accepted to be commonplace, and not
    an exception.
  • For example, safety conflicts include being
    obliged but prohibited, or being liable but
    immune.
  • Liveness problems include being desired but not
    obliged, or being obliged but not able.

9
CamPACE environment
10
Define Clauses
Syntax Highlighting
Uninflected-Verb Lookup (Merriam-Webster Online)
Semantic DatabaseConsultation
Indicator Rules
Exceptions to Rules
Tool Tips
11
CDBA Architecture E4
  • Our CDBA architecture evolves Alans projects
    using
  • Event-based middleware
  • Event logging.
  • Event Calculus.
  • Event semantics.
  • (there are subtle differences in all senses of
    the word!)
  • In terms of knowledge representation, RDF
    replaces the triple-oriented occurrence store.
  • Shift in focus from deriving software from
    natural language documents, to just correlating
    semantics.

12
CDBA Architecture Behaviour
  • We have also increased the emphasis on analysing
    and effecting dynamic behaviour.
  • Log times are connected to all events.
  • By the publish/subscribe emulator at the moment.
  • The Event Calculus is employed to define reactive
    behaviour and monitoring.
  • Symbolic programming language code is used to
    exchange software functions.
  • In our case a security-filtered form of Prolog.
  • Content-based messaging is used to exchange
    messages between interested parties.

13
CDBA Architecture
External Events
FLBC domain-specific event encodings
Event transport (Secure pub/sub)
14
Two broad levels of CDBA operation
  • It is not clear from the preceding diagram that
    there are at least two broad levels of operation.
  • The confusion stems from us using Prolog for
    both!
  • The core level (0) is the event-based
    infrastructure.
  • Here inconsistency is an exception situation.
  • Event log records being added with times long
    past.
  • Malformed RDF graphs.
  • Above the core is the application infrastructure.
  • At this level inconsistency is likely to occur as
    it does in the real world.
  • The beliefs of the agent about such situations
    will be recorded like all other events are.

15
Architecture Event Store (1)
  • RDF is a highly referential structure.
  • How on earth to perform updates?
  • If possible, just dont.
  • Intuition Log everything. (slightly refined
    later)
  • Business decision-making needs history.
  • Obviously beneficial the constraint is one of
    granularity.
  • Domain-specific events should be as close as
    possible to human-level decision granularity.
  • Hence our focus on business environments.
  • Humans are the decision bottleneck in at least
    some areas.

16
Architecture Event Store (2)
  • Robust RDBMSes use journals (event logs?).
  • Why isnt it a first-class member of more
    systems?
  • Over time the event log can be migrated to
    cheaper, slower media.
  • Storage is cheap anyway
  • Also, parallelism is now commonplace.
  • C.f. Googles approach.
  • Even better our log is WORM.
  • Necessary redundancy
  • Agents store their view of events for subsequent
    compliance checking.
  • Multi-level fold away extraneous detail over
    time

17
Architecture Caches
  • We compile programs into faster forms of code.
  • However, non-JIT compilers discard information.
  • We see relational tables as representing
    compilation of data rather than software code.
  • This is what RDBMSes do with their journals.
  • The more journal data the better in terms of
    optimisation.
  • Beyond compiling the event log into relational
    tables, we also can aggregate event log data over
    time.
  • This will be necessary for DPA compliance in the
    UK.
  • To implement event log folding efficiently, extra
    time fields will be needed.
  • Queries over the old data should gracefully
    degrade to relationships over the aggregation
    checkpoints.

18
Architecture RDF (primer)
  • RDF has numerous representations. Basic idea
  • ltsubjectgt ltpredicategt ltobjectgt .
  • Effectively defines graphs with named edges.
  • Any part of this RDF statement can be URI.
  • Otherwise it is a literal value (possibly typed).
  • Can do reification statements about statements.
  • RDF is really a storage-level solution.
  • Missing useful notions of structured objects
  • RDF Schema (not XML Schema) adds classes, etc.
  • OWL describes structural relationships across SW.
  • E.g. two different RDF descriptions might be
    unifiable.
  • OWL glues the semantic web together (when
    possible).

19
Architecture RDF messages
  • We also use RDF as a messaging format.
  • Ideal for agent-centric systems, since the RDF
    atom namespace is based on agents DNS names.
  • We need support for transmitting message graphs
  • E.g. by reference (semantic web), or
  • by instance (the receiving agent will copy the
    graph).
  • More importantly, we must checkpoint RDF graphs.
  • In the semantic web, at any time further triples
    can be linked to a given source Id.
  • This is not acceptable if it implies modifying
    event history!

20
Architecture Event Calculus
  • Beautifully simple formalism that permits
    deductive, inductive and abductive reasoning.
  • Events occur at a point in time.
  • Fluents are states of affairs that hold over
    time.
  • Half open intervals.
  • Fluents can be multi-valued, and can represent
    derivatives.
  • Driven by a set of domain-specific rules which
    events initiate and terminate which fluents.
  • Frame problem is solved by circumscription.
  • If something isnt said to change, it doesnt
    change.
  • Countless extensions modal operators, continuous
    change, non-instantaneous events, etc.

21
Architecture Event Calculus (2)
  • We are using EC to program the run-time reactive
    behaviour of each agent.
  • For this use we not need a parallelisable process
    calculus.
  • At present we are aiming to allow agents to
    reason backwards in time from the present.
  • Reasoning forwards in time efficiently might
    require a more complex formalism.
  • This is interesting to us, since often businesses
    will want to make prospective decisions.
  • Full parallel process calculi might allow us to
    prove properties for the overall behaviour of our
    system
  • Not likely to be useful above the core
    infrastructure.

22
Architecture FLBC
  • Formal Language for Business Communication.
  • Provides for compositionally encoding messages.
  • Much EDI is not compositional at all
    description of Bob and Carol would require
    creating a new ID for the pair.
  • His theory of disquotation encodes easily into
    RDF.
  • A request should prototype the expected
    fulfilment events.
  • Data not structurally equivalent may be decided
    to count as being so from the agents
    perspective.
  • Sentence meaning versus Speech meaning
  • Logging agents speech acts can usefully hint at
    their interpretations (e.g. they do not believe
    an assurance).

23
Architecture TEQL
  • Mark Spiteris Ph.D. thesis An Architecture for
    the Notification, Storage and Retrieval of
    Events.
  • He introduces the TEQL query langauage
  • (although didnt provide the formal grammar!)
  • TEQL covers a large set of desirable time query
    constructs that would be fiddly in, say, SQL.
  • Defines instantaneous events, and time intervals
  • A good fit with the Event Calculus
  • I have implemented a very small subset of the
    language for proof-of-concept decision support.

24
Projects and ongoing prototyping
  • FLBC based projects.
  • Fair and logical trade.
  • Salutory agents.
  • SWIFT simulation.
  • Other regulatory notions.
  • US taxation conflict resolution.
  • FDA blood-bank example.

25
Initial FLT prototyping
  • Aiming to assess the viability of Steves FLBC
    (Formal Language for Business Communication).
  • Shift from EDI message focus, to defining
    compositional terms within any given
    communication.
  • Semantics can be introduced gradually.
  • Uses speech acts as the main representation of
    evidence in our interactions.
  • Parties do not need to agree on the truth
  • X states she believes Y has satisfied requirement
    Z.
  • Record that the speech act occurred (via the TTP)
    regardless of its actual validity.

26
Initial FLT prototyping (2)
  • Note that there is embedded propositional content
    in the prior statement.
  • Steve Kimbroughs Disquotation theory provides
    the tools to package and unpackage such
    constructs.
  • Explored representation at a workshop last year.
  • Will return to it with actual agent behaviour.
  • Aim to decrease the first trade problem in SME
    electronic commerce.
  • Computer supported semantics will be limited
  • E.g. flag new promises related to completed past
    events.
  • Aim to provide human-level business decision
    support.

27
Agent-based simulation
  • Early prototype implementation of our
    architecture.
  • Written in multi-threaded Prolog (of course)
  • Uses RDF-equivalent Prolog terms for data
    representation
  • Soon to migrate to the SWI Prolog Semantic Web
    library.
  • Currently uses TCP/IP (!) to send messages to a
    simple publish subscribe system emulator.
  • Subscription coverage based on Prolog unification
  • RDF allows us to easily handle structured data.
  • We want the same features managing code.
  • The Prolog code/data integration is superbly
    convenient.
  • Although had some interesting security
    implications!
  • Naturally we could use other languages, but the
    implementation would be far messier.

28
Salutory agents
  • Insults / greetings exchanged between two agents.
  • Five agents in total Bob, Bobs boss, Carol,
    Carols boss, and the publish/subscribe manager.
  • These agents are completely separate Prolog
    processes.
  • The four players sleep randomly after each day.
  • Although the actual code is of course run-time.
  • Bob and Carol both have a queue of instructions
    from their respective bosses as well as event
    logging.
  • This example serves to demonstrate
  • Agent behaviour influenced by their own event
    log.
  • That the communication and application framework
    works.
  • That Netscape 2s HTTP push extensions live on in
    Firefox.

29
SWIFT simulation
  • Steve has had experience with SWIFT.
  • They own a messaging standard to deal with
    international monetary transfers.
  • It is replete with obscure codes and keywords.
  • Our aim is to show that the FLBC can contain
    simple SWIFT transactions and add useful
    flexibility.
  • Uses complex RDF structures representing FLBC
    messages with embedded propositional content.
  • The primary goal of our prototype is to
    demonstrate programmable counts-as
    functionality.
  • Allow agreeing a settlement on rounding error
    within a transaction to be reconciled dynamically.

30
Event Calculus implementation
  • Started with the Simplified Event Calculus.
  • Negation as failure.
  • Soon discovered that extensions were necessary.
  • Implemented deadlines a form of continuous
    change.
  • Deadline-surpassing fluents causing events
    required rewriting of the SEC predicates.
  • That rewrite happened to suit indexing far
    better!
  • Get for free a hash lookup on event types.
  • Queries over time ranges now use AVL trees.
  • Balanced binary trees for O(logn) operations.
  • Prolog might be O(n) slow, but Ive not had to
    care yet

31
Ontologies pending
  • To date my RDF terms have been somewhat ad hoc.
  • I want to specify numerous RDF ontologies
  • Event Calculus
  • There is an XML encoding (so what? indeed)
  • FLBC
  • Define a sufficiently comprehensive set of
    compositional, encapsulating business messages to
    fit common daily use.
  • Deontic terms
  • Working with Alan to determine a spanning set of
    terms for obligations, prohibitions, fulfilment,
    dispensation, etc.
  • Publishing our ontologies allows sharing.
  • E.g. may reference parts of the Rei policy
    ontology.

32
Documenting ontologies
  • RDF terms will need to be described using natural
    language text.
  • Leaves humans to understand the specifics.
  • Unlike current EDI, can support incremental
    augmentation.
  • I have developed a proof-of-concept approach to
    tagging natural language text using DHTML and
    SVG.
  • This will allow convenient browsing of the
    relationship between our ECProlog policy data
    and natural language descriptions of them.
  • Again Firefox 1.5 comes out a winner in terms of
    DHTMLCSS and its SVG implementation.

33
Bloodbank Project (I)
  • UPenn Bloodbank project examines a section of the
    FDA CFR relating to the management of blood
    donations.
  • Insup Lee and friends in UPenn CS tried to use
    NLP techniques to convert the policy text into
    EFSMs.
  • I am sceptical that EFSMs are sufficiently
    expressive.
  • Prescriptive rather than restrictive suitable
    for creating good traces more than showing any
    given trace is not bad.
  • I propose to use an Event Calculus formulation
    instead, using terms from our deontic ontology.
  • An example of their EFSM graphs follows

34
Bloodbank Project (II)
  • The workflow from the note to the FDA CFR

35
Future challenges
  • Moving out of RAM
  • Referential redundancy caused by graph-based
    structures being inserted into a relational
    database table.
  • Event log indexing
  • Access control
  • Distributed time and clocks
  • Trust management
  • Ontology publication.
  • Composite events
  • Distributed simulation
  • Parties agree to simulate situations, whilst
    preserving true anonymity of secret business
    information.

36
Conclusion
  • Provided background of how we got to this point.
  • Integrating the four Es looks promising.
  • Event-based middleware
  • Event logging.
  • Event Calculus.
  • Event semantics.
  • Initial prototyping is getting somewhere.
  • Many really interesting research challenges
    remain.
  • Much resonance with other Opera Group research
  • All collaboration welcome!
  • Any questions?

37
Recent voyage
  • Taken me through
  • Multithreaded Prolog
  • NetLogo
  • Slidey
  • SlideMaker
  • Xgl
  • Multidimensional indexing
  • Wink
  • Dataflow PD / jMax
  • Functional programming
  • Subtext (crazy)
  • Also
  • Philadelphia
  • New York City
  • Princeton
Write a Comment
User Comments (0)
About PowerShow.com