Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 1: Computing with Services Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter Visions for the Web Open Environments Services Introduced The Evolving Web Standards Bodies Chapter 1 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 The Web As It Is Not easy to program Designed for people to get information Focuses on visual display (as in HTML) Lacks support for meaning Supports low-level interactions HTTP is stateless Processing is client-server Creates avoidable dependencies among what should be independent components Chapter 1 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

The Web As It Is Becoming Enable interactions autonomous, heterogeneous parties (information providers and users) Go beyond visual display to capture meaning  Semantic Web Support standardized interfaces  Web services Support complex activities  processes Support rich interactions among autonomous parties  agents Chapter 1 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Historical View of Services over the Web Generation Scope Technology Example First All Browser Any HTML page Second Programmatic Screen scraper Systematically generated HTML content Third Standardized Web services Formally described service Fourth Semantic Semantic Web services Semantically described service Chapter 1 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Viewpoints on Services Traditionally, a capability that is provided and exploited, often but not always remotely Networking: bundle of bandwidth-type properties Telecom: features (caller ID, forwarding) Systems: operational functions (billing, storage); parceled up into operation-support systems Web or Grid: Web pages or Grid resources Wireless: Wireless access; messaging By contrast, we treat services as resembling real-life services or business partners Chapter 1 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

What is a Web Service? A piece of business logic accessible via the Internet using open standards (Microsoft) Encapsulated, loosely coupled, contracted software functions, offered via standard protocols (DestiCorp) A set of interfaces providing a standard means of interoperating between different software applications, running on a variety of platforms and frameworks (W3C) Our working definition: A service is functionality that can be engaged Chapter 1 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Scope Includes wherever Internet and Web technologies are employed Intranet: network restricted within an enterprise Extranet: private network restricted to selected enterprises Virtual Private Network (VPN): a way to realize an intranet or extranet over the Internet Chapter 1 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service Composition Vision Obviously desirable and challenging Specify and provide services independently, hiding implementations Use services in combination in novel ways Going beyond the idea of a passive object Obviously desirable and challenging But is this what we want? Can or should implementations be hidden? What about organizational visibility? How to assess risk? How to handle exceptions? Chapter 1 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Applications of Composable Services Portals Legacy system interoperation E-commerce Virtual enterprises Grid computing Chapter 1 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Autonomy Independence of business partners (users and organizations) Political reasons Ownership of resources Control, especially of access privileges Payments Technical reasons Opacity of systems with respect to key features, e.g., precommit in distributed databases Chapter 1 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Heterogeneity Independence of component designers and system architects Political reasons Ownership of resources Technical reasons Conceptual problems in integration Fragility of integration Difficult to guarantee behavior of integrated systems Chapter 1 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Dynamism Independence of system administrators Needed because the parties change Architecture and implementation Behavior Interactions Make configurations dynamic to improve service quality and maintain flexibility Chapter 1 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Locality: How to Handle the Above Service-Oriented Computing: Semantics, Processes, Agents August 2004 Locality: How to Handle the Above Reduce sharing of data and metadata to reduce inconsistencies and anomalies Reduce hard-coding, which reflects out-of-band agreements among programmers Bind dynamically to components Use standardized formats to express data Express important knowledge as metadata Use standardized languages to express metadata Relax consistency constraints Obtain remote knowledge only when needed Correct rather than prevent violations of constraints: often feasible Chapter 1 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

System Architectures: Centralized Service-Oriented Computing: Semantics, Processes, Agents System Architectures: Centralized August 2004 Terminal 3270 Terminal Terminal Terminal Terminal Mainframe Terminal Terminal Terminal Terminal Terminal Terminal Chapter 1 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

System Architectures: Client-Server Service-Oriented Computing: Semantics, Processes, Agents August 2004 System Architectures: Client-Server Workstation Client PC Client PC Client PC Client E-Mail Server Web Server Database Server Master-Slave Chapter 1 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

System Architectures: Peer-to-Peer Service-Oriented Computing: Semantics, Processes, Agents August 2004 System Architectures: Peer-to-Peer Application Application Application Application E-Mail System Web System Database System Chapter 1 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

System Architectures: Cooperative Service-Oriented Computing: Semantics, Processes, Agents August 2004 System Architectures: Cooperative Application Agent Application Agent Application Agent Application Agent Agent Agent E-Mail System Agent Agent Database System Web System (Mediators, Proxies, Aides, Wrappers) Chapter 1 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Chapter 1 Summary Evolving perspectives on the Web Evolutions in IT architectures Open environments challenge some fundamental assumptions of computer science Autonomy Heterogeneity Dynamism Services, if understood correctly, can support IT in open environments Chapter 1 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 2: Basic Standards for Web Services Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter eXtensible Markup Language (XML) Simple Object Access Protocol (SOAP) Web Services Description Language (WSDL) Directory Services Universal Description, Discovery, and Integration (UDDI) Chapter 2 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Standards for Web Services Chapter 2 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Markup and Metadata History None, e.g., CSV Ad hoc tags SGML (Standard Generalized Markup L): complex, few reliable tools HTML (HyperText ML): simple, unprincipled, mixes structure and display XML (eXtensible ML): simple, yet extensible subset of SGML to capture new vocabularies Machine processible Generally, comprehensible (easier debugging), though verbose and arcane Chapter 2 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

XML Basics and Namespaces <?xml version="1.0"?> <!– not part of the document per se --> <arbitrary:toptag xmlns="http://one.default.namespace/if-needed" xmlns:arbitrary="http://wherever.it.might.be/arbit-ns"       xmlns:random="http://another.one/random-ns">      <arbitrary:atag attr1="v1" attr2="v2"> Optional text also known as PCDATA <arbitrary:btag attr1="v1" attr2="v2" /> </arbitrary:atag> <random:simple_tag/> <!– abbreviate start and end --> <random:atag attr3="v3"/> <!– compare arbitrary:atag --> </arbitrary:toptag> Chapter 2 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

XML Schema Grammar (data definition language) for specifying valid documents Uses same syntax as regular XML documents: verbose and difficult to read Provides local scoping of subelement names Incorporates namespaces Types Primitive (built-in): string, integer, float, date, … simpleType constructors: list, union Restrictions: intervals, lengths, enumerations, regex patterns, Flexible ordering of elements Key and referential integrity constraints Chapter 2 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Web Services: Basic Architecture Broker Registry; well-known Publish or announce (WSDL) Find or discover (UDDI) Service Provider Bind or invoke (SOAP) Service Requestor Not well-known Chapter 2 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Basic Profile (BP 1.0) The Web Services Interoperability Organization (WS-I) has specified the following Basic Profile version 1.0: SOAP 1.1 HTTP 1.1 XML 1.0 XML Schema Parts 1 and 2 UDDI Version 2 WSDL 1.1 Chapter 2 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Describing a Service Name e.g., GetTemperature Types of Input Parameters e.g., (String, String) Types of Output Parameters e.g., Integer Chapter 2 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

SOAP (Simple Object Access Protocol) Used to exchange messages via HTTP, SMTP, and SIP (Session Initiation Protocol for Internet telephony) Originally designed for remote-procedure calls (RPC) Works through firewalls on port 80 Character-based, so easy to encrypt/decrypt and thus easy to secure Inefficient due to character, not binary, data and large headers Does not describe bidirectional or n-party interaction Chapter 2 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Ex. SOAP Request POST /temp HTTP/1.1 Host: www.socweather.com Content-Type: text/xml; charset="utf-8" Content-Length: xxx SOAPAction: "http://www.socweather.com/temp" <!-- Above: HTTP headers and a blank line. --> <!—These comments and below: an XML document --> <?xml version=“1.0”?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> <env:Body> <m:GetTemp xmlns:m="http://www.socweather.com/temp.xsd"> <m:City>Honolulu</m:City> <m:When>now</m:When> </m:GetTemp> </env:Body> </env:Envelope> Chapter 2 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Ex. SOAP Response HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: xxx SOAPAction: "http://www.socweather.com/temp" <?xml version="1.0"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> <env:Body> <m:GetTempResponse xmlns:m="http://www.socweather.com/temp.xsd"> <m:DegreesCelsius>30</m:DegreesCelsius> </m:GetTempResponse> </env:Body> </env:Envelope> Chapter 2 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

WSDL: Web Services Description Language Describes a programmatic interface to a Web service, including Definitions of data types Input and output message formats The operations provided by the service Network addresses Protocol bindings Chapter 2 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

WSDL Data Model Chapter 2 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Directory Services Support discovery: enable applications, agents, Web service providers, Web service requestors, people, objects, and procedures to locate each other White pages – entries found by name Yellow pages – entries found by characteristics and capabilities A basic directory might be a simple database (passive) or a broker/facilitator (active, that provides alerts and recruits participants) UDDI – both white pages and yellow pages, but passive Chapter 2 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

UDDI: Universal Description, Discovery, and Integration UDDI is a Web service that is based on SOAP and XML UDDI registers tModels: technical descriptions of a service’s behavior businessEntities: describes the specifications of multiple tModels Chapter 2 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Yellow, Green, and White Pages in UDDI Chapter 2 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Data Model for UDDI Chapter 2 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

WSDL  UDDI Chapter 2 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Chapter 2 Summary The main triad of Web services standards Bring together well-known ideas SOAP: object access and messaging WSDL: based on CORBA IDL UDDI: based on directories Provide necessary functionality for interoperation Are complicated in their details Meant for tool vendors rather than programmers Increasingly hidden by tools Chapter 2 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 3: Programming Web Services Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter Representational State Transfer (ReST or REST) Developing and Using Web Services Web Service Interoperability Chapter 3 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Representational State Transfer REST is an architectural style for networked systems that constrains the connector semantics (not the component semantics) The Web is a network of hyperlinked resources A resource is anything identified by a URI A Web application works as a state machine A client selecting a link is a state transition, resulting in receiving the next page (next state) of the application Chapter 3 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Characteristics of REST Client-Server Statelessness: requests cannot take advantage of stored contexts on a server Great for load balancing Caching: responses can be labeled as cacheable Uniform interface – URIs, hypermedia Layered components Focus on resources as opposed to methods: Read, construct, update a resource representation Well-suited to hypermedia applications Chapter 3 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

HTTP Verbs Popular verbs Idempotent operations Get: query (no side effects) Post: update Put Delete Idempotent operations Multiple executions = one execution Challenge: the specification imposes requirements but with no way to judge compliance Especially, can use Get and Post instead of much of SOAP Chapter 3 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Software for Open Environments Tempting to simply lift current database and programming techniques for open environments Popular pitfall (blame the tools for it) Think of objects (get and set methods); use Web services standards to invoke them Poor performance Tight coupling Error: services at too fine a granularity Chapter 3 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Simple B2C Web Service Example Suppose you want to sell cameras over the Web, debit a credit card, and guarantee next-day delivery Your application must update sales database debit the credit card send an order to the shipping department receive an OK from the shipping department for next-day delivery update an inventory database Problems: Some steps complete but not all Chapter 3 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

“Traditional” B2C Problems What if the order is shipped, but the debit fails? What if the debit succeeds, but the order was never entered or shipped? Chapter 3 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Traditional (Database) Approach A traditional database approach works only for a closed environment: Transaction processing (TP) monitors (such as IBM’s CICS, Transarc’s Encina, BEA System’s Tuxedo) can ensure that all or none of the steps are completed, and that systems eventually reach a consistent state But what if the user’s modem is disconnected right after he clicks on OK? Did the order succeed? What if the line went dead before the acknowledgement arrives? Will the user order again? The TP monitor cannot get the user into a consistent state! Chapter 3 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Approach for Open Environment Server application could send email about credit problems, or detect duplicate transactions Downloaded applet could synchronize with server after broken connection was restored, and recover transaction; applet could communicate using http, or directly with server objects via CORBA/IIOP or RMI If there are too many orders to process synchronously, they could be put in a message queue, managed by a Message Oriented Middleware server (which guarantees message delivery or failure notification), and customers would be notified by email when the transaction is complete The server behaves like an agent! Chapter 3 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Requirements Cross-enterprise processes Exception handling Autonomy leading to updates by “whim” Exception handling Revisions leading to updates by necessity Conversations and long-lived transactions Contracts among parties involved Chapter 3 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Chapter 3 Summary Tools help with low-level details Agreeing on standards is more important than the standards themselves Should conceptualize interactions in a manner compatible with the Web architecture Can simplify from SOAP in many cases The above is a small point anyway Bigger challenges are in ensuring larger-scale interactions, ensuring integrity, handling exceptions, … Sophisticated programming models are emerging Chapter 3 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 4: Enterprise Architectures Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter Enterprise Integration JEE .NET Model Driven Architecture Legacy Systems Chapter 4 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

JEE Technology Chapter 4 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

.NET Technology Chapter 4 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

