250 likes | 343 Views
FI-WARE Applications and Services Ecosystem SAP Research. 1 st Webinar Session on Registry, Torsten Leidig, Repository, and Marketplace May 28, 2013; June 5, 2013. Service Ecosystem. Highly specialized services Collaborative service value chain Outsourcing, Cloud Computing
E N D
FI-WARE Applications and Services Ecosystem SAP Research 1stWebinar Session on Registry, Torsten Leidig, Repository, andMarketplaceMay 28, 2013; June 5, 2013
Service Ecosystem • Highlyspecializedservices • Collaborative servicevaluechain • Outsourcing, Cloud Computing Weneed a platformforthe Service Ecosystem! • Core enablers • Open standardizedinterfaces • Uniform Service Description Language
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
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
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.
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!
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
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
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
Repository Generic Enablers
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
Repository: Data Model The Repository is structured into Resources and Collections Collection: Transport Collection: Packing Collection: Insurance
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
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)
Registry Generic Enablers
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
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
Marketplace Generic Enablers
Marketplace • Availableasplatformservices • Matchingofferinganddemand • Negotiationofdeliveryconstraints • Service bundlesandcompositions • Service configuration • Business modelsupport Clerk Community USDL Repository Enterprise Infrastructure Mobile Infrastructure Partner Infrastructure
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
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