1. e-Science Meeting April 2005 1 Trusted Coordination in Dynamic Virtual Organisations Santosh Shrivastava School of Computing Science Newcastle University, UK santosh.shrivastava@ncl.ac.uk

2. e-Science Meeting April 2005 2 Trust in virtual organisation (VO) Organisations want to create composite services using services of other organisations –This leads to resource sharing across organisational boundaries –Such sharing needs to be encoded as business relationships (“virtual organisations (VOs)” ) –You need to be able to set up, manage and terminate VOs –A VO however, blurs the distinction between 'outsiders' and 'insiders' –A central problem in VO management is therefore how organisations can regulate access to their resources by other organisations –So you need Middleware for regulating interactions »business process relationships underpinned by guarded trust management procedures

3. e-Science Meeting April 2005 3 What are the trust management procedures? Our approach: –Terms and conditions monitoring and enforcement »A partner within a VO providing a service to other partners will need several assurances, such as: service requester has been authenticated service requester has the right to request the operation evidence of interaction is being maintained (non-repudiation) --- –Quality of service monitoring »providers and consumers will also have ‘service level agreements (SLAs)’ stating quality of service, such as availability, response time EXAMPLE: in a B2B Auction, the auctioneer might need to guarantee that ‘even during peak periods the invocation of the place_bid operation is successfully completed within two seconds when there are less than 100 bidders logged in’

4. e-Science Meeting April 2005 4 Our Approach: Terms and conditions monitoring and enforcement: –Performed by a mediation service (a third party service) QoS monitoring service –a third party service Demonstrate the practicality of the approach via on- going projects –the GOLD e-science project –TAPAS, ADAPT EU projects

5. e-Science Meeting April 2005 5 Terms and conditions monitoring and enforcement A conventional business partnership is typically governed by rules - terms and conditions - laid down in a contract –actions the business partners are permitted, obliged and prohibited to execute –when and in what order the actions are to be executed –Example (buyer-seller business partnership) »the contract will stipulate within how many days of receiving a purchase order the goods have to be delivered… In a VO, we want: –electronic representations of terms and conditions contracts that can be used to mediate the rights and obligations that each interacting entity promises to honour –violations of agreed interactions are detected and notified to all interested parties –a non-repudiable audit trail of all interactions

6. e-Science Meeting April 2005 6 Terms and conditions monitoring and enforcement EXAMPLE hypothetical Contract: 1Offer to buy 1.1 The buyer may use his discretion to send a purchase order to the seller. 1.2 The seller is obliged to confirm acceptance or rejection of the purchase order within 24 hrs of receiving the purchase order. 2Payment 2.1 The seller is obliged to send an invoice to the buyer within 7 days of accepting the purchase order. 3Invalid messages 3.1 The buyer and the seller are forbidden to send invalid messages. 4Sanction 4.1 Failures to honour obligations and prohibitions will result in fines equal to 20% of the cost of the item. The offended party shall be granted permission to issue an invoice notification to the offending party. 4.2 Failure to respond to a fine shall be sorted out outside this contract.

7. e-Science Meeting April 2005 7 Representing Terms and conditions We need to derive/formulate ‘business conversations’ from terms and conditions by careful study of rights, obligations and prohibitions in contract clauses Conversation: a small business activity executed between two or more business partners to perform a well defined task –issue a purchase order –refund money –--- Terms and conditions contract is composed of conversations

8. e-Science Meeting April 2005 8 m1m1 m2m2 m3m3 mFmF BS conversation 1 conversation 2 conversation N m1m1 m2m2 mFmF BS m1m1 m2m2 m3m3 mFmF BS … … m3m3 … m1m1 m2m2 mFmF SB m3m3 … notification of failure conversation titi … legend: m- message B,S- two remote business partners execute next conversation

9. e-Science Meeting April 2005 9 PermissionsSubjectBeneficiarySanction P1.1 Send purchase order.buyersellernone P4.1 B Issue invoice to fine.buyersellernone P4.1 S Issue invoice to fine.sellerbuyernone Obligations O1.2 Send confirmation within 24 hrs.sellerbuyerP4.1 B O2.1 Send invoice within 7 days.sellerbuyerP4.1 B ….. Permissions, obligations……

10. e-Science Meeting April 2005 10 Representing Terms and conditions Conversations need to include implementation specific technical details such as acknowledgements and synchronization messages that form an important part of any implementation. –Contract clauses can be modified to include such messages –Conversations can be represented as finite state machines –Conversations, and their compositions can be model checked Example: Rosettanet consortium has defined a number of Partner Interface Processes (PIP) for common business activities

11. e-Science Meeting April 2005 11 Purchase Order partner interface processes, PIP 3A4:

12. e-Science Meeting April 2005 12 Rosettanet specific contract: 1Offer to buy 1.1 The buyer may use his discretion to send a purchase order to the seller. 1.2. The seller is obliged to acknowledge the purchase order within 2 hrs of receiving the purchase order 1.3 The seller is obliged to confirm acceptance or rejection of the purchase order within 24 hrs of receiving the purchase order. 1.4 The buyer is obliged to acknowledge the purchase order confirmation action within 2 hrs of receiving the message. 2Payment 2.1 The seller is obliged to send an invoice to the buyer within 7 days of accepting the purchase order. 3Invalid messages 3.1 The buyer and the seller are forbidden to send invalid messages. 4Sanction

13. e-Science Meeting April 2005 13 Mediation service The service intercepts all the contractual operations that the parties try to perform. Intercepted operations are accepted or rejected in accordance with the contract clauses and role players’ authentication. Interactions are non-repudiable Deployment can be either centralized (fig. (a), where for illustration purposes we assume an interaction between buyer and seller), or distributed (fig. (b))

14. e-Science Meeting April 2005 14 Mediation service

15. e-Science Meeting April 2005 15 Mediation service Centralised deployment –A given conversation is represented by a single state machine –an incoming message is checked for role player, associated permission and obligation, –Correct: the message is forwarded to its final destination whereas –Incorrect: the message is dropped Distributed deployment –the mediation functionality is split, with each side implementing it’s side of the conversation state machine. –distributed deployments face the difficult challenge of keeping contract state information synchronised at all the mediators. –For example, a valid message forwarded by the buyer’s side could be dropped at the seller’s end because intervening communication delays render the message untimely (and therefore invalid) at the seller side. –State synchronisation is necessary to ensure that both the parties either agree to treat the message as valid or invalid.

16. e-Science Meeting April 2005 16 Quality of Service Monitoring –Contracts include service level agreements (SLAs) describing quality of service (service availability, performance guarantees, etc) –Interacting organisations cannot simply rely on the trust they have in one another and assume that QoS levels are being honoured. –To be of practical use, a service provider must be able to demonstrate that the offered service meets the QoS levels promised to service users. –So you need (possibly third party) QoS monitoring and violation detection services

17. e-Science Meeting April 2005 17 QoS Monitoring and Violation Detection QoS Monitoring Architecture Assumption: service consumer i doesn’t want to be disturbed with metric collection responsibilities.

18. e-Science Meeting April 2005 18 Status: Mediation service: major parts have been implemented QoS monitoring: major parts have been implemented