.NET Web Services COBOL Web service for multiplication (Mike’s joke) <%@ webservice language=''COBOL'' %> CLASS-ID. MULTIPLICATIONSERVICE. FACTORY. PROCEDURE DIVISION. METHOD-ID. MULTIPLY. DATA DIVISION. LINKAGE SECTION. 01 VAL-1 PIC S9(9) COMP-5. 02 VAL-2 PIC S9(9) COMP-5. 01 PRODUCT PIC S9(9) COMP-5. PROCEDURE DIVISION USING BY VALUE VAL-1 VAL-2 RETURNING PRODUCT. COMPUTE PRODUCT = VAL-1 * VAL-2. END METHOD MULTIPLY. END FACTORY. END CLASS MULTIPLICATIONSERVICE. Chapter 4 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Legacy Systems A pejorative term for computing systems that Run on obsolete hardware and nonstandard networks Run poorly documented, unmaintainable software Consist of poorly modeled databases Support rigid user interfaces Notice that “legacy systems” is not synonymous with “mainframe” Mainframes have had a resurgence in the last decade: no longer obsolete hardware; often support modern OSs (Linux); not necessarily poorly modeled or rigid (some elements are obsolete or arcane) Most problems are with software whether on mainframes or other machines Chapter 4 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

How Legacy Systems Arise Service-Oriented Computing: Semantics, Processes, Agents August 2004 How Legacy Systems Arise Proprietary software: not supporting industry standards (vendors who hope to lock in the market through incompatibility) Meaning embedded procedurally in the code Ad hoc changes to software in response to changing requirements, because of changes in laws, regulations, competition, or other business needs bugs Chapter 4 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Legacy Systems: Pros and Cons Service-Oriented Computing: Semantics, Processes, Agents August 2004 Legacy Systems: Pros and Cons Fulfill crucial business functions Run the world’s airline reservation systems Run most air traffic control programs Have dedicated users Represent huge investments in time and money Complicate reuse and sharing of data and programs cause redundancy, wasted effort, and integrity violations Chapter 4 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Migration Updating technology is Essential A continual process All at once? Expensive Risky Brittle Frustrating for users Gradual change: dismantle legacy and build desired system hand-in-hand Install and test piecemeal Chapter 4 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Applying Services New Service Services Refactored from Legacy Backend Application Legacy Backend Legacy Interface Error: services at too coarse a granularity Chapter 4 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Chapter 4 Summary Services must fit into existing architectures J2EE and .NET are architecturally quite similar Legacy systems provide the basis for many modern services They host key data and processes Interoperating with them is nontrivial Challenge: refactoring legacy capabilities to derive best value from resulting services Chapter 4 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 5: Principles of Service-Oriented Computing Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter Use Cases Service-Oriented Architectures Major Benefits Composing Services Spirit of the Approach Chapter 5 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Hint: Consider each vertex and edge in turn Exercise: In What Ways Do We Need to Enhance the Barebones SOA Architecture? Hint: Consider each vertex and edge in turn Service Broker Publish or announce (WSDL) Find or discover (UDDI) Service Provider Bind or invoke (SOAP) Service Requestor Chapter 5 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Description The description should be unambiguous, formal representations of A service’s functionality A service’s nonfunctional attributes A user’s needs and preferences Chapter 5 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Engagement Architecture: P2P, messaging Transactions: replications, recovery Coordination Workflows and processes Choreographies Chapter 5 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Collaboration Reasoning Consistency maintenance Negotiation Organizational modeling Business protocols, interaction patterns Contracts, monitoring, and compliance Chapter 5 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Discovery and Selection Finding the right services Semantic matchmaking Team matchmaking: creating functioning collaborations (organizations) Economic selection Reputation and recommendation Distributed architectures Accommodating domain-specific or idiosyncratic qualities of service Trust Chapter 5 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Engineering Methodologies Service Management Security Ontologies: for description Process models: for engagement Service Management Deployment Administration Scalability Security Chapter 5 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Key Concepts for an SOA Loose coupling Implementation neutrality Flexible configurability Persistence Granularity Teams Chapter 5 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Chapter 5 Summary Does moving to services create so many problems? No, these are the needs of open environments Services merely highlight them As computing moves from closed to open environments, virtually every technical aspect is up for grabs Great research and practical opportunities Think of real-life service engagements Chapter 5 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 6: Modeling and Representation Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter Integration versus Interoperation Common Ontologies Knowledge Representations Relationships Hierarchies Modeling Fundamentals Unified Modeling Language (UML) Chapter 6 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Integration versus Interoperation Tight coupling Loose coupling Chapter 6 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Modeling and Composing Services Service-Oriented Computing: Semantics, Processes, Agents August 2004 Modeling and Composing Services Chapter 6 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Dimensions of Abstraction: 1 Service-Oriented Computing: Semantics, Processes, Agents August 2004 Dimensions of Abstraction: 1 Information resources are associated with abstractions over different dimensions, which capture knowledge that is relevant for interoperation. These may be thought of as constraints that must be discovered and represented Data Domain specifications Value ranges, e.g., Price >= 0 Allow/disallow null values Chapter 6 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Dimensions of Abstraction: 2 Service-Oriented Computing: Semantics, Processes, Agents August 2004 Dimensions of Abstraction: 2 Structure Taxonomic representations and relationships such as in schemas and views, e.g., securities are stocks Specializations and generalizations of domain concepts, e.g., stocks are a kind of liquid asset Value maps, e.g., S&P A+ rating corresponds to Moody’s A rating Semantic data properties, sufficient to characterize the value maps, e.g., some stock price databases consider daily averages; others closing prices Cardinality constraints Integrity constraints, e.g., each stock must have a unique SEC identifier Chapter 6 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Dimensions of Abstraction: 3 Process Procedures, i.e., how to process information, e.g., how to decide what stock to recommend Preferences for accesses and updates in case of data replication (based on recency or accuracy of data) Preferences to capture view update semantics Contingency strategies, e.g., whether to ignore, redo, or compensate Contingency procedures, i.e., how to compensate transactions Flow, e.g., where to forward requests or results Temporal constraints, e.g., report tax data every quarter Chapter 6 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Dimensions of Abstraction: 4 Service-Oriented Computing: Semantics, Processes, Agents August 2004 Dimensions of Abstraction: 4 Policy Security, i.e., who has rights to access or update what information? (e.g., customers can access all of their accounts, except blind trusts) Authentication, i.e., a sufficient test to establish identity (e.g., passwords, retinal scans, or smart cards) Bookkeeping (e.g., logging all accesses) Chapter 6 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Value Maps: 1 A value map relates the values expressed by different services Key properties Totality Order preservation Consistent inversion Chapter 6 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Value Maps: 2 Chapter 6 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Ontology A specification of a conceptualization or a set of knowledge terms for a particular domain, including The vocabulary: concepts and relationships The semantic interconnections: relationships among concepts and relationships Some simple rules of inference and logic Some representation languages for ontologies: Uniform Modeling Language (UML) Resource Description Framework Language Schema (RDFS) Web Ontology Language (OWL) Some ontology editors: Protégé, Webonto, OilEd Chapter 6 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Common Ontologies A shared representation is essential to successful communication and interoperation For humans: physical, biological, and social world For computational agents: common ontology (terms used in communication) Representative efforts are Cyc (and Opencyc) WordNet (Princeton); LDOCE; OED Several upper-level ontologies, including by IEEE Mostly stable concepts such as space, time, person, which can be used within various domains Chapter 6 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Ontologies and Articulation Axioms Service-Oriented Computing: Semantics, Processes, Agents August 2004 Ontologies and Articulation Axioms Mapping by hand, but with tool support Developing a common ontology: All at once Incrementally via consensus Chapter 6 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Knowledge Representation Expressive power Procedural (how) versus declarative (what) Declarative pros: enables standardization, optimization, improved productivity of developers Declarative cons: nontrivial to achieve and causes short-term loss of performance Trade-offs shifted by Web to favor declarative modeling Chapter 6 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Frames versus Descriptions Frame-based approaches are like object-oriented representations: Intuitive but rely on names of classes and properties to indicate meaning Description logics provide a computationally rigorous means to represent meaning; difficult for people Managing this trade-off is a major challenge for Knowledge Representation Chapter 6 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Exercise: Which Conceptualization is Most Expressive and Flexible? awg22SolidBlueWire(ID5) blueWire(ID5, AWG22, Solid) solidWire(ID5, AWG22, Blue) wire(ID5, AWG22, Solid, Blue) wire(ID5)^size(ID5, AWG22)^type(ID5, solid)^color(ID5, Blue) Chapter 6 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Mappings among Ontologies Term-to-term (one-to-one), e.g., hookupWireO1 => wireO2 Many-to-one, e.g., solidWireO1(x, size, color) ^ strandedWireO1(x, size, color) => wireO2(x, size, color, (Stranded|Solid)) Many-to-many, e.g., solidBlueWireO1(x, size) ^ solidRedWireO1(x, size) ^ strandedBlueWireO1(x, size) ^ strandedRedWireO1(x, size) => solidWireO2(x, size, (Red|Blue)) ^ strandedWireO2(x, size, (Red|Blue)) Chapter 6 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Unified Modeling Language (UML) for Ontologies (Class Diagrams) Chapter 6 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Comparison of Modeling Languages Chapter 6 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Chapter 6 Summary Shared models are essential for interoperation Based on shared ontologies or conceptualizations Good models must accommodate several important considerations Modeling requires several subtle considerations Declarative representations facilitate reasoning about and managing models Formalization enables ensuring correctness of models and using them for interoperation Chapter 6 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 7: Resource Description Framework (RDF) Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

RDF Provides a basis for knowledge representation Supports inferencing Simple language to capture assertions (statements), which help capture knowledge, e.g., about resources Combines old KR ideas (frames, OO modeling) but uses the Web to enhance their range and avoid some longstanding problems Chapter 7 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Why RDF? XML RDF expresses the content itself Gives us a document tree Doesn’t identify the content represented by a document, where content means Concepts the document is about Relationships among them Enables multiple representations for the same content RDF expresses the content itself Chapter 7 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Resources and Literals RDF captures descriptions of resources A resource is an “addressable” object Identified via a URI Of which a description can be given (and which is worth talking about) A literal is something simpler A value, e.g., string or integer Cannot be given a description Chapter 7 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Statements or Triples RDF is based on a simple grammar An RDF document is just a set of statements or triples Each statement consists of Subject: a resource Object: a resource or a literal Predicate: a resource Comes with RDFS, a vocabulary to create vocabularies Chapter 7 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Rendering RDF RDF is not about the surface syntax but about the underlying content Using the XML serialization of RDF RDF is not tied to XML Standard XML namespace syntax Namespaces defined by the RDF standard Typically abbreviated rdf and rdfs Chapter 7 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Example in XML (Using Dublin Core) <?xml version='1.0' encoding='UTF-8'?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/"> <rdf:Description rdf:about="http://www.wiley.com/SOC"> <dc:title>Service-Oriented Computing</dc:title> <dc:creator>Munindar</dc:creator> <dc:creator>Michael</dc:creator> <dc:publisher>Wiley</dc:publisher> </rdf:Description> </rdf:RDF> rdf:Description gathers statements about one subject Chapter 7 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Example in N-Triples Notation <http://www.wiley.com/SOC> <http://purl.org/dc/elements/1.1/title> "Service-Oriented Computing" . <http://purl.org/dc/elements/1.1/creator> "Munindar" . "Michael" . <http://purl.org/dc/elements/1.1/publisher> "Wiley" . Could also write individual statements in the XML syntax, but the rdf:Description element simplifies the notation Chapter 7 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Exercise Graphs represent binary relationships naturally The vendor ships SKU-99 Express a three-party relationship The vendor ships SKU-99 quickly Hint: think of gerunds from natural language grammar Chapter 7 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Reification of Statements Reify: to make referenceable, essential for quoting statements to Agree or disagree with them Assert modalities: possible, desirable, … Make a statement into a resource; then talk about it rdf:Statement is the class whose rdf:type the given statement (object) is; additional properties such as rdf:subject, rdf:object, and rdf:predicate Chapter 7 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

RDF Schema Analogous to an object-oriented type system built on top of RDF. Defines rdfs:Class, rdfs:subClassOf rdfs:Resource, rdfs:Literal rdfs:Property, rdfs:subPropertyOf rdfs:range, rdfs:domain rdfs:label, rdfs:comment, rdfs:seeAlso Applications of RDF Schema deferred to OWL, which greatly enhances the above Chapter 7 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

RDF Schema versus XML Schema Both help define custom vocabularies An XML Schema document gives us syntactic details An RDF Schema document gives us (part of) the meaning of a vocabulary An OWL document (next chapter) captures richer meaning Chapter 7 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Collections Function as containers rdf:Bag rdf:Sequence rdf:Alt (choice) Accompanied by properties to extract elements Schematically represented as rdf:_1, and so on Chapter 7 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Chapter 7 Summary RDF captures deeper structure than XML RDF captures graphs in general Meaning depends on the graph, not the document that represents a graph RDF is based on an simple linguistic representation: subject, predicate, object But “webified” via URIs RDF comes with RDF Schema In essence, an object-oriented type system: a vocabulary to create new vocabularies Used for important vocabularies (FOAF, DC, Mozilla extensions) Provides a basis for OWL Chapter 7 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 8: Web Ontology Language (OWL) Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter “Species” or Dialects Constructors Axioms Inference Dialects Compared Expressiveness Chapter 8 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Web Ontology Language (OWL) RDF captures the basics, i.e., an object-oriented type system Additional subtleties of meaning are needed for effective KR OWL standardizes additional constructs to show how to capture such subtleties of meaning Builds on RDF, by limiting it Gives particular semantics to new terms Chapter 8 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

