Service Representation, Discovery, and Composition for E-Marketplaces

Service Representation, Discovery, and Composition for E-Marketplaces W-J van Heuvel, J. Yang, M.P. Papazoglou Univ. of Tilburg, INFOLAB, The Netherlands

Contents • E-services and E-Marketplaces • Running Example and Issues • Service Representation and SDL • Capability Analysis • Service Composition • State of the Arts

E-services • E-business • E-commerce E-services definition • An e-service is a self-contained internet-application that - conducts a transaction - completes a task, or - solves a problem • and posseses the ability to to engage other e-services to complete its task; • and can be used by people, businesses; • on a pay per use basis

Applications-onTap/ E-services portal E-services Marketplace Search Register Business Scenario:Internet Buying Business Scenario:Internet Selling Select Offer Seller Buyer Front end Front end Buy Sell Receive Transact Cash-in Back officeFinancials & Logistics & HR Back officeFinancials & Logistics & HR ! ULTIMATELY Dynamic Brokering of Services

Travel E-Service Customer Information E-Service Restaurant reservation E-Service Business Model / Workflow Customer Knowledge Product Knowledge Enterprise Airline booking E-Service Value Chain Network Reservation E-Service Hotel booking E-Service Vertical E-services Weather E-Service

Summary of e-service key features • Dynamic Discovery: • can find any resource on the Internet based on its description • Brokering: • provided the match in the background • Composition: • individual services are automatically linked to meet the service request • Mediation: • automatically notifies all associated services of changes/updates

Process Integration for EC (PIEC) framework • Tools and framework for automated service development • Service representation (SDL) • Service discovery • Service combination • Mapping e-services to objectified legacy systems

Running Example Assume that there are several car sell service available on the web, and the entire buying process requires the following four main e-services: • Search for a car and car dealer. • Negotiate about the terms of delivery • Order a car • Delivery and payment

Issues • Service description • The domain model used to describe “what’s about” • The service capability (components) • The access syntax • Service discovery • Semantic relatedness • Capability analysis • Syntactic analysis

The Service Description Language (SDL) Provides a comprehensive description of service semantics: • Service properties: general info., service access info. • Service ontology. • Service cost. • Payment method. • Actors. • Authorization/security/visibility. • Service contents. • Service capability.

Specification of a Request  <request> <from src="http://www.infolab.nl/jian /> <vocabulary name="second hand car dealer" /> <service name="sell car" /> <service name="search car" /> <service name="Negotiate", option="optional" /> <service name="order car" /> <service name="fulfillment" /> <result> $serviceInfo </result> </request>

Specification of the Car Seller  <service name="Car Sell" from src="http://www.cardealer.nl /> <vocabulary name="car dealer" /> <vocabulary name="second hand car" /> <vocabulary name="new car" /> <vocabulary name="car sell" /> ... <address> <street /> <city /> <state /> <postcode /> <country /> </address> <contact> ... </contact> <transport> ... </transport> <transportSecurity> ... </transportSecurity>

Specification of the Car Seller (continued) <contents name="carInformation" > <attributes name="make" /> <attributes name="model" /> <attributes name="year" /> <attributes name="type" /> <attributes name="price" /> <attributes name="description /> </contents> <service name="new_car_sell"> <sub_type> car_sell </type> </service> <service name="second_hand_car_sell" <type> sub_service </type> </service> <service name="search_car"> <type> part_service </type> <option> <input> "make" </input> <output> "carInformation" </output> </option> <option> <input> "type" </input> <output> "carInformation" </output> </option> </service> <service name="Negotiate"> <type> part_service </type> ....... </service>

Specification of the Car Seller <service name="Order_car"> <type> part_service </type> <service name="provide_car_information"> <type> part_service </type> <input> "confirmation_of_purchasing" </input> <output> "carInformation" </output> </service> <service name="provide_contact_information"> <type> part_service </type> <input> "customer_contacts" </input> <output> null </output> </service> <service name="provide_payment_information"> <type> part_service </type> <input> "payment_information" </input> <output> "confirm/reject" </output> </service> <service name="provide_shipment_information"> <type> part_service </type> ... </service> <service name="Fulfillment"> <type> part_service </type> ... </service name> </service>

New_car_Sell Old_Car_Sell Car_Sell Fulfillment Search_Car Order_Car Negotiate Provide_Car_ Information Provide_Contact_ Information Provide_Payment_ Information Provide_Shipment_ Information Service Model

Capability Analysis • Service capability derivation algorithm • Matching and partial matching algorithms to determine • Identical • Part-of • More restrictive • Overlapping • Not relevant

Algorithm for Capability Derivation begin capability(s):={s}; for each p in part(s); capability(s):=capability(s)  p; endfor; for each q in super(s) capability(s):= capability(s)  q; s:=q; for each p in part(s); capability(s):=capability(s)  p; endfor; endfor; end;

Matching Services begin Q: the set of request services; FC: Cost function; Found:=Null; Cost:=Max_cost; For each service s in the registry if capability(s) Q then C:=FC(s); if c<Cost then Found:=s; Cost:=C; end; end; end;

Service Composition Given an use interface description in SDL S0 and a repository of several SDL-descriptions S1…Sn, we want to know which SDL call interface(s) description in the repository fits best to the given SDL description Solution: translate an SDL description to a type-tree.

State of Arts • UDDI, WSDL, E-speak … Limitations? • State of the art service representation languages are not able to • sufficiently capture the semantics of the business domain and the • structure of the service (e.g., the sub-services, the parts of the services); • Business process dynamics are only partially covered by current service • descriptions in terms of operations (capabilities): business dynamics and • policies (constraints) are lacking. Business protocols only have been • treated in cursory manner thus far. • The e-service repository and query language have only been partially • implemented. The current service searching is only based on attribute • (or name) match. More research needs to be conducted to construct a • more advanced repository and searching system. • Service descriptions are not based on a solid type system. This puts • a severe barrier on composing e-services dynamically, as the • conformance of the resulting e-service suite can not be checked at runtime. • E-service searching is only based on attribute match which is not • sufficient enough to deal with partial matches and semantic conflicts.

Conclusion • A framework for service description • Algorithms for service capability analysis and matching • Techniques for describing service composition

Service Representation, Discovery, and Composition for E-Marketplaces