550 likes | 727 Views
Erasmus University P.O. Box 1738 3000 DR Rotterdam, The Netherlands tel. 31 (10) 408 26 01 fax 31 (10) 453 13 21 www.euridis.fbk.eur.nl/Euridis/. Ronald M. Lee email R.Lee@fac.fbk.eur.nl EURIDIS Erasmus University Research Institute for Decision and Information Systems.
E N D
Erasmus University P.O. Box 1738 3000 DR Rotterdam, The Netherlands tel. 31 (10) 408 26 01 fax 31 (10) 453 13 21 www.euridis.fbk.eur.nl/Euridis/ Ronald M. Lee email R.Lee@fac.fbk.eur.nl EURIDIS Erasmus University Research Institute for Decision and Information Systems Technology forOpen International TradeElectronic Trade ScenariosPART II
Scenario Representation Automated Auditing: Audit Daemons Automated Generation: Scenario Grammars Distributed Regulations: Messenger Model Outline
Scenario Representation Documentary Petri Nets
different node types = agency of choice (endogenous, exogenous) Graphical Representations: Abstract: State Transition Diagrams Applied: DecisionTrees nodes = states arcs = transitions
arcs = activities, tasks (sub-states) nodes = transitions total state of system = set of active tasks Graphical Representations: Abstract: Marked Graphs Applied: PERT Diagrams install bath do plumbing do electrical finish walls
Combines: choice, contingency (STN) concurrency (marked graph) Graphical Representations: Abstract: Petri Nets circle nodes = places (sub-states) bar nodes = transitions tokens = mark active places
circles = control nodes boxes = document nodes cube = physical goods bar = action triangle = decision node Graphical Representations: from Buyer: purchase_order Seller: decide_accept Applied: Documentary Petri Nets {accept_order} {reject_order} null Seller: deliver_goods Seller: send_invoice to Buyer: [goods] to Buyer: [invoice]
Auditing Scenarios Audit Daemons
Doing tasks -- get the job done efficiently Control tasks -- ensure agents have sufficient authority for task agents do not exceed/misuse their authority Auditing = verify adequacy of controls under control over control Designing Business Procedures
identify where control tasks are needed proper authority for control task input requirements: documentary evidence of doing task other info available to doing task output: evidence that control was performed Control Task Requirements Detective: examine evidence of doing tasks after their effect Preventive: verification of doing task prior to its effect
Formal representation of procedures enables computer analysis ... Audit daemons = pattern-matching rules for documentary petri nets (DPN’s Basic syntax: if <conditions> warning <text> because <text>. Audit Daemons
Example ... (from Bons, 1997, p. 170-188) • WARNING: • Someone should testify the • completion of the primary activity • send_doc(the_sea_carrier, • transport_instruction( • the_consignee, Goods)) • of the_shipper otherwise • the_shipper, is not able • to prove that it executed • its obligation.
Extract from audits rule base ... • /*-------------------------------------------------------------------------*/ • /* audit daemon rule */ • /*-------------------------------------------------------------------------*/ • 'Audit Rule Ia' :: • if core_activity(Role1, PA, A1) and • not testify(Role1, Role2, Role1, PA, IP, A2) • warning [ • ‘Someone should testify the completion of the primary activity’, PA, • ‘of’, Role1, ‘otherwise’, Role1, • ‘is not able to prove that it executed its obligation.’ • ]. • /*-------------------------------------------------------------------------*/ • /* testify */ • /*-------------------------------------------------------------------------*/ • testify(Role1, Role3, Role2, PA, IP, A1) if • testify_table(Role2, PA, IP, Role3) and • not equal(Role2, Role3) and • not socially_close(Role2, Role3) and • witness(Role3, Role2, PA, A2) and • issue_ip(Role3, IP, A4) and • match(follow(Role3, A3, Role3, A4)) and • match(dpn_receive_ip(Role1, RoleX, IP, A1)).
Uses: * somewhat useful for auditing manual procedures * main purpose: design and development of electronic procedures * audit rules/patterns as a means of distributing control policy in procedure development Concluding Remarks For more information see: Bons, Roger W.H. Designing Trustworthy Trade Procedures for Open Electronic Commerce PhD Dissertation, Euridis and Faculty of Business, Erasmus University, September, 1997.
Automated Generation Of Control Procedures Scenario Grammars
Re-usability of control knowledge Trade scenario consists of: Doing tasks -- depend on goals of contracting parties Control tasks -- depend on: * level of trust among parties * requirements of legal system * available communication technologies Would like to automate expertise of designing control tasks: * input: set of doing tasks * output: electronic trade scenario (DPN’s) System asks for additional parameters, as needed. Goal: re-usability of control knowledge * encapsulate control aspects in re-usable ‘chunks’
Consist of: * chain pattern -- recognize patterns of doing tasks * scenario grammar rules -- (linear) * scenario grammar templates -- (graphical) -- role grammar templates -- linked, multi-role templates Scenario Grammars
chain_pattern prepaid_sale :: if link(money, buyer(B), seller(S)), link(goods, seller(S), buyer(B)) then [S,B]: prepaid_sale. chain_pattern postpaid_sale :: if link(goods, seller(S), buyer(B)), link(money, buyer(B), seller(S)) then [S,B]: postpaid_sale. Example Chain Patterns
scenario_grammar [Buyer, Seller]: prepaid_sale ==> [Buyer, Seller]: payment(money(@amount, @currency)) ++ [Seller, Buyer]: send_docs([pay_receipt(@amount, @currency)]) ++ [Seller, Buyer]: delivery(goods(@kind, @id) ++ [Buyer, Seller]: send_docs([goods_receipt(@kind, @id)]); end. scenario_grammar [Buyer, Seller]: postpaid_sale ==> [Seller, Buyer]: delivery(goods(@kind, @id) ++ [Buyer, Seller]: send_docs([goods_receipt(@kind, @id)]) ++ [Buyer, Seller]: payment(money(@amount, @currency)) ++ [Seller, Buyer]: send_docs([pay_receipt(@amount, @currency)]); end. Notes: Variables (beginning with Capital letter) are resolved at scenario generation; Parameters (@<parm>) are resolved at scenario execution time. Example Scenario Rules
[X,Y]: payment(Money)==> Money X: send_payment Y: recv_payment [X, Y]: delivery(Goods) ==> Goods X: deliver_goods Y: recv_goods [X, Y]: send_doclist(Docs) ==> Docs X: send_docs Y: recv_docs Example Templates (as Linked DPN’s)
seller_jones buyer_smith goods(horse, 'Molly') money(200, euro) Example 1: Chain Diagram (PostPay)
$ goods(horse, 'Molly') seller_jones: deliver_goods buyer_smith: recv_goods [goods_receipt(horse, 'Molly')] seller_jones: recv_docs buyer_smith: send_docs money(200, euro) seller_jones: recv_payment buyer_smith: send_payment [pay_receipt(200, euro)] seller_jones: send_docs buyer_smith: recv_docs PostPay Example 1: Result Scenario (as Linked DPN)
seller_philips bank_abn buyer_fiat money(5000, euro) goods(headlites, 10000) money(5000, euro) Example 2: Chain Diagram (Escrow)
$ $ money(5000, euro) [escrow_advice(5000, euro)] bank_abn: recv_payment buyer_fiat: send_payment seller_philips: recv_docs bank_abn: send_docs goods(headlite, 10000) buyer_fiat: recv_goods seller_philips: deliver_goods [escrow_release] bank_abn: recv_docs buyer_fiat: send_docs seller_philips: recv_payment bank_abn: send_payment Escrow Example 2: Result Scenario (as Linked DPN)
chain_pattern escrow_sale :: if link(money, buyer(B), bank(K)), link(goods, seller(S), buyer(B)) link(money, bank(K), seller(S)), then [S,K,B]: escrow_sale(S,K,B). scenario_grammar [Buyer, Bank, Seller]: escrow_sale(S,K,B) ==> [Buyer, Bank]: payment(money(@amount, @currency)) ++ [Bank, Seller]: send_docs([escrow_advice(@amount, @currency)]) ++ [Seller, Buyer]: delivery(goods(@kind, @id) ++ [Buyer, Bank]: send_docs([escrow_release(@kind, @id)]) ++ [Bank, Buyer]: payment(money(@amount, @currency)); end. Example 2. RuleBase (Excerpt)
Consignee Carrier Shipper Goods Goods Example 3: Steveadore as TTP
Chain Pattern: chain_pattern steveadore_as_ttp :: if link(goods, shipper(S), carrier(T)), link(goods, carrier(T), consignee(C)) then [Shipper, Steveadore1, Carrier, Steveadore2, Consignee]: steveadore_as_ttp(Goods, bill_lading, title_doc). Scenario Grammar: [Shipper, Steveadore1, Carrier, Steveadore2, Consignee]: steveadore_as_ttp(Goods, bill_lading, title_doc) ==> [Shipper, Steveadore1, Carrier]: dispatch_and_receipt(Goods, [bill_lading]) ++ [Carrier]: transport_goods(Goods) ++ [Carrier, Steveadore2, Consignee]: dispatch_and_receipt(Goods, [title_doc]) ; end. Note: this scenario grammar demonstrates re-usability of templates Example 3:RuleBase
[Sender,Receiver,TTP]: dispatch_and_receipt(Goods, DocList) ==> Sender: send_goods Receiver: send_docs TTP: transfer Receiver: recv_goods Sender: recv_docs Example 3: Template
Goods [bill_lading] [arrival_notice] Consignee: recv_docs Shipper: send_goods Carrier: send_docs Carrier: send_docs Steveadore1: transfer [title_doc] Goods Consignee: send_docs Carrier: recv_goods Shipper: recv_docs Carrier: send_goods [bill_lading] Goods Steveadore2: transfer Carrier: transport_goods Carrier: recv_goods Carrier: recv_docs Goods [bill_lading] steveadore_as_ttp Example 3: Result Scenario (as Linked DPN)
Consignee Carrier IssueBank Shipper CorresBank Goods Money Money Money Goods Example 4: Documentary Credit
Example 4. Scenario Grammar • [ Shipper, Consignee, IssueBank, CorresBank, Carrier ] : documentary_credit() ==> • ShipDocs = [ bill_lading, commerc_invoice, gsp_a] • A :: • { Consignee, Shipper]: send_docs([purchase_order]) << • [Shipper, Consignee]: send_docs([p_o_acknowledgement]) << • [Consignee, IssueBank]: send_docs([lc_request]) << • [IssueBank, Consignee, CorresBank]: send_docs([lc]) • } • /* concurrency */ • B :: • { CorresBank, Shipper]: send_docs([lc]) << • [ Shipper, Carrier]: dispatch_goods([Goods]) << • [ Carrier, Shipper]: send_docs ([bill_lading]) << • [Shipper, CorresBank ]: send_docs(ShipDocs) << • [CorresBank, IssueBank, Shipper]: eval_lc(ShipDocs) • } • C :: • { Carrier, Consignee ]: send_docs ([arrival_notice]) << • [Consignee, IssueBank]: send_docs([money]) << • [IssueBank, Consignee]: send_docs(ShipDocs) << • [Carrier, Consignee ]: phys_transfer ([Goods]) • } • A << B, A << C.
[CorresBank, IssueBank, Shipper]: eval_lc(ShipDocs) ==> • [CorresBank, IssueBank, Shipper]: corres_bank_eval_lc(ShipDocs); • [IssueBank, CorresBank]: issue_bank_eval_lc(ShipDocs); • [Shipper, CorresBank]: shipper_receive_eval_lc(ShipDocs); • end. Example 4: Rulebase (continued)
[X, Y, Z]: send_doclist_2party(DocList) ==> DocList Y: recv_docs X: send_docs DocList Z: recv_docs Example 4: Template
[IssueBank, CorresBank]: issue_bank_eval_lc(ShipDocs) ==> From CorresBank: ShipDocs IssueBank: recv_docs =reject =accept IssueBank: send_docs IssueBank: send_payment to CorresBank: money(Amt, Curr) to CorresBank: [rejection_notify | ShipDocs] Example 4: RoleTemplate, IssueBank
[Shipper, CorresBank]: shipper_receive_eval_lc(ShipDocs) ==> from CorresBank: [rejection_notify | ShipDocs] from CorresBank: money(Amt, Curr) Shipper: recv Shipper: recv =end =end Example 4: Role Template, Shipper
[IssueBank, CorresBank]: issue_bank_eval_lc(ShipDocs, Money) ==> =accept =reject CorresBank: send_docs CorresBank: send_docs to Shipper: [rejection_notify | ShipDocs] to IssueBank: ShipDocs CorresBank: recv_docs CorresBank: recv_payment from IssueBank: [rejection_notify | ShipDocs] =end to Shipper: [rejection_notify | ShipDocs] CorresBank: send_payment to Shipper: Money =end Example 4:Role Template, CorresBank
Messenger Model NavigatingDistributedRegulations
Transactions constrained by regulations by foreign governmental agencies * e.g. import/export duties * e.g. trade boycotts, embargos * e.g. dangerous goods regulations * Subject to change by agency * Must be checked before doing the transaction * Note: centralized copies may be out of date. approach: Messenger Model ... automated agents heuristic search regimes (formalized regulations) Challenge
Regime = way of doing business (rules, procedures) Inbox = performative communications Database = performative record Back Office Front Office Information System Queries Regime Illocutions Out Illocutions In Database Inbox Anatomy of a digital agency (or company):
messenger can search the environment -- the marketplace (shopping messengers) -- bureaucratic requirements messenger makes deliveries -- of messages -- of other information objects e.g. audio, video recordings; e.g. books, articles e.g. software -- of promisory objects e.g. titles e.g. licenses messenger can collect (same things) messenger has limited signature authority (performative function) What can a messenger do?
Search of a messenger is based on referrals These are addresses of further regimes to search Referrals obtained by ... suggestions of a regime e.g. bureaucracy e.g. vendor collected sources e.g. shopping mall e.g. yellow pages Referral of messengers Note: referrals implemented on Web as URL's
A. Navigation and discovery among requirements the client does not know what is required, and has some difficulty in finding out; in nasty cases, the standard solution is somehow frustrated; an alternative must be found. Sometimes, this is discovering flexibility within the requirements (e.g. fax, official copy); other times, it might be navigating around the bureaucracy (e.g. via alternate route). B. Transaction execution once a solution path is found, one actually performs the transaction. Two main aspects of the problem
Query messenger: manual queries -- user interacts with regime automated queries -- messenger pursues goal Transaction messengers -- execute the transaction Modes of operation Front Office Query Messenger Regime Transaction Messenger Inbox
Example Scenario: SOVAM Teleport * first commerical data communications company in Russia, starting in 1986 * began as a joint venture with American company, San Francisco Teleport * now, clients include SWIFT, major banks, international news agencies, etc. * CEO: Vladimir Teremetsky 1992: * decided to expand their satellite communications was necessary * negotiated a favorable deal with NORCO, a company in Anchorage, Alaska * item: 6 meter satellite dish * payment as a documentary credit * transport: by ship from Anchorage to Vladivostok by rail Vladivostok to Moscow Vladimir recounts the experience as a "labyrinth of bureaucracy". In addition to the usual trade documents, additional requirements were imposed from both the export (US) and import (RU) side. The US has long maintained a prohibition against export of technology to the USSR that has potential military importance. Even though the USSR had officially ended, the policy was still partially in force.
Norco to US-Customs: request proc (export) NORCO US Customs Office Request for procedure: export military goods
Norco to DOD: request proc (miliary goods) DOD Office of Export Controls NORCO Norco to US-Customs: request proc (export) US Customs Office Request for procedure: export military goods
Norco to DOD Telecomm: request proc (inspection) DOD Military Telecomm NORCO Norco to DOD: request proc (miliary goods) DOD Office of Export Controls Norco to US-Customs: request proc (export) US Customs Office Request for procedure: export military goods
DOD Telecom Office Nordco Request Non-military Certification NorCo: request cert DOD Telecom: certify specs Non-military Certification DOD Export Controls NorCo: dispatch goods NorCo to DOD Export Controls: Physical Inspection Goods Inspection Report Generated Procedure NORCO US Customs Customs Release
SOVAM Sovam to Rus Trade Office: request proc (import) Russia Trade Office Request for procedure: import of telecomm