OWL in Brief Specifies classes and properties in a form of description logic (DL) Class operators analogous to Boolean operators and, not, and or Constraints on properties: transitive, … Restrictions: constructs unique to DL Has three species: OWL Full, OWL DL, and OWL Lite This course: OWL DL Chapter 8 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Custom Metadata Vocabularies Creating metadata for services and their information resources they rely upon presupposes custom vocabularies for such metadata The metadata must be given a standard semantics so that different parties interpret it the same way, and so that tools can function appropriately. <Mammal rdf:ID=“Mary”/> <Mammal rdf:ID=“John”> <hasParent rdf:resource=“#Mary”/> </Mammal> Chapter 8 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Ontologies to Define Vocabulary Semantics A trivial ontology defining our vocabulary Uses simple subclasses and properties Disjointness goes beyond RDF Object properties refine RDF properties; relate two objects <owl:Class rdf:ID="Mammal"> <rdfs:subClassOf rdf:resource="#Animal"/> <owl:disjointWith rdf:resource="#Reptile"/> </owl:Class> <owl:ObjectProperty rdf:ID="hasParent"> <rdfs:domain rdf:resource="#Animal"/> <rdfs:range rdf:resource="#Animal"/> </owl:ObjectProperty> Chapter 8 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Simple Inference Given the definition for the property hasParent and the snippet <owl:Thing rdf:ID=“Fido"> <hasParent rdf:resource="#Rover"/> </owl:Thing> we can infer that Fido is an Animal Chapter 8 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

OWL Entities and Relationships Chapter 8 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Constructing OWL Classes Explicitly (as in the examples above) or Anonymously, using Restrictions (next page) Set operators: intersectionOf, unionOf, complementOf, e.g., <owl:Class rdf:ID='SugaryBread'> <owl:intersectionOf rdf:parseType='Collection'> <owl:Class rdf:about='#Bread'/> <owl:Class rdf:about='#SweetFood'/> </owl:intersectionOf> </owl:Class> Chapter 8 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Restrictions: 1 A unique feature of description logics Kind of like division in arithmetic: define classes in terms of a restriction that they satisfy with respect to a given property Anonymous: typically included in a class def to enable referring them Key primitives are someValuesFrom a specified class allValuesFrom a specified class hasValue equal to a specified individual or data type minCardinality maxCardinality cardinality (when maxCardinality equals minCardinality) Chapter 8 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Restrictions: 2 Examples of restriction fragments <owl:Restriction> <owl:onProperty rdf:resource="#hasFather"/> <owl:maxCardinality rdf:datatype="xsd:nonNegativeInteger"> 1 </owl:maxCardinality> </owl:Restriction> <owl:onProperty rdf:resource='#bakes'/> <owl:someValuesFrom rdf:resource='#Bread'/> Chapter 8 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Restrictions: 3 The maker of a Wine must be a Winery <owl:Class rdf:ID="Wine"> <rdfs:subClassOf rdf:resource="&food;PotableLiquid" /> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hasMaker" /> <owl:allValuesFrom rdf:resource="#Winery" /> </owl:Restriction> </rdfs:subClassOf> ... </owl:Class> The maker of a Wine must be a Winery The allValuesFrom restriction is on the hasMaker property of this Wine class (Makers of other products such as cheese are not constrained by this local restriction) Chapter 8 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Axioms: 1 Assertions that are given to be true Can be especially powerful in combination with other axioms, which may come from different documents Some primitives rdfs:subClassOf owl:equivalentClass Chapter 8 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Axioms: 2 <owl:AllDifferent> <!– in essence, pair-wise inequalities <owl:distinctMembers rdf:parseType='Collection'> <ex:Country rdf:ID='India'/> <ex:Country rdf:ID='Russia'/> <ex:Country rdf:ID='USA'/> <owl:distinctMembers/> </owl:AllDifferent> <ex:Country rdf:ID='Iran'/> <ex:Country rdf:ID='Persia'> <owl:sameIndividualAs rdf:resource='#Iran'/> </ex:Country> Chapter 8 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Restrictions versus Axioms Axioms are global assertions that can be used as the basis for further inference Restrictions are constructors When we state that hasFather has a maxCardinality of 1, we are Defining the class of animals who have zero or one fathers: this class may or may not have any instances Not stating that all animals have zero or one fathers Often, to achieve the desired effect, we would have to combine restrictions with axioms (such as based on equivalentClass) Chapter 8 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Inference OWL is about content, not the syntax Statements from different documents about the same URI are automatically conjoined OWL can appear unintuitive to the uninitiated Declare: no one can have more than one mother Declare: Mary is John’s mother Declare: Jane is John’s mother What will you conclude? A DBMS would declare an integrity violation An OWL reasoner would say Mary = Jane Chapter 8 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Dialects Compared OWL DL: the core dialect, includes DL primitives; not necessarily (but often practically) tractable OWL Lite: adds restrictions to OWL DL make it tractable OWL Full: lifts restrictions to allow other interpretations; extremely general; potentially intractable (undecidable); included just for fancy expressiveness needs Chapter 8 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Expressiveness Limitations: 1 OWL DL cannot express some simple requirements Non-tree models: because instance variables are implicit in OWL restrictions, OWL cannot express conditions that require that two variables be identified Think of siblings – two people who have the same parents – but in terms of classes Do the same thing with class definitions Chapter 8 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Expressiveness Limitations: 2 Specialized properties Cannot state that the child of a mammal must be a mammal and so on, without Defining new child properties for each class Adding an axiom for each class stating that it is a subClassOf the restriction of hasChild to itself Analogous to the problem in a strongly typed object-oriented language without generics You have to typecast the contents of a hash table or linked list Chapter 8 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Expressiveness Limitations: 3 Constraints among individuals Cannot define tall person: class of persons whose height is above a certain threshold Can define ETHusband: class of persons who have been married to Elizabeth Taylor Cannot capture defeasibility (also known as nonmonotonicity) Birds fly Penguins are birds Penguins don’t fly Chapter 8 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Chapter 8 Summary OWL builds on RDF to provide a rich vocabulary for capturing knowledge Synthesizes a lot of excellent work on discrete, taxonomic knowledge representation Fits well with describing information resources – a basis for describing metadata vocabularies Critical for unambiguously describing services so they can be selected and suitably engaged Chapter 8 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 9: Ontology Management Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter Motivation Standard Ontologies Consensus Ontologies Chapter 9 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Motivation Ontologies provide A basis for communication among heterogeneous parties A way to describe services at a high level But how do we ensure the parties involved agree upon the ontologies? Traditionally: manually develop standard ontologies Emerging approach: determine “correct” ontology via consensus Chapter 9 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Some Standard Ontologies IEEE Standard Upper Ontology Common Logic (language and upper-level ontology) Process Specification Language Space and time ontologies Domain-specific ontologies, such as health care, taxation, shipping, … Chapter 9 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

An Example Upper Ontology Chapter 9 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

OASIS Universal Business Language (UBL) Chapter 9 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Standardization Pros Even if imperfect, standards can Save time and improve effectiveness Enable specialized tools where appropriate Improve the reach of a solution over time and space Suggest directions for improvement Chapter 9 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Standardization Cons Standardization of domain-specific ontologies is Cumbersome: standardization is more a sociopolitical than a technical process Difficult to maintain: often out of date by the time completed Often violated for competitive reasons Chapter 9 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Standardization: Proposed Approach Use standard languages (XML, RDF, OWL, …) where appropriate Take high-level concepts from standard models: Domain experts are not good at KR Lot of work in the best of cases Work toward consensus in chosen domain Chapter 9 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Inducing Common Ontologies Instead of beginning with a standard, develop consensus to induce common ontologies Assumptions: No global ontology Individual sources have local ontologies Which are heterogeneous and inconsistent Motivation: Exploit richness of variety in ontologies To see where they reinforce each other To make indirect connections (next page) Chapter 9 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Relating Ontologies: No Overlap Safety in Numbers Possibly equivalent Truck Wheel APC Tire No Overlap Truck Wheel APC Tire equivalence partOf Possibly equivalent Safety in Numbers Chapter 9 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Relating Ontologies A concept in one ontology can have one of seven mutually exclusive relationships with a concept in another: Subclass Of Superclass Of Part Of Has Part Sibling Of Equivalent To Other (topic-specific) Each ontology adds constraints that can help to determine the most likely relationship Chapter 9 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Initial Experiment: 55 Individual Simple Ontologies about Life Chapter 9 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

55 Merged Ontologies Chapter 9 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Methodology for Merging and Reinforcement Merging used smart substring matching and subsumption For example, living  livingThing However, living X livingRoom because they have disjoint subclasses 864 classes with more than 1500 subclass links were merged into 281 classes related by 554 subclass links Retained the classes and subclass links that appeared in more than 5% of the ontologies 281 classes were reduced to 38 classes with 71 subclass links Merged concepts that had the same superclass and subclass links Result has 36 classes related by 62 subclass links Chapter 9 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Consensus Ontology for Mutual Understanding Chapter 9 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Consensus Directions The above approach considered lexical and syntactic bases for similarity Other approaches can include Folksonomies (as in tag clouds) Richer dictionaries Richer voting mechanisms Richer forms of structure within ontologies, not just taxonomic structure Models of authority as in the WWW Chapter 9 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Alternative Approaches We may construct large ontologies by Inducing classes from large numbers of instances using data-mining techniques Building small specialized ontologies and merging them (Ontolingua) Top-down construction from first principles (Cyc and IEEE SUO) Chapter 9 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Aside: Categorizing Information Consensus is driven by practical considerations Should service providers classify information where it Belongs in the “correct” scientific sense? Where users will look for it? Case in point: If most people think a whale is a kind of fish, then should you put information about whales in the fish or in the mammal category? Chapter 9 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Chapter 9 Summary For large-scale systems development, coming to agreement about acceptable ontologies is nontrivial Standardization helps, but suffers from key limitations Consensus approaches seek to figure out acceptable ontologies based on available small ontologies Should always use standards for representation languages Chapter 9 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 10: Execution Models Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter Interoperation Architecture Messaging Peer-to-Peer Computing Enterprise Service Bus CORBA Jini Grid Computing Chapter 10 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Interoperation (Standards and Technologies) Service-Oriented Computing: Semantics, Processes, Agents August 2004 Interoperation (Standards and Technologies) Requires surmounting a series of challenges Transport: HTTP, SMTP, SIP Messaging: XML (including XQuery …), SOAP Data and structure: WSDL Finding and binding: UDDI, QoS techniques Semantics: ontologies (RDF, OWL, IEEE SUO, Cyc) Transactions: WS-Coordination, WS-AtomicTransaction, WS-BusinessActivity Process: OWL-S, WS-CDL, PSL, BPEL4WS Policy: XACML Dynamism: FIPA AMS, RuleML, Jason Cooperation: FIPA ACL, multiagent systems Chapter 10 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Application Interoperation Chapter 10 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Architectural Elements Low-level (included in app server): Directories, messaging Data and process interoperation: Metadata and transformations Routing Rules engine Business process Modeling and execution engine Chapter 10 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Invocation-Based Adapters Common in distributed object settings (EJBs, DCOM, CORBA) Synchronous: blocking method invocation Asynchronous: nonblocking (one-way) method invocation with callbacks Deferred synchronous: (in CORBA) sender proceeds independently of the receiver, but only up to a point Execution is best effort, at most once More than once is OK for idempotent operations, not otherwise Chapter 10 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Message-Oriented Middleware: 1 Analogous to store and forward networks Queues: point to point Support posting and reading messages Topics: logical multicasts Support publishing and subscribing to application-specific topics Thus more flexible than queues Some messages correspond to event notifications Chapter 10 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Message-Oriented Middleware: 2 Inherently asynchronous Supports loose coupling Reliability: cannot guarantee successful message delivery, but can provide failure notification Usually used through an invocation-based interface By polling or via registered callbacks onMessage() method of message-driven beans Chapter 10 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Enterprise Service Bus An abstraction separating enterprise services and transport Supports services as units of functionality Supports routing of messages (via MoM or Web services or anything else) Enables an architectural style in which transformers convert message formats Often accompanied with modules for process, policy, logging, identity management, … Chapter 10 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Peer-to-Peer Computing Models of computation Symmetric client-server: Each party can query the other, thereby giving each power over the other at different times Doesn't fundamentally look beyond client-server Asynchrony: While the request-response paradigm corresponds to pull, asynchronous communication corresponds to push Undesirable: push applications that place their entire intelligence on the server (pushing) side Federation of equals: When the participants can enact whatever protocols they see fit Chapter 10 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Chapter 10 Summary Increasingly, interoperation architectures promote loose coupling and arms-length relationships Hence focus on messaging Similar challenges have been addressed multiple times but service improvements result in easier composition and deployment of services Chapter 10 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 11: Transaction Concepts Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter Basic concepts ACID properties Schedules Locking Transactions over composed services Relaxing serializability Extended transaction models Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Motivation As services are employed for serious purposes, they will inevitably update information resources Can we be sure that such updates preserve integrity? What about when multiple services need to work together? What about when the services are involved in a long-lived activity? Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Transactions: 1 A transaction is a computation (i.e., program in execution) that accesses and possibly modifies a database: Not the source code; not the binaries Can be interleaved with other transactions But guarantees certain correctness properties The purpose of the transaction concept is to avoid the problems (“race conditions”) that may arise from interleaving Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Transactions: 2 Operation: action on a data item Transaction: set of operations performed in a partial order according to the specifying program Assume total order here for simplicity A transaction makes a set of operations appear as one logical operation Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

