E-Services and Transactions in Semantic Web Vagan Terziyan MIT Department, University of Jyvaskyla / / AI Department, Kharkov National University of Radioelectronics vagan@it. jyu. fi http: //www. cs. jyu. fi/ai/vagan +358 14 260 -4618
Managing Transactions with Distributed Web-Services and providing Integrated Service to a User - are among the basic abilities of an Intelligent Agent
Contents 4 Transactions with Mobile services in Semantic Web 4 Agent-Based Service Integration
Transaction with Mobile Services in Semantic Web Vagan Terziyan University of Jyvaskyla, Finland e-mail: vagan@it. jyu. fi
Transactions in Databases 4 A transaction is a sequence of database actions which must either all be done, or none of them must be done 4 Another view of a transaction is that it is an action, or sequence of actions, that takes the database from one consistent state to another
M-commerce transaction: Any type of transaction of an economic value having at least at one end a mobile terminal and thus using the telecommunications network for communication with the e-commerce infrastructure Mobile e-commerce based on m-commerce transactions =
Basic (ACID) Transactional Properties 4 Atomicity 4 Consistency 4 Isolation 4 Durability
Atomicity 4 Transaction is atomic if either all operations necessary for preserving e-commerce atomicity are executed or all executed operations will become compensated. 4 With money atomic protocols, funds are transferred from one party to another without the possibility of the money remaining in the middle. 4 Goods-atomic protocols are such that a good is received if and only if the money is transferred. 4 Certified delivery protocols allow both a merchant and a customer to prove exactly which goods were delivered.
Consistency Transactions must preserve consistency at various levels. For instance, a customer should not be allowed to draw funds from an account if this would result into a negative balance.
Isolation means that various steps of a transaction do not interfere with steps of other transactions.
Durability means that once a transaction completes its execution, its results become permanent even in the presence of failures. Committed by a transaction data is saved by the system such that, even in the event of a failure and system restart, the data is available in its correct state.
Server-Side Transaction Monitor Web resource / service Server Client wireless TM Transaction Service Web resource / service Server
Server-Side Transaction Monitor Positive (1) Less wireless (sub)transactions Web resource / service Server Client wireless ! TM Transaction Service Web resource / service Server
Server-Side Transaction Monitor Positive (2) Rich ontological support Web resource / service Server Rich ontology of resources, services, other metadata TM Transaction Service Client wireless Web resource / service Server
Server-Side Transaction Monitor Positive (3) Smaller crash, disconnection vulnerability Web resource / service Server TM Transaction Service OK ! Client wireless Web resource / service Server
Server-Side Transaction Monitor Negative (1) Pure customer’s trust Web resource / service Server Customer’s private data TM Transaction Service Client wireless Web resource / service Server
Server-Side Transaction Monitor Negative (2) Lack of customer’s awareness and control Web resource / service Server Transaction online control Client Transaction data TM Transaction Service wireless Web resource / service Server
Server-Side Transaction Monitor Negative (3) Problematic TM’s adaptation to the customer Web resource / service Server Client Public TM TM Transaction Service wireless Web resource / service Server
Example: Server-based transactions for location based application 4 Positioning Service Application Server 6 5 3 10 Client 1 12 9 2 11 7 8 Content providers
Client-Side Transaction Monitor Web resource / service TM wireless Client Server wireless Web resource / service Server
Client-Side Transaction Monitor. Positive (1) Customer’s firm trust Web resource / service TM wireless Client Server wireless Web resource / service Server Customer’s private data
Client-Side Transaction Monitor. Positive (2) Customer’s awareness and involvement Web resource / service TM wireless Client Server wireless Web resource / service Server Transaction online control Transaction data
Client-Side Transaction Monitor. Positive (3) Better TM’s adaptation to the customer Web resource / service TM wireless Client Server wireless Web resource / service Server Personal TM
Client-Side Transaction Monitor. Negative (1) More wireless (sub)transactions TM Web resource / service wireless Client Server wireless ! Web resource / service Server
Client-Side Transaction Monitor. Negative (2) Restricted ontological support Web resource / service TM wireless Client Server wireless Web resource / service Server Restricted ontology of resources, services, other metadata
Client-Side Transaction Monitor. Negative (3) High crash, disconnection vulnerability Web resource / service TM wireless Client Server wireless Web resource / service Server
Terminology 4 e-Service = Web-Service, which assumes also an online payment; 4 e-Service is a Web-Service in e- Commerce
Ontology-Based Client-Side Transaction Monitor 4 This design is based on assumption that TM is an independent mobile terminal application, which can integrate different distributed external e-services by managing appropriate transactional processes. For that the ontology-based framework for transaction management is used so that the Transaction Monitor will be able to manage transaction across multiple e-services.
The conceptual scheme of the ontology-based transaction management
Basic definitions: Action Let an action be a single client-server query-response session between the mobile terminal (hereinafter - terminal) and the e-service provider (hereinafter - service), which has following structure: - action’s ID; - Ids of p input parameters for the action, specified at the terminal to create a query; - Ids of q output parameters of the action, which the terminal receives as the result to its query.
Basic definitions: Subtransaction is a vector of one or more actions between a terminal and the service and appropriate states managed by the service with definitely stated final goal and common memory of parameters.
Basic definitions: Transaction is a vector of one or more subtransactions with the same terminal and possibly different services managed by the terminal, with definitely stated final goal and common memory of parameters. .
Service Tree Service tree is a tree-like structure of the set of subtransactions, which a service can offer to his clients and which is used by a service to manage subtransactions with clients. Action of interest, toned for every subtransaction in the service tree is such an action, which outcome is in particular interest of a customer and has an economic value. Service tree as a collection of subtransactions offered by the Service to its customers. In the rectangles together with the Id of an action there is also Id of a state, into which a subtransaction is coming after performing this action
Constants and Ontologies 4 basic constants, which define Ids of the terminal and services used, basic screens for the interface, total numbers of services, actions and parameters, which Transaction Monitor is operating with; 4 service atomic actions ontologies define basic actions with their input and output, from which every service can be composed, and which are used as a common procedural language between a client and a service (include always LOGIN and LOGOUT actions ontologies); 4 parameter ontologies describe parameters, which can be used in actions, by providing their Ids, default values and types (or schemas), and which are actually a common declarative language between a client and a service.
Basic constants
Ontologies
Variables 4 control variables have sense only for a Transaction Monitor and are used to manage different states of the terminal during going-on transactions, subtransactions and actions; 4 working variables are used to manage parameters' states and provide common memory for different subtransactions, which can be run with different services; 4 billing variables are used to manage billing data in the Transaction Monitor. The terminal will collect bills separately for every service adding online price for appropriate service actions to it, when it is requested.
Service Actions service query service response
An Example of Action
An Example of Action
LBS example: ontology for the LOCATE_BY_ID action
LBS example: ontology for the LOCATE_BY_ADDRESS action
LBS example: ontology for the GET_MAP action
LBS example: ontology for the GET_INFO action
LBS example: service tree for the Positioning Service
LBS example: service tree for the Location Based Service
LBS example: Case when a user locates himself and submits coordinates to LBS
<Query_ID="01 -03 -2002_12: 33: 57" Type="Service" To_Service="Positioning_Service" From_Terminal="0501234567" Terminal_State="S 0" > <Action ID="LOGIN"/> <Input_Parameters> <Parameter ID="user_ID” Type="text” Value="vagan"/> <Parameter ID="password” Type="text” Value="4321"/> </Input_Parameters> </Query> “Login” Query Terminal Positioning Service
<Response_ID="01 -03 -2002_12: 34: 42” Type="Service” To_Query="01 -03 -2002_12: 33: 57” To_Terminal="0501234567” From_Service="Positioning_Service” Terminal_State="S 1" > <Action ID="LOGIN"/> <Output_Parameters> <Parameter ID="login_reply” Type="binary” </Output_Parameters> <Price_for_Action Value="OK"/> Currency="EURO" Value="0. 0"/> <Bill_Recent_Value Currency="EURO" Value="0. 0"/> <Actions_Allowed> <Action ID="LOGOUT"/> <Action ID="LOCATE_BY_ID"/> <Action ID="LOCATE_BY_ADDRESS"/> </Actions_Allowed > </Response> “Login” Response Terminal Positioning Service
<Query_ID="01 -03 -2002_12: 34: 53" Type="Service" To_Service="Positioning_Service" From_Terminal="0501234567" Terminal_State="S 1" > <Action ID="LOCATE_BY_ADDRESS"/> <Input_Parameters> <Parameter ID="street_number” Type="integer” Value="43"/> <Parameter ID="street_name” Type="text” Value="Nokatu"/> <Parameter ID="city_name" Type="text” Value="Jyvaskyla"/> <Parameter ID="country_name” Type="text” Value="Finland"/> </Input_Parameters> </Query> “Locate by Address” Query Terminal Positioning Service
<Response_ID= "01 -03 -2002_12: 35: 14” Type= "Service" To_Query= "01 -03 -2002_12: 34: 53” To_Terminal= "0501234567" From_Service= "Positioning_Service” Terminal_State= "S 1" > <Action ID="LOCATE_BY_ADDRESS"/> <Output_Parameters> <Parameter ID="latitude" Type="integer" Value="54321"/> <Parameter ID="longitude" Type="integer" Value="98765"/> </Output_Parameters> <Price_for_Action Currency="EURO" Value="0. 23"/> <Bill_Recent_Value Currency="EURO" Value="0. 23"/> <Actions_Allowed> <Action ID="LOGOUT"/> <Action ID="LOCATE_BY_ID"/> <Action ID="LOCATE_BY_ADDRESS"/> </Actions_Allowed > </Response> “Locate by Address” Response Terminal Positioning Service
<Query_ID="01 -03 -2002_12: 35: 20" Type="Service" To_Service="Positioning_Service" From_Terminal="0501234567" Terminal_State="S 1" > <Action ID="LOGOUT"/> <Input_Parameters> <Parameter ID="user_ID” Type="text” Value="vagan"/> </Input_Parameters> </Query> “Logout” Query Terminal Positioning Service
<Response_ID= "01 -03 -2002_12: 35: 25” Type= "Service" To_Query= "01 -03 -2002_12: 35: 20” To_Terminal= "0501234567" From_Service= "Positioning_Service” Terminal_State= "S 0" > <Action ID="LOGOUT"/> <Output_Parameters> <Parameter ID="logout_reply” </Output_Parameters> Type="binary” Value="OK"/> <Price_for_Action Currency="EURO" Value="0. 0"/> <Bill_Recent_Value Currency="EURO" Value="0. 23"/> <Actions_Allowed> <Action ID="LOGIN"/> </Actions_Allowed > </Response> “Logout” Response Terminal Positioning Service
<Query_ID="01 -03 -2002_12: 35: 47" Type="Service" To_Service="Location_Based_Service" From_Terminal="0501234567" Terminal_State="S 0" > <Action ID="LOGIN"/> <Input_Parameters> <Parameter ID="user_ID” Type="text” Value="vagan"/> <Parameter ID="password” Type="text" Value="1234"/> </Input_Parameters> </Query> “Login” Query Terminal Location-Based Service
<Response_ID= "01 -03 -2002_12: 36: 01” Type= To_Query= "01 -03 -2002_12: 35: 47” To_Terminal= From_Service="Location_Based_Service” Terminal_State= > <Action ID="LOGIN"/> <Output_Parameters> <Parameter ID="login_reply” Type="binary" </Output_Parameters> "Service" "0501234567" "S 1" Value="OK"/> <Price_for_Action Currency="USD" Value="0. 0"/> <Bill_Recent_Value Currency="USD" Value="0. 0"/> <Actions_Allowed> <Action ID="LOGOUT"/> <Action ID="GET_MAP"/> </Actions_Allowed > </Response> “Login” Response Terminal Location-Based Service
<Query_ID="01 -03 -2002_12: 39: 07" Type="Service" To_Service="Location_Based_Service" From_Terminal="0501234567" Terminal_State="S 1" > <Action ID="GET_MAP"/> <Input_Parameters> <Parameter ID= "latitude” Type= "integer” Value="54321"/> <Parameter ID= "longitude” Type= "integer” Value="98765"/> </Input_Parameters> </Query> “Get Map” Query Terminal Location-Based Service
<Response_ID= "01 -03 -2002_12: 41: 34” Type= "Service" To_Query= "01 -03 -2002_12: 39: 07” To_Terminal= "0501234567" From_Service= "Location_Based_Service” Terminal_State= "S 2" > <Action ID="GET_MAP"/> <Output_Parameters> <Parameter ID= "map” Type= "GML” Value= "GML Data"/> </Output_Parameters> <Price_for_Action Currency="USD" Value="0. 15"/> <Bill_Recent_Value Currency="USD" Value="0. 15"/> <Actions_Allowed> <Action ID="LOGOUT"/> <Action ID="GET_MAP"/> <Action ID="GET_INFO"/> </Actions_Allowed > </Response> “Get Map” Response Terminal Location-Based Service
<Query_ID="01 -03 -2002_12: 50: 12" Type="Service" To_Service="Location_Based_Service" From_Terminal="0501234567" Terminal_State="S 2" > <Action ID="GET_INFO"/> <Input_Parameters> <Parameter ID= "point_of_interest” Type="text” Value="Alba_Hotel"/> </Input_Parameters> </Query> “Get Info” Query Terminal Location-Based Service
<Response_ID= "01 -03 -2002_12: 51: 04” Type= "Service” To_Query= "01 -03 -2002_12: 50: 12" To_Terminal= "0501234567” From_Service= "Location_Based_Service” Terminal_State= "S 2 " > <Action ID="GET_INFO"/> <Output_Parameters> <Parameter ID="point_address" <Parameter ID="point_phone" <Parameter ID="point_info” Type="text" Value="Mattilaniemi A 1"/> Type="text" Value="0509876543"/> Type="text” Value="Rooms available: single (60 EURO), double (80 EURO)"/> </Output_Parameters> <Price_for_Action Currency="USD" Value="0. 10"/> <Bill_Recent_Value Currency="USD" Value="0. 25"/> <Actions_Allowed> <Action ID="LOGOUT"/> <Action ID="GET_MAP"/> <Action ID="GET_INFO"/> </Actions_Allowed > </Response> “Get Info” Response Terminal Location-Based Service
<Query_ID="01 -03 -2002_12: 58: 03" Type="Service" To_Service="Location-Based_Service" From_Terminal="0501234567" Terminal_State="S 2" > <Action ID="LOGOUT"/> <Input_Parameters> <Parameter ID="user_ID” Type="text” Value="vagan"/> </Input_Parameters> </Query> “Logout” Query Terminal Location-Based Service
<Response_ID= "01 -03 -2002_12: 58: 55” Type= "Service" To_Query= "01 -03 -2002_12: 35: 20” To_Terminal= "0501234567" From_Service= "Location_Based_Service” Terminal_State= "S 0" > <Action ID="LOGOUT"/> <Output_Parameters> <Parameter ID="logout_reply" Type="binary" Value="OK"/> </Output_Parameters> <Price_for_Action Currency= ”USD” <Bill_Recent_Value Currency= ”USD” <Actions_Allowed> <Action ID="LOGIN"/> </Actions_Allowed > </Response> Value= "0. 0"/> "0. 25"/> “Logout” Response Terminal Location-Based Service
Atomicity consideration 4 Money atomicity: Money is either entirely transfer or not transfer at all; 4 Goods atomicity: Customer receives the ordered goods if and only if merchant is paid; 4 Distributed Purchase Atomicity: Products bought from different suppliers are either both delivered or none.
Distributed independent purchase case Assume a customer wants to purchase specialised software (SW) from a merchant. In order run this software, he also needs an operating system (OS), which is, however, only available from a different merchant. As both goods individually are of no value for the customer, he needs the guarantee to perform the purchase transaction with the two different merchants atomically in order to get either both products or none.
Distributed sequential purchase case Assume that a customer needs a Map from Service 2 but to apply for that map he is requested to provide his coordinates (CR). Coordinates he can get from Service 1. Assume that Service 1 does not care about how a customer is going to use coordinates delivered - the service has made job and got money for it. Even if the rest of a transaction will fail and for some reason a customer will not get his Map from Service 2, full compensation for the transaction as whole cannot be guaranteed.
Reference Terziyan V. , Ontological Modelling of E-Services to Ensure Appropriate Mobile Transactions, In: International Journal of Intelligent Systems in Accounting, Finance and Management, J. Wiley & Sons, Vol. 11, No. 3, 2002, pp. 159 -172. Available in: http: //www. ingenta. com/isis/searching/Expand/ingenta? pub=infobike: //jws/isaf/2002/00000011/00000003/art 00221
Acknowledgements Information Technology Research Institute (University of Jyvaskyla): Agora Center Customer-oriented research and development in Information Technology Innovations in Business, Communication and Technology Research Project (In. BCT) http: //www. titu. jyu. fi/eindex. html http: //www. jyu. fi/agora/ Multimeetmobile (MMM) Project (2000 -2001): Location-Based Service System and Transaction Management in Mobile Electronic Commerce http: //www. cs. jyu. fi/~mmm (University of Jyvaskyla):
Agent-Based Service Composition Vadim Ermolayev, Natalya Keberle, Sergey Plaksin Zaporozhye State Univ. , Ukraine Int. Conference on Web Services Europe (ICWS-Europe’ 03), Erfurt, Germany, Sept. 23 -25, 200
Semantic Web Services’ Orchestration: the field is becoming increasingly hot p p Several ongoing initiatives define compositional notations for web services E. g. : n p IBM, Microsoft and BEA have released BPEL 4 WS as the specification for coordinating business processes over the Web Such notations express the flow of control and data across a collection of web services whose choreography performs a workflow
…Having a Recipe doesn’t yet Grant Having a Meal… p A pro-active component is required p Pro-active understanding of the process specification is: n n p Not only the ability to ensure the right sequence and the proper combination of the components But also the capability to find the best provider in the dynamic and open environment This is why much attention is paid to the field of agent-enabled web service composition
What should be offered is: p A new understanding of a web service as: n p An agent capability implemented as a self-contained proactive software component and the subject of negotiation and trade It implies the appearance of the rational service providing agent , which demands the negotiable incentive and behaves to increase its utility p E. g. : if a service requested from a travel agency is ‘Book. Roundtrip(‘Kiev’, ‘Erfurt’, 22/09/03, 25/09/03, …)’, the price paid by the requestor will comprise: § the prices of consumable resources (air fare, hotel room, …) § plus the incentive paid to the contracted service provider for ‘Book. Roundtrip’ service usage
What’s behind the scenes … p The agent performing ‘Book. Roundtrip’ service should be able to realize that the requested task is composite and will require RATIONAL cooperation with at least: n n p Air Companies’ service providing agents And hotel booking service providing agents These actors will also intend to increase their own utilities by requesting fees for their service provision
‘Book. Roundtrip’ Scenario Agent roles (played by human actors): p p p AUTHOR (A) – acts on behalf of the one of the paper authors attending ICWS’ 03 -Europe , requests ‘Book. Roundtrip’ service TRAVEL AGENT (T) –provides ‘Book. Roundtrip’ service, generates and conducts corresponding task execution behind the scenes FARE AGENT (F) – provides air fare information and booking services ICWS INFO (I) – provides information services on ICWS’ 03 -Europe: local arrangements, infrastructure, accommodation, etc HOTEL AGENT (H) – provides hotel room reservation services BUSINESS PARTNER (P) – acts on behalf of A’s business partner in Austria with whom A intends to meet in Germany in time of the conference to discuss a joint proposal
‘Book. Roundtrip’ Exercise Inputs p Semi-formally (enough for human actors to understand unambiguously): A Starting_Point= “Kiev, Ukraine” Destination=“Erfurt, Germany” Beg_Date=22/09/2003 End_Date=25/09/2003 Event=“ICWS’ 03 -Europe” Preferences=(“low fare”, “non-stop flights”, “fast connections”, “ 4 -star hotel”, “continental breakfast”, “conference discounts”) Constraints=(Budget = € 1500, Payment=(VISA, USD), Hotel >= 3 -star, Room-per-night <= € 110, Hotel_Location=”in Max 20 min walk from the Conference venue”) Special_Arrangements=((Event=“business dinner”, Agent=(“Prof. Heinrich C. Mayr”, http: //www. ifi. uniklu. ac. at/IWAS/HM/Staff/Heinrich. Mayr/), Date=(23/09/2003, 24/09/2003), Location=(Erfurt, Munich)), …)
What are the parties supposed to do? p Negotiates with T-s about which A believes that they are: n n p p p Capable to provide ‘Book. Roundtrip’ Reliable partners Collects proposals from T-s and selects the best of them Hires the T which has given the best proposal Pays and gets the results A p p p Analyses if A’s inputs allow to accept the job Prepares the proposal based on its previous experience IF hired: n Conducts the performance of ‘Book. Roundtrip’ according to: p p n n Its knowledge about the job Its beliefs about the other service providers which might be involved Provides the best result possible to prove that it is reliable But does it rationally for not to loose its income T
And why do they do it? A desires: p p p Not to go behind the scenes To rely on the T-s competencies To pay a reasonable incentive for that A believes: n n ‘Book. Roundtrip’ is an atomic activity – just a piece of cake ‘Book. Roundtrip’ may be outsourced to T T desires: p p p To be hired and paid for the job To spend the money most efficiently (remain competitive) To remain a reliable partner for A T believes: n ‘Book. Roundtrip’ is a complex, dynamic, composite task
T: ‘Book. Roundtrip’ is a Complex Task p The knowledgebase of T contains facts: Tas k Part_o Activit y a Is_a Is_ a d nd Has. Preco Par of t_ recon f _o rt Pa Part_ of Has. P f Book. Roundtrip is a Task Book Roundtrip n It contains at least Plan. Trip Task and Make. Hotel. Res, Apply. For. Visa, Spec. Arrangements Activities as its phases n Make. Hotel. Res requires Make Plan. Trip results as the Hotel. Res Pre. Condition Plan. Trip n Spec. Arrangements and Apply. For. Visa may be Apply. For. Visa Spec performed concurrently Arrangements with Plan. Trip and Make. Hotel. Res Indiv Part_of here idua Plan. Trip l_of p These facts are formulated is a Phase. Results in the terms of the Task Activity kind of Approved Ontology (namespace meronimy for the compositional Pre. Condition relationship notation) !!! Another T may have a different idea of ‘Book. Round. Trip’ composition n
T: ‘Book. Roundtrip’ – More Facts a Is_ a pa ble Self. Performanc Ind ivi d ua l_o f To Make Hotel. Re s PLP f Individual_o Outsource !!! Another T may have different Capabilities and PLPs wrt ‘Book. Round. Trip’phases Define. Capability Ca PL n Make Hotel. Res Partial Local Plan. Tr ip. PLP Plan. Trip s Ha P n Has. PL P Activit y To n Tasks and Activities have Partial Local Plans (PLP) PLPs among other facts define the Capability to perform an Activity either by itself or by outsourcing it to another agent According to Plan. Trip. PLP T is capable to perform Plan. Trip by itself According to Make. Hotel. Res. PLP T needs to outsource Make. Hotel. Res to another agent (via Contract Net negotiation) Has. PL P ble n Tas k pa The knowledgebase of T contains facts: Ca p Capability
T: behaves pro-actively – Adjusts Inputs p p May significantly lower the cost of the air fare because of the Sunday Rule Discounts Beg_Date of Is<= du al_ n End_Date ivi p Beg_Date=20. 09, End_Date=25. 09 Or Beg_Date=22. 09, End_Date=28. 09 Ind p Ha s. E D Days. O f. AWee k Is_a E. g. , for Plan. Trip the following alternative dates: Plan. Trip Has. BD n Dat e a An intelligent service provider may propose to pro-actively change the Task Inputs in order to get better overall result Is_ p Assertions on Task Inputs will form, e. g. , the initial proposal for End. DOW Air. Fare negotiation Beg. DOW T should undertake it to outsource Inquire. Fares Activity while Sunday. Rule. Dates (Beg_Date, End_Date): performing Plan. Trip Task (End_Date-Beg_Date>6) Or (Beg. DOW>End
T-F-s: Negotiation on Air Fares n n p p p Some F-s are capable to perform Inquire. Fares Some of them are trusted partners 20. 09 -25. 09 22. 09 -28. 09 2500 T starts Contract Net negotiation by declaring Activity Inputs and the Intended 1600 Price 700 F-s invoke Web Services they 450 wrap and respond with … These responses are not 20. 09 satisfactory for T … -25. 09 22. 09 -28. 09 Not available p Erfurt T knows from his knowledgebase that Inquire. Fares 700 should be outsourced T knows from his previous 450 experience that: Not available p
T: yet one more Adjustment 650 p Frankfurt is chosen as the destination point 500 P in s. IA Is Ha Is_ a P Negotiations on 900 Frankfurt and Munich 700 fares result in: s. IA p Erfurt Region Int. Air. Po rt Germa n. City Ha p T has got unsatisfactory responses from F-s T pro-actively tries to alter the destination point to the one close to Erfurt … Is_a p Frankfurt Munich Frankfurt $1014=€ 8921600 $984=€ 865 $1574=€ 1385 € 751 € 681 700 € 602 650 € 609 € 671 500 $513=€ 609 20. 09 -25. 09 22. 09 -28. 09
T: Additional Activity is Required Munich Frankfurt Is _a Bingo! Con n This leads T to incorporate one more Activity to Plan. Trip Task: Book. RWFare … Further on, Die Bahn Web Service provides the result The mechanism seems to be the same as for Inquire. Fares in Is Frankfurt Has. RWConn to Erfurt RW p a Has p Is_ P p s. IA n Ha p Erfurt Region Int. Air. Po rt Germa n. City Has. IAP p …But Frankfurt is not Erfurt So, T needs to explore Frankfurt’s Properties for Connections Luckily, there is an appropriate fact in T-s knowledgebase: Is_a p Erfur t
‘Book. Roundtrip’ Service Composition A Negotia te T F T Negotia Book. Round. Trip Service Providers Middle Layer T $1014=€ 892 900 700 650 500 Cyber Flyer € 609 € 671 $513=€ 609 20. 09 22. 09 -25. 09 -28. 09 A R F A Precond Make. Hotel. Res I Inquire. Event. Info : Apply. Constraints Plan. Trip Apply. Preferences results Adjust. Preferences H are Adjust. Constraints available Book. Hotel. Room. Negotiat Approve. Solution Task Ontology Service Requestor Task Ontology T Event: Plan. Trip te F Plan. Trip Inquire. Fares Allocating Make. Hotel. Res +(Convert. Currencies) Plan. Trip Apply. For. Visa Apply. Constraints Spec. Arrangements Task Apply. Preferences Approve. Solution for self. Adjust. Preferences perfor. Adjust. Constraints mance +(Book. RWFare) Agent Book. Fare Approve. Solution Lufthansa Infoflyway Frankfurt e H CNN Currency Converter Service: $1=€ 0. 88 Die Bahn Booking Service Conference Info Service All-hotels. com Reservation Service Hotel reservation Service (hrs. de) Services
Conclusions: p Agent Middle Layer is required for scalable, intelligent, dynamic service composition p Service Mediator is formed dynamically as the coalition of service providing agents (SPAs) participating in the Task execution p Services are self-contained modular loosely coupled program components wrapped by SPAs
Скачать презентацию E-Services and Transactions in Semantic Web Vagan Terziyan
f4e028a7238819a3b139172303bca106.ppt