Integrating and Orchestrating Services upon a MAS Coordination Infrastructure Enrico Denti, Alessandro Ricci, Rossella Rubino DEIS, Università degli Studi di Bologna (Italy) Sede di Cesena / Bologna

Context & Goals Context Goals Engineering Systems a MAS Coordination Infrastructure (TuCSoN) Smart Environments WfMS & CSCW Goals Reuse/Integration of (Legacy) Services Email, FTP, HTTP, Web Services Infrastructure support for Service Coordination Coordination Services Organisation Services Context - Engineering CSCW and WfMS upon MAS Coordination Infrastructure - Reuse/Integration of Legacy Services (email, FTP, etc..) - Objective 2 Basic Questions: 1) Come usare un servizio se sono un agente TuCSoN? More Generally: Come inquadrare, modellare e utilizzare un servizio su una MAS Coordination/Organisation Infrastructure? Come sfruttare il supporto infrastrutturale di organizzazione / coordinazione a tal riguardo? 2) Come posso sfruttare l'infrastruttura di coordinazione per affrontare aspetti di composizione e coordinazione dei servizi?

Service Oriented Architecture Issues Service Oriented Issues Architecture Registration, Discovery, Access (ex: Web Services, OSGi, Jini...) Interoperability Ontologies, Protocols (ex: Semantic Web Effort...) Composition and Coordination Choreography & Orchestration (ex: BPEL4WS, WSCI, BPML...) Our Focus Enabling Access to Standard/Legacy Services for TuCSoN heterogeneous Agents heterogeneous computational models & languages Exploiting coordination and organisation infrastructure facilities to aggregate and orchestrate services Quali sono le main issues a cui ci si trova di fronte quando si parla di integrazione di servizi - architettura in generale - interoperabilità - composizione e coordinazione NOI ci siamo focalizzati sul 3 punto

Engineering Services IMPACT of Infrastructure model and abstractions Organisation Model Structures and Rules Interaction/Coordination Model Direct vs. Mediated Specifying/Enacting/Ruling social activities Objective vs. Subjective Approaches And the consequent Security Model ... Il modello e le astrazioni fornite/supportate dall’infrastruttura condizionano pesantemente l’ingegneria dei servizi In particolare il modello organizzazionale supportato dall’infrastruttura, quello di interazione, di coordinazione, etc...

Approaches: Direct (P2P) Models Marginal Infrastructure Support

Approaches: Agent-Mediated Model Middle-Agents as Mediator

Approaches: Tuple-Space-like Model Mediate Interaction through Shared Information Space Infrastructure Support Ex: PageSpace

Our approach: Coordination Artifacts Runtime Customisable Coordination Services Encapsulating Coordination Policy & Control Programmed for supporting/automating specific coordination tasks Infrastructure Abstractions Predictable, Inspectable, Malleable, Linkable Role in SOA Interfaces for Users Ontology Mediators Governing Users/Providers concurrency/multiplicity

TuCSoN Infrastructure for Coordination Artifacts Tuple Centres as Coordination Artifacts Programmable Logic Tuple Spaces Coordination behaviour programmed in ReSpecT Agent Coordination Contexts to access Tuple Centres Runtime Organisation Abstraction Negotiated by agents to enter the Organisation Models agent’s active role(s) inside the Organisation Runtime Interface to access Organisation Resources Role-Based Access Control

Systems on TuCSoN

ACC Negotiation & Entrance

A Simple Service Model Mapping Service Ontology as Logic Tuples User Profile Service Request Service Result Coordination Artifact Usage Protocol Getting Request ID Inserting Request Info Reading Request Result

An example: Email User Profile Mail Description Service Operations user_profile(’mail/pop’,Name,info(host(H),user(U),pwd(P)),...) user_profile(’mail/smtp’,Name,info(host(H),user(U),pwd(P)),... ) Mail Description mail_header(ID, MsgID, sender(S), recipient(R), subject(X),...) mail_body(ID, MsgID, ‘content-type’(MIMEType),content(C)) Service Operations service_request(mail,ProfileName,ID,check_mail(TargetTC)) service_request(mail,ProfileName,ID,send_mail(TargetTC))

Sending an email... reaction(in(sevice_request_id(ID)),( ... )).

Sending an email...

Sending an email...

Sending an email...

Sending an email...

Sending an email...

Sending an email...

Composing and Coordinating Services Coordination Artifacts as natural services glue Encapsulating the logic of Service Composition & Coordinations Two Basic Architectures Single Tuple Centre Multiple Tuple Centres

A simple scenario: SMS/email coordination

A Taste of Service Coordination (1) Composing Basic Email and SMS Service Basic Gluing Activity: “Automatic SMS Sending” Single Tuple Centre Architecture

Single Tuple Centre Approach (1)

Single Tuple Centre Approach (2)

A Taste of Service Coordination (2) Multiple Tuple Centres Architecture Introducing a new coordination artifact for service orchestration

Multiple Tuple Centres Approach (1)

Multiple Tuple Centres Approach (2)

Towards Full-fledged Service Orchestration Coordination Artifacts used as general purpose Workflow/Orchestration Engines agents responsible of individual job/task execution tuple centres encapsulate/enact task coordination social tasks

Outcomes Separation of Concerns Encapsulation of Coordination Policies agents coordination artifacts Encapsulation of Coordination Policies prescriptiveness & control runtime adaptability dynamic inspection/change of coordination artifacts’ coordination behaviour reuse

Ongoing & Future Work Service Catalogue Current: email, ftp, web browsing, LEGO Mindstorms Ongoing: SMS, Vocal, generic web services Exploiting the TuCSoN Organisation Support Service Organisation Role-based Access Control Testing/Using Services in System Engineering Web Service Orchestration & Choreography BPEL4WS, BPML, WSCI