ACID Properties If programmers guarantee correctness of individual transactions, then DBMS guarantees correctness of any set of them The ACID properties formalize the notion of a transaction behaving as one operation (Failure) Atomicity—all or none—if failed then no changes to DB or messages This is the vernacular notion of “transaction” Consistency—don't violate DB integrity constraints: execution of the op is correct Isolation (Atomicity)—partial results are hidden Durability—effects (of transactions that "happened" or committed) are forever Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Transaction Lifecycle A transaction goes through well-defined stages in its life (always terminating) Inactive Active (may read and write) Entire business logic takes place here Precommit (no errors during execution; needed for mutual commitment protocols) Failed (errors) Committed (the DBMS decides this) Forgotten (the DBMS reclaims data structures) Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Schedules Schedules are histories of computations showing all events of interest Schedule of T1...Tn has all ops of T1...Tn in the same order as within each Ti, but interleaved across Ti to model concurrency Includes active transactions Typically a partial order among events Two challenges What are the bad schedules? How can the DBMS prevent them? Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Conflict Order-sensitivity of operations Two operations of different transactions, but on the same data item, conflict if Their mutual order is significant, i.e., determines at least one of the following: The final value of that item read by future transactions The value of the item as read by present transactions Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Serial Schedules Transactions are wholly before or after others (i.e., occur one by one) Clearly, we must allow for service requests to come in slowly, one-by-one Thus, under independence of transactions (assuming each transaction is correct), serial schedules are obviously correct Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Serializable Schedules Interleaved schedules are desirable Why? Those equivalent to some serial schedule. Here equivalent can mean Conflict equivalent—all pairs of conflicting ops are ordered the same way View equivalent—all users get the same view Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Achieving Serializability Optimistically: Let each transaction run, but check for serializability before committing Pessimistically: Use a protocol, e.g., locking, to ensure that only serializable schedules are realized Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Locks Lock item x while using item x Binary: at most one party may lock x Lock(x): acquire the lock Computation hangs until lock(x) returns, i.e., the lock is acquired Unlock(x): relinquish the lock Gives mutual exclusion but restrictive Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Multimode Locks When one party has an exclusive lock, no other party may have an exclusive or a shared lock Shared-lock(x) needed for read(x) Others can also hold a shared lock Exclusive-lock(x) needed for write(x) No one else can concurrently hold a shared or exclusive lock Can be upgraded (read to write) or downgraded (write to read) Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Achtung! By itself, using locks does not guarantee serializability What is an example of a bad schedule obtained while using locks? A locking protocol, i.e., how locks are acquired and released, is critical That is, locks on different data items must be related Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Two-Phase Locking (2PL) Two phases in a transaction’s life Growing phase: acquire but not release locks Shrinking phase: release but not acquire locks Guarantees serializability, but can deadlock Strict 2PL releases all locks at once when the transaction commits or rolls back Ensures rigorous schedules (to be discussed) But can deadlock Conservative 2PL: takes all locks early; risks starvation Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Reading From T1 reads from T2 if the schedule contains a subsequence w2(x)...r1(x), where w2 is the first write on x going backwards from r1(x) a2 doesn’t occur between w2 and r1 Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Recoverable Schedules In which a transaction commits after all transactions it read from have committed In terms of the ACID properties, what is the risk in allowing a nonrecoverable schedule? Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Avoid Cascading Aborts (ACA) In which a transaction does not read from uncommitted transactions What is the risk in allowing such reads? Are cascading aborts Legal? Expensive? Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Strict Schedules In which an item can't be read or written until the previous transaction to write that item has committed (the aborted ones having been factored out) Compare with ACA This allows us to UNDO by restoring the before image Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Rigorous Schedules In which an item can't be read or written until the previous transaction to read or write that item has committed Compare with strict schedules Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Distributing ACID Transactions Service-Oriented Computing: Semantics, Processes, Agents August 2004 Distributing ACID Transactions ACID transactions are applicable for Brief, simple activities (few updates; seconds, at most) On centralized architectures Without distribution, ACID transactions would be a nonstarter outside of a single DBMS Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Closed-Nested Distributed Transactions Service-Oriented Computing: Semantics, Processes, Agents August 2004 Closed-Nested Distributed Transactions ACID transactions can be implemented in distributed settings Consider two or more subtransactions, conceptually organized as a tree Ensure atomicity through two-phase commit (2PC) Ensure isolation so that results are not exposed till the global transaction commits As in WS-AtomicTransaction Why would ACID transactions ever be useful for SOC? Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Transactions over Composed Services Service-Oriented Computing: Semantics, Processes, Agents August 2004 Transactions over Composed Services Expedia Composed service as a transaction Composed Transaction Manager Direct users service service United Sheraton LDB1 LDB2 Assume each service ensures serializability locally Two main kinds of service agreements are possible: Execution, e.g., LDB retains full control on execution even if in conflict with CTM Communication, e.g., LDB decides what (control) information to release Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Compositional Serializability Service-Oriented Computing: Semantics, Processes, Agents August 2004 Compositional Serializability Transactions throughout the system should be serializable CTM ensures that the composed transactions are serializable This doesn't guarantee compositional serializability, because of indirect conflicts: CTM does T1: r1(a); r1(c) CTM does T2: r2(b); r2(d) LDB1 does T3: w3(a); w3(b) LDB2 does T4: w4(c); w4(d) Since T1 and T2 are read-only, they are serializable. LDB1 sees S1=r1(a); c1; w3(a); w3(b); c3; r2(b); c2 LDB2 sees S2=w4(c); r1(c); c1; r2(d); c2; w4(d); c4 Each LDB has a serializable schedule; yet jointly they put T1 before and after T2 Notice we would have lots of potential compositions, so the problem is worse Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Strawman 1: Tickets Compositional serializability fails because of local conflicts that the CTM does not see Fix by always causing conflicts--whenever two composed transactions execute at a site, they must conflict there. Indirect conflicts become local conflicts visible to the LDB Make each composed transaction increment a ticket at each site Downside: Causes all local subtransactions of a transaction to go through a local hotspot Composed transactions are serialized, but only because many are aborted! Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Strawman 2: Rigorous Scheduling Service-Oriented Computing: Semantics, Processes, Agents August 2004 Strawman 2: Rigorous Scheduling Hold read and write locks till end (no tickets) Check that this prevents the bad example The CTM must delay all commits until all actions are completed possible only if allowed by LDB requires an operation-level interface to LDB Downside: Causes all sites to be held up until all are ready to commit Essentially like the 2PC approach Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Possible Methodology When no cross-service constraints apply, local serializability is enough Split data into local and shared partitions LDB controls local data CTM controls shared (local transactions can read, but write only via CTM) Downside: doesn’t work in all cases All shared data is managed through a special service Only for the most trivial compositions Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Compositional Atomicity Service-Oriented Computing: Semantics, Processes, Agents August 2004 Compositional Atomicity Can succeed only if the services restrict their autonomy through service-level agreements, e.g., 2PC Otherwise, the services May not release their prepare-to-commit state May not participate in a mutual commit protocol such as 2PC Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Compositional Deadlock Service-Oriented Computing: Semantics, Processes, Agents August 2004 Compositional Deadlock Assume LDB1 and LDB2 use 2PL. If a deadlock is formed Solely of upper-level transactions, then the CTM may detect it Of a combination of local and upper transactions, then CTM won't know of it LDBs won't share control information Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Compositional Atomicity & Durability Service-Oriented Computing: Semantics, Processes, Agents August 2004 Compositional Atomicity & Durability Without 2PC, what would happen when a CT fails? Each service individually ensures “correctness” according to its local policies Achieve weaker atomicity, durability via: Redo: rerun the writes from log Retry: rerun all of a subtransaction Compensate: semantically undo all other subtransactions Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Beyond ACID Transactions Service-Oriented Computing: Semantics, Processes, Agents August 2004 Beyond ACID Transactions Composed services feature in business processes, which Cross administrative boundaries Are complex, i.e., long-running, failure-prone, multisite, with subtle consistency requirements Cooperate with other processes, involving computational and human tasks Respect autonomy and heterogeneity of components Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Extended Transactions Service-Oriented Computing: Semantics, Processes, Agents August 2004 Extended Transactions Extended transaction models relax the ACID properties by modifying various features Allowing open nesting, wherein partial results are revealed (newer, non-ACID) Atomicity, e.g., contingency procedures, to ensure “all” Consistency restoration, e.g., via compensation, to ensure “none” Constraints among subtransactions, such as Commit dependencies Abort dependencies Ultimately, a transaction must be atomic (albeit in a relaxed sense) Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Compensation Something that semantically undoes the effect of a transaction Common in business settings Compensations are necessary even if imperfect Deposit and withdraw Reserve and cancel Ship and return Pay and refund Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Extended Transaction Models The ones we consider Sagas Flex Transactions DOM Transactions Several others, mostly either Implementation-specific or Narrower than the above General-purpose scheduling approach (Chapter 14) Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Sagas Guarantee atomicity but not isolation Execute a sequence of transactions If all transactions succeed, then good (all) If any transaction fails, undo all previous in reverse order (none) Assumptions Compensations succeed (eventually) for the first several members of sequence Retries succeed for the last several Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Distributed Object Management Avoid partial failure of a multitransaction via either total success or total failure Total success Redo from log Retry Contingency procedures Total failure Undo from log Compensations Uses ordering constraints and vital subtransactions Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Chapter 11 Summary We need a means to ensure that services behave reasonably, i.e., by ensuring the integrity of data Database management provides the notion of transactions for this purpose Distributed transactions can apply in closed settings Ensuring the ACID properties is infeasible in open settings Extended transaction models are needed Simple constructs of such models are helpful, and being encoded in standards Often, an important application is process management (coming up) More sophisticated behaviors require increased intelligence in modeling and enactment, also to be discussed later Chapter 11 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 12: Coordination Frameworks for Web Services Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter WSCL: Web Services Conversation Language WSCI: Web Service Choreography Interface WS-Coordination Web service transaction types BTP: Business Transaction Protocol Chapter 12 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Achieving Business Interoperation The parties must Know each other’s identity and location (presumes suitable directories) Agree on the low-level transport protocols and encoding formats Agree on the syntax and semantics of documents to be exchanged Agree on their expectations about when different documents will be sent and received This specification is termed a business protocol An instance of a business protocol is a conversation (but sometimes the term is used to mean protocol – watch out!) Chapter 12 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Process Abstractions Orchestration: A process is a partial order of actions under the control of a central conductor; akin to a workflow [Global; central] Choreography: A process is an exchange of messages among participants; akin to a conversation as described by WSCL and WSCI [Global; distributed] Collaboration: A process is a joint set of activities among business partners [Local; distributed] Workflow: narrower concept than process, which emphasizes control and data flows from a central perspective; original idea behind modern orchestration Chapter 12 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Parts of a WSCL Specification WSCL: Web Services Conversation Language Document Type Definitions: specify what types of XML documents will be exchanged Interaction Types: Send, Receive, SendReceive, ReceiveSend, Empty <Interaction interactionType="SendReceive" id="Payment"> <OutboundXMLDocument id="Invoice" hrefSchema="http://sc.edu/InvoiceRS.xsd"/> <InboundXMLDocument id="Payment" hrefSchema="http://ncsu.edu/Payment.xsd"> </InboundXMLDocument> </Interaction> Transitions: order of the interactions <Transition> <SourceInteraction href="Quote"/> <DestinationInteraction href="Purchase"/> </Transition> <DestinationInteraction href="CatalogInquiry"/> Conversation: a name for the protocol and a list of its interactions and transitions; this is one party’s perspective Chapter 12 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Concepts in WSCL Chapter 12                                                                                                                                                 Concepts in WSCL Chapter 12 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Well-Formed Conversations All interactions are reachable from the initial interaction The final interaction is reachable from all interactions If a transition from interaction A to interaction B specifies a SourceInteractionCondition, then all transitions from A to B do so The final interaction and transitions to the final interaction unambiguously clarify for each participant when a conversation is finished Chapter 12 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Example Conversation Definition Chapter 12 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Example WSCL Specification: 1 <Conversation name="StoreFrontServiceConversation" xmlns="http://www.w3.org/2002/02/wscl10" initialInteraction="Start" finalInteraction="End" > <ConversationInteractions> <Interaction interactionType="ReceiveSend" id="Login"> <InboundXMLDocument hrefSchema=“http://conv1.org/LoginRQ.xsd” id="LoginRQ"/> <OutboundXMLDocument hrefSchema=“http://conv1.org/ValidLoginRS.xsd” id="ValidLoginRS"/> <OutboundXMLDocument id="InvalidLoginRS" hrefSchema=“http://conv1.org/InvalidLoginRS.xsd”/> </Interaction> … <Interaction interactionType="Empty" id="Start" /> <Interaction interactionType="Empty" id="End" /> </ConversationInteractions> Chapter 12 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Example WSCL Specification: 2 <ConversationTransitions> <Transition> <SourceInteraction href="Start"/> <DestinationInteraction href="Login"/> </Transition> … <SourceInteraction href="Login"/> <DestinationInteraction href="Registration"/> <SourceInteractionCondition href="InvalidLoginRS"/> <SourceInteraction href="Logout"/> <DestinationInteraction href="End"/> </ConversationTransitions> </Conversation> Chapter 12 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

