1 / 25

Linked-USDL: Enabling a Coherent and Transparent Service Marketplace

This webinar discusses the importance of a common description language for services and apps in the FI-WARE Applications and Services Ecosystem. It explores the use of Linked-USDL to create a marketplace for highly specialized services, with a focus on logistics and cloud services.

wharding
Download Presentation

Linked-USDL: Enabling a Coherent and Transparent Service Marketplace

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. FI-WARE Applications and Services Ecosystem SAP Research 1stWebinar Session on Registry, Torsten Leidig, Repository, andMarketplaceMay 28, 2013; June 5, 2013

  2. Service Ecosystem • Highlyspecializedservices • Collaborative servicevaluechain • Outsourcing, Cloud Computing Weneed a platformforthe Service Ecosystem! • Core enablers • Open standardizedinterfaces • Uniform Service Description Language

  3. Unified Service Description • Service Provider • Agents • Price plans • Service levels • Availability • Licenses • Functionality • Dependencies • Interaction • Composition • Resources Technical Business Operational USDL • Interface • Protocol • Parameters • Infrastructure

  4. Linked USDL Rationale • Common description language for services and apps is needed • Low entry barrier to allow easy onboarding • Relying on existing standards as much as possible • Extensible according to domain and life-cycle aspect • Link linking information across the service/app life cycle • http://Linked-usdl.org • https://github.com/linked-usdl

  5. USDL roadmap Use Case: Logistics Logistic services problems • No common scheme for transportation services • Planning of routes with many legs is cumbersome • Main criteria are price, reliability and time • Hard to find transport options if plan must be changed on the fly • Vast amount of transport options is inaccessible • Phone calls, paper work A spot market and planning tool based on Linked-USDL logistic service descriptions would have an enormous effect.

  6. Service Description

  7. Example: Cloud Services • Problems • Countless offerings in the wild • No coherent description of services available • No common marketplace • Comparison of offerings (price, SLA, capabilities, …) is very difficult for users • Linked-USDL can help to put light into the dark and make Cloud offerings more transparent to the consumer!

  8. Examination of IaaS Offerings • CPU Power, Memory and Storage • IP Addresses and I/O Performance • Data Recovery • Availability and Service Level Agreements • Cedit system • Legal issues • Support services • Third parties involved

  9. How to express in Linked-USDL Generic USDL vocabularies: • usdl-core • usdl-sla • usdl-price ComplementingdomainspecificCloudvocabularies • cloudvocabularytaxonomy, specific qualitative and quantitative non-functionalproperties • operatingsystemtaxonomy • supportvocabulary

  10. Example service <#service_IaaS> a usdl:Service ; dcterms:modified "2012-05-07"^^xsd:date ; dcterms:created "2012-04-17"^^xsd:date ; dcterms:title "Iaas demo service"@en ; dcterms:abstract "An IaaS demo service."@en ; dcterms:description "This a service demo description for an IaaS service."@en ;usdl:hasProvider :entity_IaaSDemoProvider ;usdl:hasLegalCondition<#terms_IaaS> ;usdl:hasPartMandatory<#service_Support> ; cloud:hasCPUPower [ gr:hasUnitOfMeasurement "A86" ; # gigahertz gr:hasValue "1.5" ; gr;valueReference [ a cloud:numberOfCores ; gr:hasValue "2" ]] ; cloud:hasAmountOfDiskStorage [ gr:hasUnitOfMeasurement "E34" ; # gigabyte gr:hasValue "30" ] ; cloud:hasAmountOfMainMemory [ gr:hasUnitOfMeasurement "4L" ; # megabyte gr:hasValue "1250" ] ; cloud:hasUpstreamCapacity [ gr:hasValue "32" ; gr:hasMinValue "6" ; gr:hasUnitOfMeasurement "D36" ] . # megabit

  11. High Level Architecture

  12. Repository Generic Enablers

  13. Repository: Rationale Storing service descriptions and associated resources Used by other components (marketplace, composition editor, …) Distributed storage (Linked Data) Defined by Open Specification based on HTTP Different implementations possible Authentication (IDMaaS) Etag handling to ensure consistency

  14. Repository: Data Model The Repository is structured into Resources and Collections Collection: Transport Collection: Packing Collection: Insurance

  15. Repository Principles „How to publish Linked Data on the Web“by Chriz Bizer et al Respect Web Architecture principles A resource is identified by its „dereferencable“ URL Information resources (200 ok) Non-information resources (303 see other) HTTP GET should deliver meaningful information Content negotiation (RDF, N3, HTML, JSON, …) Use of resolvers like PURL (30x redirect) Easily crawled by search engines Accessed using generic data browsers Enabling linkes between data from different sources

  16. Repository: Data Model and Operations Collections Identified by path e.g. /logistics/services/transport/ Resources Indentified by URI! E.g. /logistics/services/transport/service4711 Service descriptions Any kind of media type Operations Read, write, delete, list (Extensions: search)

  17. Registry Generic Enablers

  18. Registry: Rationale Used to store information on instance level(entries describing instances and their parameters) Somehow equivalent to directory services (e.g. LDAP) Is just an protocol specification, which is agnostic according the implementation (database, distribution) Our implementation is based on MongoDB

  19. Registry: Data Model and Operations Register key Identifiedby (directory) path e.g. /provider/transport/ Register entry Indentifiedby URI, e.g. /provider/transport/dhl Isrepresentedby a setofkey/valuepairs (JSON object) Operations Read, write, delete, list Filteringandattributeselection via queryparameters

  20. Marketplace Generic Enablers

  21. Marketplace • Availableasplatformservices • Matchingofferinganddemand • Negotiationofdeliveryconstraints • Service bundlesandcompositions • Service configuration • Business modelsupport Clerk Community USDL Repository Enterprise Infrastructure Mobile Infrastructure Partner Infrastructure

  22. Marketplace – Architecture

  23. Marketplace – Core Components • Registry and Directory • holds information of registered stores, participants and their role • takes care of registering, updating, and deleting information about market relevant entities. • Offering & Demand • responsible for exchanging service offerings with stores and version handling/archiving of out-dated offerings. • Discovery & Matching • is about discovering and matching offering and demand

  24. Marketplace – Core Components • Recommendation • provides the user service recommendations based on the users’ profile and context • Review & Rating • allows users of the marketplace to give textual and star-rating feedback for services and stores along predefined categories • Reviews of users and their overall rating about applications and services can be used to improve the quality of recommendations

More Related