WSCI: Web Service Choreography Interface Choreography refers to a global view of how messages are exchanged WSCI describes the flow of messages exchanged by a Web service that is interacting with other services WSCI is viewed as an enhancement to WSDL (inserted within a WSDL description) Chapter 12 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Example WSCI Add-In to WSDL <correlation name="quotationCorrelation“ property="tns:quotationID“/> <interface name="StockQuoteWS"> <process name="ProvideStockQuote" instantiation="message"> <sequence> <action name="ReceiveLogin“ role="tns:StockQuoteWS“ operation="tns:QuoteToUser/LogIn"/> <action name="ReceiveStockQuoteRequest" role="tns:StockQuoteWS" operation="tns:QuoteToUser/ProvideQuote"> <correlate correlation="tns:quotationCorrelation"/> <call process="tns:LookupPrice"/> </action> <action name="ReceiveLogout“ role="tns:StockQuoteWS“ operation="tns:QuoteToUser/LogOut"/> </sequence> </process> <process name="LookupPrice" instantiation="other"> <action name="QueryNYSE" role="tns:StockQuoteWS“ operation="tns:QuoteToUser/QueryNYSE"/> </interface> Chapter 12 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

WSCI Example for Transaction Compensation <sequence> <context> <transaction name="buyStock" type="atomic"> <compensation> <action name="NotifyUnavailable" role="NYSE“ operation="tns:NYSEtoBroker/NotifyUnavailable"/> </compensation> </transaction> </context> <action name="BuyShare" role ="Broker“ operation="tns:BrokerToNYSE/BuyShare"/> <while name="BuyShares"> <condition>defs:fundsRemain</condition> <action name="BuyShare" role ="Broker“ operation="tns:BrokerToNYSE/BuyShare"> <correlate correlation="defs:buyingCorrelation"/> </action> </while> </sequence> <!-- Compensating Behavior for the Above Transaction --> <exception> <onTimeout property="tns:expiryTime" type="duration" reference="tns:BuyShares@end"> <compensate transaction="tns:buyStock"/> </onTimeout> </exception> Chapter 12 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

WS-Coordination WS-Coordination is the specification for a service whose job is to coordinate the activities of the Web services that are part of a business process A coordination service is an aggregation of three services: Registration: for parties to register with the coordinator Activation: to create an instance of a coordination context Coordination protocol: to define the specific protocol to be followed Chapter 12 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

WS-Coordination Service Chapter 12 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

WS-Coordination Service Chapter 12 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

WS-AtomicTransaction: Protocol for an Atomic Transaction The travel agency and the airline can perform 2PC, but the museum can perform only a simple, zero-phase update Chapter 12 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Business Transaction Protocol (BTP) Chapter 12 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 12 Summary SOC needs an ability to specify interactions among business partners in a manner that respects the partners’ autonomy and heterogeneity: conversations are a natural way to do so SOC needs support for transactions The more relaxed varieties are preferable, but there is a place for traditional transactions as well The transactions are based on a small set of primitives Chapter 12 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 13: Process Specifications Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter Processes Describing Dynamics with UML Workflows Business Process Languages BPEL4WS (WS-BPEL) ebXML RosettaNet PSL: Process Specification Language Chapter 13 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Processes and Workflows Chapter 13 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

A Process Is … [Abstractions] Service-Oriented Computing: Semantics, Processes, Agents August 2004 A Process Is … [Abstractions] Orchestration: An ordering of actions (activity graph or script, which may iterate) under the control of a central conductor; akin to a workflow [Global view; central] Workflow: narrower concept than process; emphasizes control and data flows from a central perspective; usually tool-specific and focused on human tasks Choreography: An exchange of messages among participants; akin to a conversation as described by WSCL, WS-CDL, ebBP [Global view; distributed] Collaboration: A joint set of activities among business partners [Local views; distributed] Chapter 13 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Telecommunications Order Processing Older workflow tools support specialized (ad hoc) notations Chapter 13 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Describing Dynamics with UML UML Activity Diagrams are practically identical to BPMN (Business Process Modeling Notation) and WS-BPEL (Business Process Execution Language) Sequence: a transition from one activity to the next Branch: a decision point among alternative flows of control Merge: where two or more alternative flows of control rejoin Fork: a splitting of a flow of control into two or more concurrent and independent flows of control Join: a synchronization of two or more concurrently executing flows of control into one flow Chapter 13 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

UML Activity Diagram Implementation of a vendor’s purchase process Chapter 13 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Flow Interoperability Patterns Among others: Chained Nested Synchronized What guarantees would you obtain from each? How would you accommodate exceptions in each? Chapter 13 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

WS-BPEL Metamodel Chapter 13 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Process as a Composite Web Service Chapter 13 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Stock Quote Service in WS-BPEL <process name="simple" targetNamespace="urn:stockQuoter" xmlns:tns="urn:stockQuoter" xmlns:sqp="http://tempuri.org/services/stockquote" xmlns=&BPEL;/> <containers> <container name="request" messageType="tns:request"/> <container name="response" messageType="tns:response"/> <container name="invocationRequest" messageType="sqp:GetQInput"/> <container name="invocationResponse" messageType="sqp:GetQOutput"/> </containers> <partners> <partner name="caller" serviceLinkType="tns:StockQuoteSLT"/> <partner name="provider" serviceLinkType="tns:StockQuoteSLT"/> </partners> <sequence name="sequence"> <receive name="receive" partner="caller" portType="tns:StockQuotePT" operation="wantQuote" container="request" createInstance="yes"/> <assign> <copy> <from container="request" part="symbol"/> <to container="invocationRequest" part="symbol"/> </copy> </assign> <invoke name="invoke" partner="provider" portType="sqp:StockQuotePT" operation="getQuote" inputContainer="invocationRequest" outputContainer="invocationResponse"/> <from container="invocationResponse" part="quote"/> <to container="response" part="quote"/> </copy> </assign> <reply name="reply" partner="caller" portType="tns:StockQuotePT" operation="wantQuote" container="response"/> </sequence> </process> Chapter 13 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Electronic Business Extensible Markup Language (ebXML) Established jointly by UN-CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) OASIS (Organization for the Advancement of Structured Information Standards) Provides specification languages for business processes, business messages to facilitate trading agreements Motivations: Global standard for companies of all sizes Automate finding business partners Chapter 13 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

ebXML Vocabulary Unified Modeling Methodology (UMM) Specialized UML for Business Processes Collaboration Protocol Profile (CPP) Describes a business with respect to its roles in specified processes, the messages it exchanges, and the transport mechanism (e.g., HTTPS) Collaborative Partner Agreement (CPA) Intuitively, like an “intersection” of two CPPs Technical agreement between two or more partners May be legally binding Chapter 13 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Design of an ebXML System Chapter 13 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Discover Partner Information and Negotiate Chapter 13 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Implementing ebXML ebXML is a set of specifications: of collaborations and repositories for discovering business partners Build and deploy its custom ebXML-compliant application to implement necessary roles in different collaborations Use COTS ebXML compliant applications and components (from ERP vendors) Business Service Interface (BSI): a wrapper that enables a given party to participate properly in an ebXML exchange Chapter 13 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Business Service Interface Interfaces with the legacy system to have it play a role in a specific protocol (e.g., vendor in 3A4) Is aware of its own Collaborative Protocol Profile Handles transactions based on all current agreements (CPAs) Chapter 13 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

RosettaNet PIP for Creating a Purchase Order: The Content for ebXML PIP: Partner Interface Process; an interaction protocol ebXML BPSS: language for specifying PIPs Two-party protocols Request-response only No specification of the meanings of the messages exchanged Chapter 13 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Exercise: Exception in a Process Recording student registration Assume that each database management system supports two-phase commit for transactions Task #2 checks that the student has completed the necessary prerequisites for all the courses for which the student is registering Consider a scenario where Tasks #3, #4, #5 succeed, but Task #2 fails As the system administrator, what operations would you have to perform in order to restore consistency to your system? How would you modify the process to prevent problems such as this from occurring? Chapter 13 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 13 Summary In virtually all serious applications of SOC, services are composed into processes Current approaches for process modeling are based on workflow abstractions WS-BPEL enables specification of processes ebXML also considers the life cycle of processes RosettaNet is an application of ebXML Flows interact in various ways Exceptions in flows can be handled via (extended) transactions or through application-specific means (where interesting patterns can arise) Chapter 13 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 15: Agents Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter Agents Introduced Agent Descriptions Abstractions for Composition Describing Compositions Service Composition as Planning Rules Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 What is an Agent? The term agent in computing covers a wide range of behavior and functionality An agent is an active computational entity With a persistent identity Perceives, reasons about, and initiates activities in its environment Communicates (with other agents) and changes its behavior based on others Business partners => agents Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Agents and MAS for SOC Why agents for services? Unlike objects, agents Autonomy, heterogeneity, dynamism Unlike objects, agents Are proactive and autonomous Cooperate or compete Model users, themselves, others Dynamically use and reconcile ontologies Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Modeling Agents: AI Traditionally, emphasize mental concepts Beliefs: agent’s representation of the world Knowledge: (usually) true beliefs Desires: preferred states of the world Goals: consistent desires Intentions: goals adopted for action Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Modeling Agents: MAS Emphasize interaction Social: about collections of agents Organizational: about teams and groups Legal: about contracts and compliance Ethical: about right and wrong actions Emphasize autonomy and communication Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Mapping SOC to Agents Agents as components of an open system Autonomy => ability to enter into and enact contracts; compliance Heterogeneity => ontologies Loose coupling => communication Trustworthiness => contracts, ethics, learning, incentives Dynamism => combination of the above Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

A Reactive Agent Environment e; RuleSet r; while (true) { state = senseEnvironment(e); a = chooseAction(state, r); e.applyAction(a); } Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 A Rational Agent Rationality depends on ... A performance measure, e.g., expected utility What the agent has perceived so far What the agent knows ahead of time The actions the agent can perform An ideal rational agent: for each possible percept sequence, it acts to maximize its expected utility, on the basis of its knowledge and the evidence from the percept sequence Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Logic-Based Agents An agent is a knowledge-based system Challenges: Explicitly represents symbolic model of the world Reasons symbolically via logical deduction Challenges: Maintaining adequate descriptions of the world Representing information about complex real-world entities in symbolic terms Easier in information environments than in general Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Cognitive Architecture for an Agent For SOC, sensors and effectors are services; communication is via messaging middleware Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Generic BDI Architecture brf Generate options filter action Sensor input beliefs desires intentions A BDI architecture addresses how beliefs, desires and intentions are represented, updated, and acted upon Action output Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Architecture of BDI-Based Agent Execution Cycle: the agent Receives new information Updates beliefs and goals Reasons about actions Intends an action Selects an intended action Activates selected intention Performs an action Updates beliefs, goals, intentions Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Web Ontology Language for Services (OWL-S) An OWL-S service description provides Declarative ads for properties and capabilities, used for discovery Declarative APIs, used for execution A declarative description of services Based on their inputs, outputs, preconditions, and effects Used for composition and interoperation Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

OWL-S Service Ontology Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

OWL-S Compared to UDDI Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

OWL-S Service Model Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

OWL-S Example: Processing Book Orders Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

OWL-S IOPEs for Bookstore Example Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Composition as Planning Service composition as planning: Represent current and goal states Represent each service as an action (with inputs, outputs, preconditions, effects) Represent a composed service as a plan that invokes the constituent services constraining the control and data flow to achieve the goal state Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Rules: Logical Representations Rules are desirable because they are Modular: easy to read and maintain Inspectable: easy to understand Executable: no further translation needed Expressive: (commonly) Turing complete and can capture knowledge that would otherwise not be captured declaratively Compare with relational calculus (classical SQL) or description logics (OWL) Declarative, although imperfectly so Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Kinds of Rules ECA or Reaction Derivation rules: special case of above On event if condition then perform action Derivation rules: special case of above Integrity constraints: derive false if error Inference rules If antecedent then consequent Support multiple computational strategies Forward chaining; backward chaining Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Applying ECA Rules Capture protocols, policies, and heuristics as rules Examples? Often, combine ECA with inference rules (to check if a condition holds) Modeling challenge What is an event? How to capture composite events by pushing event detection to lower layers Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Applying Inference Rules Inference rules capture general requirements well Elaboration tolerance requires defeasibility Write general rules Override them as need to specialize them to account for context Leads to logical nonmonotonicity Easy enough operationally but difficult to characterize mathematically Details get into logic programming with negation Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Use of Variables Need free variables to make the rules generic in how they apply For ECA rules: event and condition For inference rules: antecedent Should generally not have free variables in consequent to ensure “safety” Free variable in action indicates perform action for each binding Free variable in consequent means assert it for each binding Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 15 Summary Agents are natural fit with open environments Agent abstractions support expressing requirements in a natural manner Agents go beyond objects and procedural programming Self-study Jess Chapter 15 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 16: Multiagent Systems Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter Applicability in Service-Based Systems Multiagent Architecture Agent Types Lifecycle Management Consistency Maintenance Modeling Other Agents Cognitive Concepts Chapter 16 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Basic Problems of MAS Distributing control among agents Describing, decomposing, distributing tasks Interacting and communicating Representing goals, problem-solving states, and other agents Maintaining consistency, reconciling conflicts Chapter 16 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

(de facto) Standard Agent Types Service-Oriented Computing: Semantics, Processes, Agents August 2004 (de facto) Standard Agent Types Chapter 16 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Brokerage Service Cooperates with a Directory Service An agent requests the Brokerage Service to recruit one or more agents who can provide a service Brokerage Service uses knowledge about the requirements and capabilities of registered agents to Determine the appropriate agents to which to forward a request for a service Negotiates with the agents to determine a suitable set of service providers Potentially learn about the properties of the responses example: Brokerage agent determines that advertised results from agent X are incomplete and seeks a substitute for X Chapter 16 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

FIPA Agent Management System Chapter 16 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Agent Management System: 2 Handles the creation, registration, location, communication, migration and retirement of agents. Provides the following services: White pages, such as agent location, naming and control access services, which are provided by the Agent Management System (AMS). Agent names are represented by a flexible and extensible structure called an agent identifier, which can support social names, transport addresses, name resolution services, amongst other things Yellow pages, such as service location and registration services, which are provided by the Directory Facilitator (DF) Agent message transport services Chapter 16 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Java Agent Development Framework JADE, the most popular FIPA-compliant agent framework for multiagent systems: http://jade.tilab.com/ The most established of the publicly available agent frameworks (FIPA-OS and Zeus having died) Chapter 16 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Consistency Maintenance across Services Service-Oriented Computing: Semantics, Processes, Agents August 2004 Consistency Maintenance across Services A truth maintenance system (TMS) helps maintain consistency Performs a form of propositional deduction Maintains justifications and explains the results of its deductions Updates beliefs incrementally when premises change TMSs help us Deal with atomicity Maintain modular models Chapter 16 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Architecture of TMS-Based Agent Service-Oriented Computing: Semantics, Processes, Agents August 2004 Architecture of TMS-Based Agent Problem Solver TMS justifications beliefs Problem solver: decides on actions TMS: maintains a network of beliefs based on the justifications relating them Chapter 16 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Knowledge Base Integrity Service-Oriented Computing: Semantics, Processes, Agents August 2004 Knowledge Base Integrity Stability: believe everything justified validly; disbelieve everything else Well-Foundedness: no circular beliefs Logical consistency: no logical contradictions Completeness: find a consistent state if one exists, or report failure Problems arise when knowledge is distributed Chapter 16 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Distributed TMS Each agent has a justification-based TMS Each datum can have status OUT IN: valid local justification EXTERNAL: must be IN for some agent When a problem solver adds or removes a justification, the DTMS Unlabels data based on the changed justification Relabels all unlabeled shared data (in one or more iterations) Chapter 16 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Degrees of Logical Consistency Service-Oriented Computing: Semantics, Processes, Agents August 2004 Degrees of Logical Consistency Inconsistency: an agent is individually inconsistent Local Consistency: all agents are individually consistent Local-and-Shared Consistency: agents are locally consistent and agree about any data they might share Global Consistency: agents are globally consistent (union of KBs is consistent) The DTMS maintains local-and-shared consistency and well-foundedness Chapter 16 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Cooperative Service: 1 Client f3: afford(xcorp) IN r3: buy(X) :- query(Broker recommend(X)), afford(X) IN ? recommend(?X) Broker f1: afford(xcorp) OUT f2: cash-rich(xcorp) IN r2: recommend(X) :- takeover-bid(X) IN r1: takeover-bid(X) :- cash-rich(X) IN Chapter 16 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Cooperative Service: 2 Client f3: afford(xcorp) IN r3: buy(X) :- query(Broker recommend(X)), afford(X) IN recommend(XCorp) Broker f1: afford(xcorp) OUT f2: cash-rich(xcorp) IN r1: recommend(X) :- takeover-bid(X) IN r2: takeover-bid(X) :- cash-rich(X) IN f3: recommend(xcorp) IN Shared with: Client; Justification: (f2 r1 r2) Chapter 16 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Cooperative Service: 3 Client f3: afford(xcorp) IN r3: buy(X) :- query(Broker recommend(X)), afford(X) IN f4: recommend(xcorp) EXTERNAL Shared with: Broker; Justification: ( ) f5: buy(xcorp) IN Justification: (f3 f4 r3) Broker f1: afford(xcorp) OUT f2: cash-rich(xcorp) IN r1: recommend(X) :- takeover-bid(X) IN r2: takeover-bid(X) :- cash-rich(X) IN f3: recommend(xcorp) IN Shared with: Client; Justification: (f2 r1 r2) Chapter 16 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Cooperative Service: 4 Client f3: afford(xcorp) IN r3: buy(X) :- query(Broker recommend(X)), afford(X) IN f4: recommend(xcorp) EXTERNAL Shared with: Broker; Justification: ( ) f5: buy(xcorp) IN Justification: (f3 f4 r3) relabel recommend(XCorp) Broker f1: afford(xcorp) OUT f2: cash-rich(xcorp) IN --> OUT r1: recommend(X) :- takeover-bid(X) IN r2: takeover-bid(X) :- cash-rich(X) IN f3: recommend(xcorp) IN --> OUT Shared with: Client; Justification: (f2 r1 r2) Chapter 16 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Cooperative Service: 5 Client f3: afford(xcorp) IN r3: buy(X) :- query(Broker recommend(X)), afford(X) IN f4: recommend(xcorp) OUT Shared with: Broker; Justification: ( ) f5: buy(xcorp) OUT Justification: (f3 f4 r3) Broker f1: afford(xcorp) OUT f2: cash-rich(xcorp) OUT r1: recommend(X) :- takeover-bid(X) IN r2: takeover-bid(X) :- cash-rich(X) IN f3: recommend(xcorp) OUT Shared with: Client; Justification: (f2 r1 r2) Chapter 16 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 16 Summary Study multiagent systems because interactions among agents make them interesting Communication among agents is key, although markets (later chapter) only support implicit communication through prices Programming environments support agent interactions Consistency maintenance is a major challenge Agents must model agents; simple techniques are often adequate; more subtle techniques can require extensive reasoning power Chapter 16 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 17: Organizations Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter Contracts Spheres of Commitment Achieving Collaboration via Conventions Policies Negotiation Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Why Organizations? Serious applications of services require interactions structured in subtle ways Organizations consist of agents (business partners) providing or using services Organizations Relate well to human organizations Promote coherence in service interactions Offer a conceptually natural, high-level basis for understanding and designing service interactions Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Organizations Organizations nest naturally (not necessarily as trees) All organizations are agents Some agents are organizations Organizations help overcome limitations of individuals in Reasoning Capabilities Perception Lifetime, persistence Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Three Kinds of Organizations Concrete: agents playing roles Configured, run-time concept Abstract (templates): roles and relationships among roles Design-time concept Institutions: part abstract and part concrete Run-time concept, but the membership can change Example: eBay, where buyers and sellers can change but eBay itself is a fixed participant Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Legal Abstractions Contracts Directed obligations Hohfeldian concepts Compliance Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Contracts Contracts structure interactions among autonomous parties People and corporations Governmental agencies Compare with contracts in programming Key questions: how to create, modify, perform, or monitor contracts Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Motivation for Contracts Provide a basis for service agreements Crucial in open environments Emphasize behavior: observable by others Constrain behavior: limit autonomy Mostly disregard internal implementations, thus facilitating heterogeneity Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Legal Concepts Inherently multiagent: about interactions among autonomous parties Directed obligations One party being obliged to another party Multiagent flavor Contrast with traditional deontic logic Zero-agent: it is obliged that … One-agent: you are obliged to do … Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Rights The rights or claims a party has on another party Not the right (ethical) thing to do The claims of one party are the duties of another: claim is a correlate of duty Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Hohfeldian Concepts: 1 The term right is used ambiguously Sixteen concepts distinguish the main situations: Four main concepts Their correlates Their negations Their negations’ correlates Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Hohfeldian Concepts: 2 Claim-duty: as above Privilege-exposure: freedom from the claims of another agent Power-liability: when an agent can change the claim-duty relationship of another agent Immunity-disability: freedom from the power of another agent Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Commitments A commitment Involves three parties: a debtor commits to a creditor within a context Is scoped by its (organizational) context May be manipulated, subject to additional commitments is public (unlike beliefs) Commitments provide Flexible interactions, thus promoting coherence A basis for judging compliance Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Manipulating Commitments Service-Oriented Computing: Semantics, Processes, Agents August 2004 Manipulating Commitments Operations on commitments: Create Discharge (satisfy) Cancel Release (eliminate) Delegate (change debtor) Assign (change creditor) Metacommitments constrain the manipulation of commitments Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Commitments for Contracts A contract is a set of related commitments Provides a notional context to the commitments Applies between specified parties, in a context (e.g., UCC, real-estate, Internet commerce) In contrast to commitments, other approaches: Single-agent focused, e.g., deontic logic Don’t handle organizational aspects of contracts Don’t accommodate manipulation of contracts Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

SoCom: Sphere of Commitment A computational abstraction based on organizations An institution with additional features Involves roles (abstract) or agents (concrete) A witness for the commitment A locus for testing compliance and enforcing corrections (e.g., compensation) Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 SoComs and Structure A SoCom inherits policies from surrounding (contextual) SoCom E.g., UCC applies to commercial interactions Inherited policies can conflict because of Nonunique nesting When agents play multiple roles - Munindar Singh and Michael Huhns © Singh & Huhns

Virtual Enterprises (VE) A VE offers commitments beyond those of its members Sellers come together with a new proxy agent called VE Example of VE agent commitments: Entertain order updates Notify on change of order Price guarantee Delivery date guarantee Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

A Selling VE (Composition Example) Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Teams Tightly knit organizations Goals shared by all team members Commitments to help team members Commitments to adopt additional roles and offer capabilities on behalf of a disabled member Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Teamwork When a team carries out some complex activity Negotiating what to do Monitoring actions jointly Supporting each other Repairing plans Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Negotiation Negotiation is central to adaptive, cooperative behavior Negotiation involves a small set of agents Actions are propose, counterpropose, support, accept, reject, dismiss, retract Negotiation requires a common language and common framework (an abstraction of the problem and its solution) Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Negotiation Mechanism Attributes Service-Oriented Computing: Semantics, Processes, Agents August 2004 Negotiation Mechanism Attributes Efficiency Stability Simplicity Distribution Symmetry E.g., sharing book purchases, with cost decided by coin flip Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Negotiation among Utility-Based Agents Service-Oriented Computing: Semantics, Processes, Agents August 2004 Negotiation among Utility-Based Agents Problem: How to design the rules of an environment so that agents interact productively and fairly, e.g., Vickrey’s Mechanism: lowest bidder wins, but gets paid second lowest bid This motivates each bidder to bid its true valuation Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Negotiation A deal is a joint plan between two agents that would satisfy their goals The utility of a deal for an agent is the amount he is willing to pay minus the cost to him of the deal The negotiation set is the set of all deals that have a positive utility for every agent. The possible situations for interaction are Conflict: the negotiation set is empty Compromise: agents prefer to be alone, but will agree to a negotiated deal Cooperative: all deals in the negotiation set are preferred by both agents over achieving their goals alone Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Negotiation Mechanism Service-Oriented Computing: Semantics, Processes, Agents August 2004 Negotiation Mechanism The agents follow a Unified Negotiation Protocol, which applies to any situation. In this protocol, The agents negotiate on mixed-joint plans, i.e., plans that bring the world to a new state that is better for both agents If there is a conflict, they “flip a coin” to decide which agent gets to satisfy his goal Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Problem Domain Hierarchy Service-Oriented Computing: Semantics, Processes, Agents August 2004 Problem Domain Hierarchy Worth-Oriented Domains State-Oriented Domains Task-Oriented Domains Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Task-Oriented Domains: 1 Service-Oriented Computing: Semantics, Processes, Agents August 2004 Task-Oriented Domains: 1 A TOD is a tuple <T, A, c>, where T is the set of tasks, A is the set of agents, and c(X) is a monotonic function for the cost of executing the set of tasks X Examples Deliveries: c(X) = length of minimal path that visits X Postmen: c(X) = length of minimal path plus return Databases: c(X) = minimal number of needed DB ops Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Task-Oriented Domains: 2 Service-Oriented Computing: Semantics, Processes, Agents August 2004 Task-Oriented Domains: 2 A deal is a redistribution of tasks Utility of deal d for agent k is Uk (d) = c(Tk) - c(dk) The conflict deal, D, is no deal A deal d is individual rational if d>D Deal d dominates d’ if d is better for at least one agent and not worse for the rest Deal d is Pareto optimal if there is no d’>d The set of all deals that are individual rational and Pareto optimal is the negotiation set, NS Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Monotonic Concession Protocol Service-Oriented Computing: Semantics, Processes, Agents August 2004 Monotonic Concession Protocol Each agent proposes a deal If one agent matches or exceeds what the other demands, the negotiation ends Else, the agents propose the same or more (concede) If no agent concedes, the negotiation ends with the conflict deal This protocol is simple, symmetric, distributed, and guaranteed to end in a finite number of steps in any TOD. What strategy should an agent adopt? Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Zeuthen Strategy Offer deal that is best among all deals in NS Calculate risks of self and opponent R1=(utility A1 loses by accepting A2’s offer) (utility A1 loses by causing a conflict) If risk is smaller than opponent, offer minimal sufficient concession (a sufficient concession makes opponent’s risk less than yours); else offer original deal If both use this strategy, they will agree on deal that maximizes the product of their utilities (Pareto optimal) The strategy is not stable (when both should concede on last step, but it’s sufficient for only one to concede, then one can benefit by dropping strategy) Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Deception-Free Protocols Service-Oriented Computing: Semantics, Processes, Agents August 2004 Deception-Free Protocols Zeuthen strategy requires full knowledge of Tasks Protocol Strategies Commitments Hidden tasks Phantom tasks Decoy tasks P.O. A1 (hidden) A1 A2 Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 17 Summary Organizations are a natural metaphor for understanding and designing systems of services Organizations provide a basis for Legal and contractual concepts such as commitments Teamwork Understanding and formalizing negotiation Chapter 17 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 18: Communication Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter Agent Communication Languages Speech Act Theory Semantics Interaction Patterns Combining ACLs with Web Services Contract Net Protocol Business Protocols Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Interaction and Communication Service-Oriented Computing: Semantics, Processes, Agents August 2004 Interaction and Communication Interactions occur whenever agents share an environment Resource contention, e.g., bumping into each other Communications are interactions understood to preserve the participants’ autonomy Realized by physical actions (e.g., shared memory or messaging middleware) that may not preserve autonomy Meaning based on shared conventions Communications offer loose coupling: essential for services A message is a unit of communication Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Syntax, Semantics, Pragmatics Service-Oriented Computing: Semantics, Processes, Agents August 2004 Syntax, Semantics, Pragmatics Syntax: structure of a (communication) language Semantics: meaning based solely on the terms used Requires a structured vocabulary and a shared framework of knowledge, e.g., an ontology Pragmatics: meaning based on the context (“here”) Knowing whom to communicate with and how to find them Knowing how to initiate and maintain an exchange Knowing the effect of the communication on the recipient Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

A Classification of Message Classifications Service-Oriented Computing: Semantics, Processes, Agents August 2004 A Classification of Message Classifications Structure-based (syntactic) Distinguish messages based on grammatical forms in natural language Meaning-based (semantic) Distinguish messages based on a notion of intrinsic meaning E.g., prohibitive is different from directive, despite syntactic similarity Use-based (pragmatic) Distinguish messages based on their functions in specific classes of protocols E.g., assertion is different from acknowledgment Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Communicative Act Theory Service-Oriented Computing: Semantics, Processes, Agents August 2004 Communicative Act Theory Called speech act theory (but not specific to speech) Developed for human language Views communication as action Contrasts with traditional logic, which is about true or false assertions Considers three aspects of a message: Locution, or how it is phrased, e.g., “It is hot here” or “Turn on the air conditioner”: strings or XML documents Illocution, or how it is meant by the sender or understood by the receiver, e.g., a request to turn on the air conditioner or an assertion about the temperature: message type plus proposition Perlocution, or how it influences the recipient, e.g., turns on the air conditioner, opens the window, ignores the speaker Illocution is the core aspect Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Applying the Theory Classifications of illocutions motivate message types, but are typically designed for natural language Rely on NL syntax, e.g., conflate directives and prohibitives In natural language understanding: determining how locutions map to illocutions (inferring agents’ beliefs and intentions) For services and agents, determining the Message type is trivial, because it is explicitly encoded Agents’ beliefs and intentions is impossible, because the internal details of the agents are not known Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 ACL Semantics What does a inform, promise, request, query mean? Mentalist: a state of solo or mutual knowledge (under assumption of sincerity) Inform: speaker believes true Promise: speaker intends to make true Request: speaker intends listener to make true Query: speaker intends listener to inform if true Public: conventions based on laws and observations Inform: speaker’s commitment to veracity of Promise: speaker’s commitment to bring about Evaluation: For open systems, public semantics is essential because it underlies compliance Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

FIPA FIPA is the Foundation for Intelligent Physical Agents Incorporated as IEEE standards body Specifies standards for heterogeneous, interoperating agent-based systems Concerned with agency as it relates to Autonomous behavior Communication with other agents Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

FIPA Standards Ways of interpreting communications in a way that respects their intended meanings Communicative acts Public ontologies Transport and infrastructure Superseded by Web services and messaging standards Programming model and container Compatible with containers in application servers Compared to existing approaches XML Schema standardizes grammar, not meaning OWL standardizes ontology description, not communication Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Low-Level Patterns Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Combining Agents with Traditional Web Services ACL is the FIPA ACL standard Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Contract Net Protocol: 1 Service-Oriented Computing: Semantics, Processes, Agents August 2004 Contract Net Protocol: 1 An important generic protocol Manager announces tasks via a (possibly selective) multicast Agents evaluate the announcement; some submit bids Manager awards a contract to the most appropriate bidder Manager and contractor communicate privately as necessary Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Contract Net: 2 Applies best when problem has a well-defined hierarchy of tasks With coarse-grained decomposition No interference with each other Lacks support for specifying service agreements and contracts Yields robustness: failure can be treated as a manifestation of autonomy Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

RFQ: Task Announcement Service-Oriented Computing: Semantics, Processes, Agents August 2004 RFQ: Task Announcement Eligibility specification: criteria that an agent must meet to be eligible to submit a bid Task abstraction: a brief description of the task to be executed Bid specification: a description of the expected format of the bid Expiration time: a statement of the time interval during which the task announcement is valid Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Bid and Award Messages A bid specified the provider’s capabilities An award consists of a task specification A complete specification of the task Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Commitment Protocols Protocols enable open systems to be constructed Interaction protocols expressed in terms of Participants’ commitments Actions for performing operations on commitments (to create and manipulate them) Constraints on the above, e.g., captured in temporal logic Examples: escrow, payment, RosettaNet (107 mostly request-response Partner Interface Processes or PIPs) Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

NetBill Payment Protocol Checking compliance is easy but the representation is rigid Some obvious variations are not allowed by the FSM: The merchant may start the protocol by sending a quote The customer may send an accept prior to offer The merchant may send the goods prior to accept FSM Representation Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

NetBill using Commitments Meanings: 1. true 2. request 3. offer 4. Cm,cgoods  accept  promiseReceipt 5. goods  Cc,mpay  promiseReceipt 6. goods  pay  Cm,creceipt 7. goods  pay  receipt 8. goods  promiseReceipt 9. accept Final state: No open commitments remain Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Patterns for Commitment Operations Ensure that information about commitment operations flows to the right parties, to enable local decisions Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Complying with Commitment Protocols Compliance means commitments are discharged directly or indirectly How can an agent check if others comply with specified protocols? Commitment protocols are specified in terms of Main roles and sphere of commitment Roles essential for coordination Domain-specific propositions and actions Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Verifying Compliance Specification Run-time Verification Models based on potential causality Commitments based on branching-time TL Run-time Verification Respects design autonomy Uses TL model-checking Local verification from observed messages: each party checks the others behavior Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Run-Time Compliance Checking An agent maintains Pending commitments of which it is debtor or creditor A local model of the messages sent or received It uses this local model to verify that each commitment is discharged – or replaced by a commitment that is Invariant: a creditor of a commitment can determine if it is violated – if the commitment doesn’t refer to a third party’s actions Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Fish-Market Sample Execution Based on a vector clock Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Fish-Market Local Observations The discharge of a commitment must be reachable from its create Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Fish-Market Compliance Auctioneer can verify if the bidders comply An individual bidder cannot verify if the auctioneer complies If bidders pool their observations, then they can verify if the auctioneer complies Asymmetry indicates need for third party Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 18 Summary Communication enables loose coupling Communications are actions – thus outside the purview of traditional logic Protocols capture important patterns of communications Business protocols can be understood using commitments Model message meanings, not just syntax Check compliance with respect to commitments Chapter 18 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 19: Semantic Service Selection Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter Semantic Matchmaking An Advertising and Matchmaking Language Selecting Services SoCom Matchmaking Chapter 19 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Discovery versus Selection Often the purpose behind discovering a service is to select a good one We don’t need to find all services Just the one that’s best for us! By focusing on selection, we can Improve the payoff Reduce overhead from trying irrelevant or less relevant services Chapter 19 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Where Does Selection Apply? Service users looking for providers Service providers looking for users Brokers looking for both users and providers Markets to be populated with participants Spheres of Commitments or organizations to be instantiated The situation is fundamentally symmetric Chapter 19 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Semantic Matchmaking Match using an ontology Domain of a service Preconditions and effects of methods Use ontologies to reformulate queries and generate query plans by Generalizing or specialize concepts Partitioning concepts Decomposing properties Chapter 19 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Matchmaking Language A language to describe services and formulate service requests would need many features Provenance and ownership Cost Service agreements (e.g., refundable?) Resource requirements Availability: geographic, temporal, … Payment mechanisms Possibly, support for empirical, evaluative aspects (discussed in Chapter 20) Chapter 19 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Semantic Team Matchmaking Service-Oriented Computing: Semantics, Processes, Agents August 2004 Semantic Team Matchmaking Formally represent commitments and capabilities (not just methods) Define abstract spheres of commitment (SoCom) in terms of roles, e.g., buy-sell: Capabilities: can issue quote and ship, can pay Commitments: will honor price quote; will pay To adopt these roles, agents must have the capabilities and acquire the commitments Chapter 19 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Consumer and Provider Agents SoComs provide the context for concepts represented & communicated Chapter 19 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 19 Summary Service selection is a key aspect of SOC Service selection involves suitably rich representations of Services Services requested or desired More than two-party, client-server: Formation of SoComs to solve complex business problems Chapter 19 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 20: Social Service Selection Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter Reputation Mechanisms Recommender Techniques Referrals Social Mechanism for Trust Identity Chapter 20 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Recommending Products vs. Services Products (by a product vendor): often, The recommender is the provider Votes are known to the recommender Votes are received prior to usage (buying) Repetition is less likely (buy the same book?) Services (by a service registry) The recommender is not the provider Votes are not necessarily known to recommender Votes are given after usage Repetition may occur, invisibly to registry Chapter 20 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Reputation The agency (e.g., eBay) is the authority that Authenticates users Records, aggregates, and reveals ratings Provides the conceptual schema for How to capture ratings (typically a number and text) How to aggregate them How to decay them over time Chapter 20 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service Communities Each principal Provides services to others Provides recommendations to others Exploits services provided by others Has a reputation The agents assist their users and other agents in Evaluating the services and referrals provided by others Maintaining contact lists Deciding whom to contact for a service Chapter 20 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Social Networks and Referral Chains Referral chains provide: Way to identify a good provider Way to judge the quality of a provider Reason for a member to respond in a trustworthy manner Social networks induce referral chains in which an individual may participate As the chains get longer The trustworthiness of a recommendation decreases The effort to find providers increases Therefore, shorter chains are better Chapter 20 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Distributed Treatment of Referrals Receive request Ask Model asker Follow referrals Respond Use Rate; update Chapter 20 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Model for Referrals Each agent has An interest (services sought) An expertise (services provided) Models of acquaintances Acquaintance models are built autonomously and represent Acquaintances’ expertise (ability to provide good service along a set of dimensions) Sociability (ability to provide accurate referrals) Chapter 20 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Reputation Buildup and Collapse A participant who begins to misbehave is detected Chapter 20 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Small World Phenomenon Milgram (1967): two individuals chosen at random in the U.S.A. are linked by a chain of 6 or fewer first-name acquaintances (empirical observation) Six degrees of separation Erdös numbers Diameter of the connected Web: 20 Chapter 20 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Small-World Network Generated by perturbing a regular ring A highly structured (clustered) network with just a few random edges Random edges correspond to shortcuts Yields high clustering and short paths Direct relationships between agents who primarily participate in different subcommunities Shortcuts: weak ties Chapter 20 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Quality Relates Inversely to Clustering Chapter 20 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Weak Ties versus Clustering Conventional approaches give recommendations based on the preferences of similar users (as discussed previously) For finding the best referrals, it is best to ask dissimilar people who bring a novel perspective Define a form of controlled scattering Chapter 20 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Link Analysis Links on a web page correspond to recommendations by the page author Links provide an external criterion for estimating the value of a page (as opposed to words on a page, which can be rigged) Typically, web engines crawl the web, build giant indexes, and analyze links A referral corresponds to a targeted recommendation by an agent. While we may not crawl referrals ahead of time, the same mathematical concepts apply Chapter 20 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 20 Summary Selection must rationally be empirical: based on data Centralized reputation mechanisms address data gathering but impose too many restrictions Social network ideas can avoid such limitations Referrals help maintain distributed social networks and incorporate purposes Social structure can evolve collaboratively Services can be rated and selected and rated … Chapter 20 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 21: Economic Service Selection Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter Market Environments Auctions for Services Chapter 21 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 21 Summary Chapter 21 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 22: Building SOC Applications Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter Elements of SOC Design Self study: Quality of Service Self study: How to Create an Ontology Self study: How to Create a Process Model How to Construct Agent-Based Systems How to Engineer Composed Services Exception Handling Self study: Knowledge Management Self study: eBusiness Supply-Chain Automation Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Elements of Service-Oriented Architectures Loose coupling: focus should be on high-level contractual relationships Implementation neutrality: the interface is what should matter Flexible configurability: late binding of components Long lifetime: components should exist long enough to be discovered, to be relied upon, and to engender trust in their behavior Granularity: interactions and dependencies should occur at as high a level as possible Teams: computation in open systems should be conceptualized as business partners working as a team Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Goals for Multiagent Control Develop techniques for Locating and allocating capabilities and resources that are dispersed in the environment Predicting, avoiding, or resolving contentions over capabilities and resources Mediating among more agents, with more heterogeneity and more complex interactions Maintaining stability, coherence, and effectiveness Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Control Challenges: Agents Control gets harder as agents become more: Numerous Complex individually (e.g., more versatile) Heterogeneous (in capabilities, representations, languages) quantity complexity heterogeneity Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Control Challenges: Problems Control gets harder as the problems agents solve become more Interrelated Rapidly changing, or pursued in an uncertain and changing world Unforgiving of control failures (e.g., involving irreversible actions) degree of interaction volatility severity of failure Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Control Challenges: Solutions Control gets harder as solutions to agent problems are required to be more Efficient Robust to changing circumstances Cheaper or faster to develop individually and in concert quality / efficiency robustness low overhead Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Techniques for Agent Control Broker-based Matchmaker-based Market-based; auctions BDI and commitment based Decision theoretic Workflow (procedure) based Standard operating procedures Learning Coordinated planning Conventions Protocols Stochastic or physics-based Organizations: teams and coalitions Constraint satisfaction or optimization Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Dimensions of Control Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Task Decomposition Divide-and-conquer to reduce complexity: smaller subtasks require less capable agents and fewer resources Task decomposition must consider the resources and capabilities of the agents, and potential conflicts among tasks and agents The designer decides what operators to decompose over The system decides among alternative decompositions, if available Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Task Decomposition Methods Service-Oriented Computing: Semantics, Processes, Agents August 2004 Task Decomposition Methods Inherent (free!): the representation of the problem contains its decomposition, as in an AND-OR graph Composition designer (human does it): decomposition is programmed during implementation. (There are few principles for automatically decomposing tasks) Hierarchical planning (agents implementing the services do it): decomposition again depends heavily on task and operator representation Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Task Decomposition Examples Service-Oriented Computing: Semantics, Processes, Agents August 2004 Task Decomposition Examples Spatial decomposition: service is info source or decision point: Functional decomposition: service offers specialized expertise: Agent 1 Agent 3 Agent 2 Pediatrician Neurologist Internist Cardiologist Psychologist Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Task Distribution Criteria Service-Oriented Computing: Semantics, Processes, Agents August 2004 Task Distribution Criteria Avoid overloading critical resources Engage services on tasks where expertise matches Make an agent with a wide view assign tasks to other agents Assign overlapping responsibilities to agents to achieve coherence Assign highly interdependent tasks to agents in spatial or semantic proximity. This minimizes communication and synchronization costs Reassign tasks if necessary for completing urgent tasks Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Task Distribution Mechanisms Service-Oriented Computing: Semantics, Processes, Agents August 2004 Task Distribution Mechanisms Market mechanisms: tasks are matched to agents by generalized agreement or mutual selection (analogous to pricing commodities) Contract net: announce, bid, and award cycles Multiagent planning: planning agents have the responsibility for task assignment Organizational structure: agents have fixed responsibilities for particular tasks Recursive allocation: responsible agent may further decompose task and allocate the resultant subtasks Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

JADE Behavior for CNP Initiator Role Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Two Patterns for Engineering Service Applications Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Agents for Collaboration Each Business Collaboration is handled by an autonomous software entity (agent) On forming a Collaboration, automatically generate ebXML-compliant agents The “Agent Generator,” when integrated with the BSI, has static knowledge about local constraints and dynamic knowledge from the current CPA The software agents exchange ebXML messages to perform the selected Business Collaboration Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Why this Approach? Issues regarding transport, messaging, security constraints are to be handled for each Collaboration Business collaborations are becoming increasingly complex The system will be dealing with multiple collaborations at a given time If the transactions are legally bound or even otherwise, the non-repudiation condition MAY have to be satisfied There is always a possibility of unpredictable situations (exceptions) Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Agent-Based Coordination Methodology BOD Semantics Robust Agent Skeleton Dooley Graph Agent Skeleton Participants Enact B2B Interaction Agents Create Agent-Based B2B Transaction State Machine Participants Develop B2B Interaction Diagrams Identify B2B Conversations Augment B2B Transaction State Machine Generic B2B Use-Case and Class Models Exception-Augmented Transaction Templates Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Ford Interoperability Scenario Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Conversation Analysis Based on Mutual Understanding (Bipartite Conversation Graph) Sender Receiver Ford1 1Jarvis Ford2 2Lubetec Ford3 3Eff.Logistics Jarvis4 4Ford Lubetec5 5Ford The arcs above help identify the roles of the participants in the B2B transactions. The notation Ford1 indicates that message 1 (to Jarvis) is being sent by Ford; the notation 4Ford indicates that message 4 (sent by Jarvis) is being received by Ford. This graphical technique is the basis for constructing collaboration diagrams. Explanation: The arc from Ford1 to 4Ford indicates that Jarvis in message 4 is replying to Ford’s message 1 (ProcessPO). The arc from Lubetec6 to 2Lubetec indicates that message 6 (ShowShipment) resolves Ford’s message 2 (ProcessPO). The arc from Ford2 to 7Ford indicates that message 7 completes intermediate messages 5, which, in turn, resolves message 2. The semantics of respond, reply, resolve, and complete can be found in [Singh 2000] and [Parunak 96]. [Singh 2000] Munidar P. Singh, “Synthesizing Coordination Requirements for Heterogeneous Autonomous Agents,” Autonomous Agents and Multi-Agent Systems, no. 3, 2000, pp. 107-132. [Parunak 1996] H. Van Dyke Parunak, “Visualizing Agent Conversations: Using Enhanced Dooley Graphs for Agent Design and Analysis, International Conference on Multi-Agent Systems, ICMAS-1996, pp. 275-282. Lubetec6 6Ford Lubetec7 7Ford Jarvis8 8Ford Jarvis9 9Ford Ford10 10Greenfield Greenfield11 11Ford Greenfield12 12Ford Greenfield13 13Ford Eff.Logistics14 14Ford Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Transaction Skeletons for Agent Enactment Supplier Warehouse Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Augmented Transaction Skeletons for Agent-Based Exception Handling Ignore Exceptions Consider Exceptions Order Complete Order Complete Receive( payment ) ^send("Thank you") Receive( payment ) ^send("Thank you") exceeded( Deadline ) ^send(ReminderInvoice) Waiting for Waiting for Payment Payment ^send(ProcessInvoice) Set Deadline Alarm Start ^send(ProcessInvoice) Start Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 22 Summary Success of service-oriented computing solutions depends upon How ontologies and process models are constructed How a system is designed so that desired behaviors ensue How abstractions for interaction are fleshed out How the above are related to software engineering approaches Chapter 22 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 23: Service Management Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter Enterprise Resource Planning WS Management Framework WS Distributed Management Scalability Robust Services Chapter 23 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Advanced Composition: 1 Suppose an application needs simply to sort some data items, and suppose there are 5 Web sites that offer sorting services described by their input data types, output date type, time complexity, space complexity, and quality: One is faster One handles more data types One is often busy One returns a stream of results, another a batch One costs less Sort1 Application ? Sort2 ? ? ? Sort3 Sort5 Sort4 Chapter 23 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Advanced Composition: 2 Possible approaches Application invokes services randomly until one succeeds Application ranks services and invokes them in order until one succeeds Application invokes all services and reconciles the results Person organizes all services into one service using BPEL4WS Application contracts with one service after requesting bids Services self-organize into a team of sorting services and route requests to the best one The last two require that the services behave like agents The last two are scalable and robust Chapter 23 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 23 Summary Chapter 23 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 24: Security Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter Securing Web Services SAML and WS-Security WS-Trust XACML: eXtensible Access Control Markup Language Security and Privacy Policies Chapter 24 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 24 Summary Chapter 24 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 25: Challenges and Extensions Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005 © Singh & Huhns

Highlights of this Chapter Service-Oriented Computing: Semantics, Processes, Agents August 2004 Highlights of this Chapter Trust Ethics Coherence Benevolence Managing Privacy Key Challenges and Recommendations Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Systemic Trust Fundamentally Requires The information agents retrieve must be accurate, or characterized accurately The information agents contribute must be used appropriately Requires Sources have reliability and reputation, and specify constraints on usage Dependencies are preserved and maintained Results: information items have credibility and domains of utility; agents self-organize into service communities Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Trust Trust means that services Are understood in context Have the right capabilities and understanding of needs Follow legal contracts where specified Support one’s organization or society Follow an understood ethics Failing all else, behave rationally Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Ethical Abstractions Agents that are members of a society must have an ethics and a philosophy. This requires the development of components for Deontological ethics Teleological ethics Consequentialism Duties Obligations Applying ethics Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Motivation The ethical abstractions help us specify agents who would act appropriately Intuitively, ethics is just the basic way of distinguishing right from wrong It is difficult to separate ethics entirely from legal, social, or even economic considerations Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Right and Good Right: that which is right in itself Good: that which is good or valuable for someone or for some end Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Deontological vs. Teleological Deontological theories Right before good Being good does not mean being right Ends do not justify means Teleological theories Good before right Something is right only if it maximizes the good Ends justify means Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Deontological Theories Constraints Negatively formulated Narrowly framed E.g., lying is not not-telling-the-truth Narrowly directed at the agent’s specific action Not its occurrence by other means Not the consequences that are not explicitly chosen, i.e., only applies on consequences that are explicitly identified Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Double Effect Deontological theories distinguish intentional effects from foreseen consequences An action is not wrong unless the agent explicitly intends for it to do wrong Legitimizes inaction even when inaction has predictable (but unintended) effects Shut down bank ATM for diagnostics even if that might leave someone without cash Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Kant’s Categorical Imperative Whatever maxim an agent uses must be universalizable, i.e., in the society of agents Respect for others (no lying or coercion) so they can consent False promising is unacceptable, because if everyone did so, society would not function Agents’ maxims are uncertainly inferred from their actions Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Teleological Theories Based on how actions satisfy various goals, not their intrinsic rightness Comparison-based Preference-based Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Consequentialism An agent should promote whatever values it adopts Actions are instrumental in the promotion Honor the values only if doing so promotes them Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Utilitarianism This is the view that a moral action is one that is useful Must be good for someone Good may be interpreted as Pleasure: hedonism Preference satisfaction: microeconomic rationalism (assumes each agent knows its preferences) Interest satisfaction: welfare utilitarianism Aesthetic ideals: ideal utilitarianism Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Prima Facie Duties What agents need to decide actions are Not just universal principles (each can be stretched) Not just consequences But also a regard for their promises and duties Agents have prima facie duties to help others, keep promises, repay kindness,... No ranking among these Highly defeasible conclusions, e.g., steal to feed kids Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Obligations Obligations are For deontological theories, those that are impermissible to omit For teleological theories, those that most promote good For contract-based theories, those that an agent accepts Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Asimov’s Laws of Robotics 0. A robot may not injure humanity or, through inaction, allow humanity to come to harm. [Added after the following more famous laws] 1. A robot may not injure a human being, or, through inaction, allow a human being to come to harm. 2. A robot must obey the orders given it by human beings except where such orders would conflict with the First Law. 3. A robot must protect its own existence as long as such protection does not conflict with the First or Second Law. Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Applying Ethics: 1 The ethical theories are theories Of justification Not of deliberation An agent can decide what basic “value system” to use under any approach Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Applying Ethics: 2 The deontological theories (“right”) Are narrower Ignore practical consideration But are only meant as incomplete constraints (out of all the right actions, the agent can choose any) The teleological theories (“good”) Are broader Include practical considerations But leave fewer options for the agent, who must always choose the best available alternative Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Applying Ethics: 3 The ethical approaches Are single-agent in orientation Implicitly encode other agents An explicitly multiagent ethics would be an interesting topic for study Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 An Agent Should Act Benevolently Seeking the welfare of others Rationally, i.e., maximizing utility Consistent with its model of itself (including its desires and capabilities) Predictably Consistent with its model of other agents’ beliefs about itself Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Benevolence: “A Mattress in the Road” Who will stop to pick it up? Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Information System Example: A Collective Store Benevolent agents might contribute information they have retrieved, filtered, and refined to a collective store Utilitarian variant: Access to the collective store is predicated on contributions to it Collective Store World Wide Web... Query Agents Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Challenges and Recommendations Respect autonomy and heterogeneity Design rules for various levels: ontologies, transactions, protocols, organizations, … Security and trust: difficult given openness Scalability Quality of service understood to include user needs and application specifics User-centered requirements analysis and design to capture key functionality in a manner that works in multiple settings Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 To Probe Further IEEE Internet Computing, http://computer.org/internet DAI-List-Request@engr.sc.edu (International Joint Conference and Journal) Autonomous Agents and Multiagent Systems Journal of Web Semantics Intl. Semantic Web Conference (ISWC) Intl. Conf. on Service-Oriented Computing (ICSOC) Intl. Conf. on Web Services (ICWS) World-Wide Web Conference Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns

Service-Oriented Computing: Semantics, Processes, Agents August 2004 Chapter 25 Summary SOC improves our effectiveness in building large-scale systems in open environments Because of openness, SOC systems rely upon trust among components and in dealing with people SOC technologies support aspects of trust: progressing, but not solved Concepts from human ethics can inspire abstractions for designing SOC systems Ethics can help make SOC systems manageable and responsive to human needs Chapter 25 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns © Singh & Huhns