Agenda

  • Motivation
  • Semantic Web
  • Web Services
  • Semantic Web Services
  • Summary
  • References

Motivation

The traditional Web

Finding relevant information

  • Finding information on the current Web is based on keyword search
  • Keyword search has a limited recall and precision due to:
    • Synonyms
      • e.g. Searching information about “Cars” will ignore Web pages that contain the word “Automobiles” even though the information on these pages could be relevant
    • Homonyms:
      • e.g. Searching information about “Jaguar” will bring up pages containing information about both “Jaguar” (the car brand) and “Jaguar” (the animal) even though the user is interested only in one of them
  • Keyword search has a limited recall and precision due also to:
    • Spelling variants:
      • e.g. “organize” in American English vs. “organise” in British English
    • Spelling mistakes
    • Multiple languages
      • i.e. information about same topics in published on the Web on different languages (English, German, Italian,…)
  • Current search engines provide no means to specify the relation between a resource and a term
    • e.g. sell / buy  

Extracting relevant information

  • One-fit-all automatic solution for extracting information from Web pages is not possible due to different formats, different syntaxes
  • Even from a single Web page is difficult to extract the relevant information
  • Extracting information from current web sites can be done using wrappers

Extracting relevant information

  • The actual extraction of information from web sites is specified using standards such as XSL Transformation (XSLT)
  • Extracted information can be stored as structured data in XML format or databases.
  • However, using wrappers do not really scale because the actual extraction of information depends again on the web site format and layout

Combining and reusing information

  • Tasks often require to combine data on the Web    
    • Searching for the same information in different digital libraries 

    • Information may come from different web sites and needs to be combined

How to improve the current Web?

  • Increasing automatic linking among data
  • Increasing recall and precision in search
  • Increasing automation in data integration
  • Increasing automation in the service life cycle
  • Adding semantics to data and services is the solution!

Semantic Web

Semantic Web (contd')

  • “An extension of the current Web in which information is given well-defined meaning, better enabling computers and people to work in cooperation.”

    Tim Berners-Lee et al., Scientific American, 2001: tinyurl.com/i59p
  • “…allowing the Web to reach its full potential…” with far-reaching consequences
  • “The next generation of the Web”
  • The next generation of the WWW 
  • Information has machine-processable and machine-understandable semantics 
  • Not a separate Web but an augmentation of the current one
  • Ontologies as basic building block
  • Web Data Annotation
    • connecting (syntactic) Web objects, like text chunks, images, … to their semantic notion (e.g., this image is about Innsbruck, Dieter Fensel is a professor)
  • Data Linking on the Web (Web of Data)
    • global networking of knowledge through URI, RDF, and SPARQL (e.g., connecting my calendar with my rss feeds, my pictures, ...)
  • Data Integration over the Web
    • Seamless integration of data based on different conceptual models (e.g., integrating data coming from my two favorite book sellers)

Semantic Web - Ontologies

 


Components of Ontology

Ontologies

  • To make the Semantic Web working we need:

    • Ontology Languages:
      • expressivity 
      • reasoning support 
      • web compliance
    • Ontology Reasoning
      • large scale knowledge handling 
      • fault-tolerant 
      • stable & scalable inference machines
    • Ontology Management Techniques
      • editing and browsing 
      • storage and retrieval 
      • versioning and evolution Support 
    • Ontology Integration Techniques
      • ontology mapping, alignment, merging 
      • semantic interoperability determination 
    • and … Applications

Types of ontologies

 

“Semantic Web Language Layer Cake”

Introduction

Definition

  • “Loosely coupled, reusable software components that encapsulate discrete functionality and are distributed and programmatically accessible over standard Internet protocols”, The Stencil Group
  • Web service applications are encapsulated, loosely coupled Web “components” that can bind dynamically to each other, F. Curbera
  • “Web Services are a new breed of application. They are self-contained, self-describing, modular applications that can be published, located, and invoked across the Web. Web Services perform functions, which can be anything from simple request to complicated business processes”, The IBM Web Services tutorial 
  • Common to all definitions:
    • Components providing functionality
    • Distributed
    • Accessible over the Web

Definition (contd')

 

Definition (contd')

Software Architecture

  • Web Services connect computers and devices with each other using the Internet to exchange data and combine data in new ways.
  • The key to Web Services is on-the-fly software creation through the use of loosely coupled, reusable software components.
  • Software can be delivered and paid for as fluid of services as opposed to packaged products.

Web Services as a new concept for ework and ecommerce

  • Business services can be completely decentralized and distributed over the Internet and accessed by a wide variety of communication devices.
  • The internet will become a global common platform where organizations and individuals communicate among each other to carry out various commercial activities and to provide value-added services.
  • The dynamic enterprise and dynamic value chains become achievable and may be even mandatory for competitive advantage.

Web Services as a programming technology

  • Web Services are Remote Procedure Calls (RPC) over HTTP


Web Service vs. Service

  • Service
    • A provision of value in some domain (not necessarily monetary, independent of how service provider and requestor interact)
  • Web Service
    • Computational entity accessible over the Internet (using Web Service Standards & Protocols), provides access to (concrete) services for the clients.

Introduction

WSDL

  • Web Service Description Language describes interface for consuming a Web Service Interface:
    • operations (in- & output) 
    • Access (protocol binding)
    • Endpoint (location of service)

SOAP

  • Simple Object Access Protocol 
  • W3C Recommendation 
  • XML data transport:
    • sender / receiver
    • protocol binding
    • communication aspects
    • content 

UDDI

  • Universal Description, Discovery, and Integration Protocol 
  • OASIS driven standardization effort
  • Registry for Web Services:
    • provider 
    • service information
    • technical access

Restful Services

  • Another way of realizing services, other then SOAP/WSDL/UDDI approach
  • Follows the Web principles (REST principles)
  • Services expose their data and functionality through resources indentified by URI 
  • Services are Web pages that are meant to be consumed by an autonomous program
  • Uniform interfaces for interaction: GET, PUT, DELETE, POST
  • HTTP as the application protocol

Google – Unified Cloud Computing

  • An attempt to create an open and standardized cloud interface for the unification of various cloud API’s
  • Key drivers of the unified cloud interface is to create an api about other API's 
  • Use of the resource description framework (RDF) to describe a semantic cloud data model (taxonomy & ontology)

Amazon - Mechanical Turk

“People as a service”

  • Amazon Mechanical Turk
    • An API to Human Processing 
    • Power
    • The Computer Calls People
    • An Internet Scale Workforce
    • Game-Changing Economics

Amazon – S3 & EC2

“Infrastructure as a service”

 
  • Amazon Simple Storage Service (S3)
    • Write and read objects up to 5GB
    • 15 cents GB / month to store
    • 20 cents GB / month to transfer
  • Amazon Elastic Compute Cloud (EC2)
    • allows customers to rent computers
      on which to run their own computer
      applications
    • virtual server technology
    • 10 cents / hour

 

Introduction

Deficiencies of WS Technology

Deficiencies of WS Technology (contd')

  • current technologies allow usage of Web Services
  • but:
    • only syntactical information descriptions 
    • syntactic support for discovery, composition and execution
    • => Web Service usability, usage, and integration needs to be inspected manually 
    • no semantically marked up content / services
    • no support for the Semantic Web 
  • current Web Service Technology Stack failed to realize the promise of Web Services

So what is needed?

  • Mechanized support is needed for
    • Annotating/designing services and the data they use
    • Finding and comparing service providers
    • Negotiating and contracting services
    • Composing, enacting, and monitoring services
    • Dealing with numerous and heterogeneous data formats, protocols and processes, i.e. mediation
  • => Conceptual Models, Formal Languages, Execution Environments

Definition

Semantic Web Technology

  • allow machine supported data interpretation
  • ontologies as data model

+

Web Service Technology

  • automated discovery, selection, composition, and web-based execution of services

=> Semantic Web Services as integrated solution for realizing the vision of the next generation of the Web 

  • define exhaustive description frameworks for describing Web Services and related aspects (Web Service Description Ontologies) 
  • support ontologies as underlying data model to allow machine supported data interpretation (Semantic Web aspect)

Definition (contd')

  • define semantically driven technologies for automation of the Web Service usage process (Web Service aspect)
  • Tasks to be automated:
     

Definition (contd')

  • Semantic Web Services are a layer on top of existing Web service technologies and do not aim to replace them
  • Provide a formal description of services, while still being compliant with existing and emerging technologies
  • Distinguish between a Web service (computational entity) and a service (value provided by invocation)
  • Make Web services easier to: 
    • Find
    • Compare
    • Compose 
    • Invoke

Semantic Web Services benefits

  • Brings the benefits of Semantics to the executable part of the Web 
    • Ontologies as data model 
    • Unambiguous definition of service functionality and external interface
  • Reduce human effort in integrating services in SOA 
    • Many tasks in the process of using Web services can be automated
  • Improve dynamism 
    • New services available for use as they appear
    • Service Producers and Consumers don’t need to know of each others existence 
  • Improve stability
    • Service interfaces are not tightly integrated so even less impact from changes 
    • Services can be easily replaced if they are no longer available
    • Failover possibilities are limited only by the number of available services

Service Oriented Architecture

Semantically Enabled SOA (SESA)

SESA Architecture


SESA functionality

  • Middleware for Semantic Web Services
    • Allows service providers to focus on their business,
  • Environment for goal based discovery and invocation
    • Run-time binding of service requesters and providers,
  • Provide a flexible Service Oriented Architecture
    • Add, update, remove components at run-time as needed,
  • Keep open-source to encourage participation
    • Developers are free to use in their own code, and
  • Define formal execution semantics
    • Unambiguous model of system behavior.

Realizing Semantic Web Services Vision

  • Take the WSDL/SOAP web service stack as a starting point and add semantic annotations.

Realizing Semantic Web Services Vision (contd')

  • Alternative way to realize Semantic Web Services vision is to focus on further developing the Semantic Web.

Motivation

  • Are WSDL/SOAP web services really web services? - No!
  • Web services require tight coupling of the applications they integrate. 
    • Applications communicate via message exchange requiring strong coupling in terms of reference and time. 
  • The Web is strongly based on the opposite principles. Information is published in a persistent and widely accessible manner. 
    • Any other application can access this information at any point in time without having to request the publishing process to directly refer to it as a receiver of its information. 
  • Web services can use the Web as a transport media, however that is all they have in common with the Web.
  • Distributed systems dominated by messaging
    • Web services / SOAP
    • CORBA / RPC / RMI / MOM
    • Agents
  • Web architecture different
    • Persistent publication as the main principle
    • Uniform interface
    • Uniform addressing
  • Web clearly scales to a large size

Space-based Communication

Semantic Spaces

  • Persistent publication of semantic data
  • Retrieval by semantic matching
  • Mediation of data between heterogeneous services
  • Semantics-aware distribution of data
  • Coordination of concurrent access situations
  • Appropriate security and trust mechanisms
  • Use of Web service protocol stack and Semantic Web technologies

LOD Cloud March 2009

  • Linked Data 

Data Linking on the Web

  • Linked Open Data statistics:
    • data sets: 121
    • total number of triples: 13.112.409.691
    • total number of links between data sets: 142.605.717

Data linking on the Web principles

  • Use URIs as names for things
    • anything, not just documents
    • you are not your homepage
    • information resources and non-information resources
  • Use HTTP URIs
    • globally unique names, distributed ownership
    • allows people to look up those names
  • Provide useful information in RDF
    • when someone looks up a URI
  • Include RDF links to other URIs
    • to enable discovery of related information

DBpedia

  • DBpedia is a community effort to:
    • Extract structured information from Wikipedia
    • Make the information available on the Web under an open license
    • Interlink the DBpedia dataset with other open datasets on the Web
  • DBpedia is one of the central interlinking-hubs of the emerging Web of Data

The DBpedia Dataset

  • 91 languages
  • Data about 2.9 million “things”. Includes for example:
    • 282.000 persons
    • 339.000 places
    • 119.00 organizations
    • 130.000 species
    • 88.000 music albums
    • 44.000 films
    • 19.000 books
  • Altogether 479 million pieces of information (RDF triples)
    • 807.000 links to images
    • 3.840.000 links to external web pages
    • 4.878.100 data links into external RDF datasets

LinkedCT

  • LinkedCT is the Linked Data version of ClinicalTrials.org containing data about clinical trials.
  • Total number of triples: 
    • 6,998,851
  • Number of Trials:
    • 61,920
  • RDF links to other data sources:
    • 177,975
  • Links to other datasets:
    • DBpedia and YAGO(from intervention and conditions) 
    • GeoNames (from locations) 
    • Bio2RDF.org's PubMed (from references)

Summary

  • Why Semantic Web Services?
    • To overcome limitations of traditional Web-Services Technology by integrating it with Semantic Technology;
    • To enable automatic and personalized service discovery;
    • To enable automatic service invocation and execution monitoring;
    • To enable automatic service integration;
    • To enable semantic mediation of Web-Services.
  • Two new sciences are currently emerging: Web science and Service Science. 
  • Core pillar of these sciences are:
  • Semantic Web
    • the next generation of the Web in which information has machine-processable and machine-understandable semantics.
  • Semantic Web Services
    • overcome limitations of traditional Web-Services Technology using Semantic Technology to enable automatic service discovery, ranking, selection, composition, etc.

References

  • D. Fensel, M. Kerrigan, and M. Zaremba (eds.). Implementing Semantic Web Services - The SESA Framework, Springer, 2008. ISBN: 978-3-540-77019-0
  • D. Fensel, C. Bussler. The Web Service Modeling Framework WSMF, Electronic Commerce Research and Applications, 1(2): 113-137, 2002 
  • D. Fensel: Triple-space computing: Semantic Web Services based on persistent publication of information. In Proc. of the IFIP Int'l Conf. on Intelligence in Communication Systems (INTELLCOMM 2004), Bangkok, Thailand, November 23-26, 2004.
  • L. Richardson, and S. Ruby. Web services for the real world, O’Reilly, 2007. ISBN 10: 0-596-52926-0
  • SOAP: http://w3.org/TR/soap12
  • WSDL: http://w3.org/TR/wsdl20
  • UDDI: http://uddi.xml.org/
  • http://dbpedia.org/About
  • http://en.wikipedia.org/wiki/Semantic_Web_Services
  • http://en.wikipedia.org/wiki/Service_(systems_architecture)
  • http://en.wikipedia.org/wiki/Webservice
  • http://en.wikipedia.org/wiki/Service-oriented_architecture
  • http://en.wikipedia.org/wiki/Web_Services_Description_Language
  • http://en.wikipedia.org/wiki/SOAP
  • http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration
  • http://en.wikipedia.org/wiki/Cloud_computing
  • http://en.wikipedia.org/wiki/Amazon_Elastic_Compute_Cloud
  • http://en.wikipedia.org/wiki/Amazon_Mechanical_Turk
 

The Web today


Agenda

  • Motivation
  • Web Science
  • Web Evolution
    • Web 1.0 - Traditional Web
    • Web 2.0
      • Major breakthroughs of Web 2.0
    • Web 3.0 - Semantic Web
  • What Web Science could be
    • The computer science of 21st century
  • Summary
  • References

Motivation

  • “[…] As the Web has grown in complexity and the number and types of interactions that take place have ballooned, it remains the case that we know more about some complex natural phenomena (the obvious example is the human genome) than we do about this particular engineered one.”
  • A new science that studies the complex phenomena called Web is needed!!

Web Science

  • A new science that focuses on how huge decentralized Web systems work. 
  • “The Web isn’t about what you can do with computers. It’s people and, yes, they are connected by computers. But computer science, as the study of what happens in a computer, doesn’t tell you about what happens on the Web.” 
    Tim Berners-Lee
  • “A new field of science that involves a multi-disciplinary study and inquiry for the understanding of the Web and its relationships to us”
    Bebo White, SLAC, Stanford University
  • Shift from how a single computer works to how huge decentralized Web systems work

Endorsements for Web Science

  • “Web science represents a pretty big next step in the evolution of information. This kind of research likely to have a lot of influence on the next generation of researchers, scientists and, most importantly, the next generation of entrepreneurs who will build new companies from this.” 
    Eric E. Schmidt, CEO Google
  • “Web science research is a prerequisite to designing and building the kinds of complex, human-oriented systems that we are after in services science.” 
    Irving Wladawsky-Berger, IBM

Web Science – multi-disciplinary approach

The goals of Web Science

  • To understand what the Web is
  • To engineer the Web’s future and providing infrastructure
  • To ensure the Web’s social benefit

Scientific method

  • Natural Sciences such as physics, chemistry, etc. are analytic disciplines that aim to find laws that generate or explain observed phenomena
  • Computer Science on the other hand is synthetic. It is about creating formalisms and algorithms in order to support particular desired behaviour.
  • Web science scientific method has to be a combination of these two paradigms

What Could Scientific Theories for the Web Look Like?

  • Some simple examples:
    • Every page on the Web can be reached by following less than 10 links
    • The average number of words per search query is greater than 3
    • Web page download times follow a lognormal distribution function (Huberman)
    • The Web is a “scale-free” graph
  • Can these statements be easily validated? Are they good theories? What constitutes good theories about the Web?

Food for thought

           

  • What are the analogies for Web Science and Design? Is our understanding of the Web like that of 1800 electricity?

Evolution of the Web

Introduction

  • Web evolution
    • Web 1.0 - Traditional Web
    • Web 2.0 
    • Web 3.0 - Semantic Web
  • Future steps to realize Web science
    • Large scale reasoning
    • Rethinking Computer Science for the 21st century

Web 1.0

  • The World Wide Web ("WWW" or simply the "Web") is a system of interlinked, hypertext documents that runs over the Internet. Witha Web browser, a user views Web pages that may contain text, images, and other multimedia and navigate between them using hyperlinks.
  • The Web was created around 1990 by Tim Berners-Lee working at CERN in Geneva, Switzerland. 
  • A distributed document delivery system implemented using application-level protocols on the Internet
  • A tool for collaborative writing and community building
  • A framework of protocols that support e-commerce
  • A network of co-operating computers interoperating using HTTP and related protocols to form a ‘subnet’ of the Internet
  • A large, cyclical, directed graph made up of Web pages and links

The breakthrough

WWW components

  • Structural Components
    • Clients/browsers – to dominant implementations
    • Servers – run on sophisticated hardware
    • Caches – many interesting implementations
    • Internet – the global infrastructure which facilitates data transfer
  • Language and Protocol Components
    • Uniform Resource Identifiers (URIs)
    • Hyper Text Transfer Protocol (HTTP)
    • Hyper Text Markup Language (HTML)

Uniform Resource Identifiers (URIs)

  • Uniform Resource Identifiers (URIs) are used to name/identify resources on the Web
  • URIs are pointers to resources to which request methods can be applied to generate potentially different responses
  • Resource can reside anywhere on the Internet
  • Most popular form of a URI is the Uniform Resource Locator (URL)

Hypertext Transfer Protocol (HTTP)

  • Protocol for client/server communication
    • The heart of the Web
    • Very simple request/response protocol
    • Client sends request message, server replies with response message
    • Provide a way to publish and retrieve HTML pages
    • Stateless
    • Relies on URI naming mechanism

HTTP Request Messages

  • GET – retrieve document specified by URL
  • PUT – store specified document under given URL
  • HEAD – retrieve info. about document specified by URL
  • OPTIONS – retrieve information about available options
  • POST – give information (eg. annotation) to the server
  • DELETE – remove document specified by URL
  • TRACE – loopback request message
  • CONNECT – for use by caches

HTML

  • Hyper-Text Markup Language
    • A subset of Standardized General Markup Language (SGML)
    • Facilitates a hyper-media environment
  • Documents use elements to “mark up” or identify sections of text for different purposes or display characteristics
  • Mark up elements are not seen by the user when page is displayed
  • Documents are rendered by browsers
  • HTML markup consists of several types of entities, including: elements, attributes, data types and character references 
    • DTD (Document Type Definition)
    • Element (such as document (…), head elements () 
    • Attribute: HTML
    • Data type: CDATA, URIs, Dates, Link types, language code, color, text string, etc. 
    • Character references: for referring to rarely used characters: 
      • "&#x6C34" (in hexadecimal) represents the Chinese character for water 

Web 2.0

  • “Web 2.0 is a notion for a row of interactive and collaborative systems of the internet“
  • Web 2.0 is a vaguely defined phrase referring to various topics such as social networking sites, wikis, communication tools, and folksonomies.
  • Tim O'Reilly provided a definition of Web 2.0 in 2006: "Web 2.0 is the business revolution in the computer industry caused by the move to the internet as platform, and an attempt to understand the rules for success on that new platform. Chief among those rules is this: Build applications that harness network effects to get better the more people use them.”

Elements of the Web's next generation

  • People, Services, Technologies

Definition“ by O‘Reilly

Web 1.0

DoubleClick

Ofoto

Britannica Online content

Web sites

publishing

CMS 

directories

taxonomy

Web 2.0

Google AdSense

Flickr

Wikipedia

blogging

participation

wikis

tagging

folksonomy

improvement

personalized

tagging, community

community, free

dialogue


flexibility, freedom

community

    Characteristics of Web 2.0 applications

    • Typical characteristics of Web 2.0 applications
      • Users can produce and consume data on a Web 2.0 site
      • Web is used as a participation platform
      • Users can run software applications entirely through a Web browser
      • Data and services can be easily combined to create mashups

    Examples

    • Gmail
    • Google Notebooks (Collaborative Notepad in the Web)
    • Wikis
    • Wikipedia
      • Worlds biggest encyclopedia, Top 30 web site, 100 langueges
    • Del.icio.us (Social Tagging for Bookmarks)‏
    • Flickr (Photo Sharing and Tagging) 
    • Blogs, RSS, Blogger.com
    • Programmableweb.com: 150 web-APIs

    Blogs

    • Easy usable user interfaces to update contents
    • Easy organization of contents
    • Easy usage of contents
    • Easy publishing of comments
    • Social: collaborative (single users but strongly connected)‏

    Introduction


    • Wiki was invented by Ward Cunningham
    • Collection of HTML sites: read and edit
    • Most famous and biggest Wiki: Wikipedia (MediaWiki)
      • But: Also often used in Intranets (i. e. our group)
    • Problems solved socially instead of technically
    • Flexible structure
    • Background algorithms + human intelligence
    • No new technologies
    • social: collaborative (nobody owns contents)

    Wikis: Design Principles

    • Open
      • Should a page be found to be incomplete or poorly organized, any reader can edit it as they see fit. 
    • Incremental
      • Pages can cite other pages, including pages that have not been written yet. 
    • Organic
      • The structure and text content of the site are open to editing and evolution. 
    • Mundane
      • A small number of (irregular) text conventions will provide access to the most useful page markup. 
    • Universal
      • The mechanisms of editing and organizing are the same as those of writing so that any writer is automatically an editor and organizer. 
    • Overt
      • The formatted (and printed) output will suggest the input required to reproduce it. 
    • Unified
      • Page names will be drawn from a flat space so that no additional context is required to interpret them. 
    • Precise
      • Pages will be titled with sufficient precision to avoid most name clashes, typically by forming noun phrases.

    Wikis: Design Principles

    • Tolerant
      • Interpretable (even if undesirable) behavior is preferred to error messages. 
    • Observable
      • Activity within the site can be watched and reviewed by any other visitor to the site.
    • Convergent
      • Duplication can be discouraged or removed by finding and citing similar or related content. 

    Social tagging

    • Idea: Enrich contents by user chosen keywords
    • Replace folder based structure by a organisation using tags
    • New: Simple user interfaces for tagging and tag based search
    • First steps to Semantic Web?
    • Technically: user interfaces
    • Social: collaborative (own contents, shared tags)

    Collaborative Tagging

    Collaborative Tagging: Delicious

    • Browser plug-ins available from http://del.icio.us
    • Allows the tagging of bookmarks
    • Community aspect: 
      • Suggestion of tags that were used by other users
      • Availability of tag clouds for bookmarks of the whole community
      • Possibility to browse related bookmarks based on tags

    Tagging: Flickr.com

      

    Folksonomies

    • Data created by tagging, knowledge structures

    Tag Clouds

    Major breakthroughs of Web 2.0

    • The four major breakthroughs of Web 2.0 are:
      • Blurring the distinction between content consumers and content providers.
      • Moving from media for individuals towards media for communities.
      • Blurring the distinction between service consumers and service providers.
      • Integrating human and machine computing in a new way.

    Blurring the distinction between content consumers and providers

    • Interactive Web applications through asynchronous JavaScript and XML (AJAX)
    • Interactive Web applications through asynchronous JavaScript and XML (AJAX)
    • Web blogs or Blogs, Wikis

    Blurring the distinction between content consumers and providers:

    • Flickr, YouTube

    • Tagging – del.icio.us, shazam.com

    Blurring the distinction between content consumers and providers

    • RDFA, micro formats

    Moving from a media for individuals towards a media for communities


    • Folksomonies, FOAF
    • Community pages (friend-of-a-friend, flickr, LinkedIn, myspace, …)

    Moving from a media for individuals towards a media for communities

    • Second Life
    • Wikipedia

    Moving from a media for individuals towards a media for communities

    • Wikipedia


    Blurring the distinction between service consumers and service providers

    • RSS feeds

    • Yahoo pipes allow people to connect internet data sources, process them, and redirect the output.

    Blurring the distinction between service consumers and service providers

    • Widgets, gadgets, and mashups.

    Integrating human and machine computing in a new way

    •  Amazon Mechanical turk

    Web Evolution - summary

    Web 1.0

    Web 2.0

    Semantic Web

    Personal Websites

    Blogs

    Semantic Blogs: semiBlog, Haystack, Semblog, Structured Blogging

    Content Management Systems, Britannica Online

    Wikis, Wikipedia

    Semantic Wikis: Semantic MediaWiki, SemperWiki, Platypus, dbpedia, Rhizome

    Altavista, Google

    Google Personalised, DumbFind, Hakia

    Semantic Search: SWSE, Swoogle, Intellidimension

    CiteSeer, Project Gutenberg

    Google Scholar, Book Search

    Semantic Digital Libraries: JeromeDL, BRICKS, Longwell

    Message Boards

    Community Portals

    Semantic Forums and Community Portals: SIOC, OpenLink DataSpaces

    Buddy Lists, Address Books

    Online Social Networks

    Semantic Social Networks: FOAF, PeopleAggregator

    Semantic Social Information Spaces: Nepomuk, Gnowsis

    Web Evolution - summary (cont')

    • Traditional Web (Web1.0)
      • Normal User: browsing
      • Communication style: one-direction communication (e.g. reading a book)
      • Data: web data (string and syntactic format)
      • Data contributor: webmaster or experienced user
      • How to add data: compose HTML pages
    • Social Web (Web2.0) 
      • Normal User: browsing + publishing and organizing web data
      • Communication style: human-human (sharing) 
      • Data: web data + tags
      • Data contributor: normal user – revolution!
      • How to add data: tagging
    • Semantic Web 
      • Normal User: interacting (human-machine)
      • Communication style: humanmachine
      • Data: web data + tags + metadata (in SW Language)
      • Data contributor: normal user, machine
      • How to add data: machine generate or user publish

    Web principles

    • In the context of the traditional Web (Web 1.0) a set of principles were proposed:
      • Web resource are identified by URI (Universal Resource Identifier)
      • Namespaces should be used to denote consistent information spaces
      • Make use of HTML, XML and other W3C Web technology recommendations, as well as the decentralization of resources

    Web 1.0 + semantics = Semantic Web

    • The traditional Web represents information using:
      • natural language (English, German, Italian,…)
      • graphics, multimedia, page layout
    • Humans can process this easily
      • can deduce facts from partial information
      • can create mental associations
      • are used to various sensory information
    • However... Machines are ignorant!
      • partial information is unusable
      • difficult to make sense from, e.g., an image
      • drawing analogies automatically is difficult
      • difficult to combine information automatically
      • is same as ?
      • how to combine different XML hierarchies?

    Semantic Web

    • Semantic Web is about applying semantics to the tradition Web, Web 1.0
    • Some of the benefits of Semantic Web:
      • More precise queries
      • Smarter apps with less work
      • Share & link data between apps
      • Information has machine-processable and machine-understandable semantics

    Limitations of applying semantics to traditional Web

    • The principal limits of describing large, heterogeneous, and distributed systems
    • The principal limits of self representation and self reflection
    • Necessitates incompleteness and incorrectness of semantic descriptions.


    Limitations of applying semantics to traditional Web

    • The meta layer should apply heuristics that may help
      • Speed up the overall reasoning process. 
      • Increase its flexibility.
    • Therefore, it needs to be incomplete in various aspects and resemble important aspects of our consciousness.
      • Introspection
      • Reflection
    • Unbounded rationality, constrained rationality, limited rationality.
    • Description of data by metadata or programs by metaprograms
      • Always larger (even infinitely large) 
      • … or always an approximation

    Data look-up on the Web

    • In a large, distributed, and heterogeneous environment, classical ACID guarantees of the database world no longer scale in any sense.
    • Even a simple read operation in an environment such as the Web, a peer-to-peer storage network, a set of distributed repositories, or a space, cannot guarantee completeness in the sense of assuming that if data was not returned, then it was not there.
    • Similarly, a write can also not guarantee a consistent state that it is immediately replicated to all the storage facilities at once.

    Information retrieval on the Web

    • Modern information retrieval applies the same principles
      • In information retrieval, the notion of completeness (recall) becomes more and more meaningless in the context of Web scale information infrastructures.
      • It is very unlikely that a user requests all the information relevant to a certain topic that exists on a worldwide scale, since this could easily go far beyond the amount of information processing he or she is investing in achieving a certain goal. 
      • Therefore, instead of investigating the full space of precision and recall, information retrieval is starting to focus more around improving precision and proper ranking of results.

    Reasoning on the Web

    • What holds for a simple data look-up holds in an even stronger sense for reasoning on Web scale.
    • The notion of 100% completeness and correctness as usually assumed in logic-based reasoning does not even make sense anymore since the underlying fact base is changing faster than any reasoning process can process it.
    • Therefore, we have to develop a notion of usability of inferred results and relate them with the resources that are requested for it.

    LarKC – The Large Knowledge Collider

    • An open source, modular, and distributed platform for inference on the Web that makes use of new reasoning techniques
    • A plug-in architecture that supports cooperation between distributed, heterogeneous, cooperating modules enabling research into new and different reasoning techniques
    • A platform for infinitely scalable reasoning on the data-web
    • First real attempt at Reasoning at a Web scale
    • Not just adding a Web syntax to reasoning, but reflecting on the underlying assumptions of reasoning and the Web
      • Bringing Web principles to reasoning
      • Bringing reasoning to the Web
    • Thus LarKC is true Web Science
    • A number of broken assumptions of reasoning and logic in a Web context:
      • The Web is small
      • The Web does not change
      • The Web does not contradict itself

    LarKC – The Large Knowledge Collider

    • In fact:
      • The Web is huge
      • The Web changes faster than we can reason over it
      • The Web contains contradictions and different points of view
    • The essence of the web (search) must be included into the reasoning process, generating something new called reasearch
    • After 4000 years of separation LarKC merges induction and deduction

    Web Science – The Computer Science of the 21st Century

    • With the Web we have an open, heterogeneous, distributed, and fast changing computing environment.
    • Therefore we need computing to be understood as
      • A goal driven approach where the solution process is only partially determined and actually decided during runtime, based on available data and services.
      • A heuristic approach that gives up on absolute notion of completeness and correctness in order to gain scalability.
    • The times of 100% complete and correct solutions are gone.
    • The need for trade-offs:
      • In all areas one has to define the trade-off between the guarantees one provides in terms of service level agreements. Completeness and correctness are just examples of some very strong guarantees and what this requires in terms of assumptions, and computational complexity 
      • Different heuristic problem solving approaches are just different combinations of these three factors.
    • Service level agreements (or goals) define what has to be provided as result of solving a problem.
    • Do we request an optimal solution, a semi-optimal solution, or just any solution?

    Web Science – The Computer Science of the 21st Century (cont')

    • Assumptions describe the generality of the problem solving approach:
      • Assuming that there is only one solution allows stopping the search for an optimum immediately after a solution has been found. 
      • Instead of a global optimization method, a much simpler heuristic search method can be used in this case, which would still deliver a global optimum.
    • Computational complexity (scalability) or the resources that are required to fill the gap between the assumptions and the goals.
    • Computer science in the 20th century was about perfect solutions in closed domains and applications. 
    • Web science, the new computer science of the 21st century, will be about approximate solutions and frameworks that capture the relationships of partial solutions and requirements in terms of computational costs, i.e., the proper balance of their ratio.

    Web Science – The Computer Science of the 21st Century (cont')

    • This shift is comparable to the transition in physics, from classical physics to relativity theory and quantum mechanics,
    • ...where the notion of absolute space and time is replaced by relativistic notions and the principle limits of precision.
    • the more precisely we know about the location of a particle in space, the less we know about its movement in time and vice versa.

    Summary

    • The Web is a in an extending success story with over more than a 2 billion users more than 50 billion pages
    • There is a need for a new science that focuses on how huge decentralized Web systems work - Web Science
    • Semantics will play a central role in the future development of the Web
    • However there are limitations of applying semantics to traditional Web due to the principal limits of self representation and self reflection
    • Limitations should be addressed by considering 2 levels: meta layer and object layer
    • Meta layer should apply heuristics that may help speed up the overall reasoning process and increase its flexibility.
    • Introspection and Reflection can be used to move from one layer to the other

    References

    • T. Berners-Lee, W. Hall, J. Hendler, N. Shadbolt, D. Weitzner (2006): Creating a science of the Web. http://eprints.ecs.soton.ac.uk/12615/ 
    • T. Berners-Lee, W. Hall, J. Hendler, K. O’Hara, N. Shadbolt, D. Weitzner (2006): A Framework for Web Science. http://eprints.ecs.soton.ac.uk/13347/
    • D. Fensel, Dieter F. van Harmelen. Unifying Reasoning and Search to Web Scale, IEEE Internet Computing, 11(2), 2007 
    • D. Fensel, D. Wolf: The Scientific Role of Computer Science in the 21st Century. In Proceedings of the third International Workshop on Philosophy and Informatics (WSPI 2006), Saarbruecken, Germany, May 3-4, 2006. 
    • D. Fensel, F. van Harmelen, B. Andersson, P. Brennan, H. Cunningham E. Della Valle, F. Fischer, Z. Huang, A. Kiryakov and T. Kyung-il Lee, L. School,V. Tresp, S. Wesner, M. Witbrock and N. Zhong, Towards LarKC: a Platform for Web-scale ReasoningIEEE Computer Society Press Los Alamitos, CA, USA, 2008.
    • F. Fischer, G. Unel, B. Bishop and D. Fensel, Towards a scalable, pragmatic Knowledge Representation Language for the Web, 2009.
    • N. Shadbolt. Web Science Research Initiative Seminar November 2008
    • http://www.ecs.soton.ac.uk/podcasts/video.php?id=153
    • http://en.wikipedia.org/wiki/Web_of_Science
    • http://en.wikipedia.org/wiki/Web_2.0
    • http://en.wikipedia.org/wiki/Semantic_Web
    • Web Science Research Initiative http://webscience.org/
    • http://www.larkc.eu/
     

    Agenda

    • What is Service Science?
    • Motivation
    • Service vs Web Service
    • Service Oriented Architecture (SOA)
      • SOA Principles
      • SOA Properties
      • SOA Benefits
      • Semantically enabled Service Oriented Architecture
    • Summary
    • References

    What is Service Science?

    • “Service Science, Management and Engineering (SSME) is a new multi-disciplinary research and academic effort that integrates aspects of established fields such as computer science, operations research, engineering, management sciences, business strategy, social and cognitive sciences, and legal sciences.”
      IBM's definition
    • “Service Science, Management, and Engineering (SSME) is an interdisciplinary approach to the study, design, and implementation of service systems – complex systems in which specific arrangements of people and technologies take actions that provide value for others.”
      Wikipedia's definition

    Service Science: multidisciplinary

    • A multidisciplinary science influenced by
      • Computer science
      • Cognitive science
      • Economics
      • Organizational behavior
      • Marketing
      • Operations research
      • Policy and Law

    Towards a theory of service systems

    • A general theory of service systems should consist of:
      • Sciencewhat service systems are and how to understand their evolution
      • Management how to invest to improve service systems
      • Engineering how to invent new technologies that improve the scaling of service systems

    Service Science References

    • Service Science is recognized as a very important emerging science:
      • IBM: Service Science, Management and Engineering
        http://www.ibm.com/university/ssme
      • HP: Center for Systems and Service Sciences
        http://www.services-sciences.org/
      • Oracle: Service Research and Innovation Initiative
        http://www.thesrii.org/

    Motivation

    • Service sector vs Industrial sector vs agriculture sector
      • Service sector is becoming more important than industrial sector
      • Products today have a higher service component than in previous decades
    • The current list of Fortune 500 companies contains more service companies and fewer manufacturers than in previous decades.

    The Rise of the Service Economy

    • Services has a growing share inany of the big countries
    • US or Germany have a long tradition in service economy
    • China or India have switched to services more into the last century 
    • In most countries, services represent more than 50% of the overall economy
    • Service economy is growing due to various reasons:
      • substituting technology for human labor in many agricultural and manufacturing process
      • labor is moved to low cost locations (countries) which makes allows countries that oursource production to focus on services.

    Explosion of services in IT: Example IBM


    Why Service Science?

    • Services are becoming more important than any other sector of the economy
    • Economies of the world shifting from agriculture and manufacturing to services: The Rise of the Service Economy
    • A new discipline dedicated to the study, design, and implementation of service systems is needed - Service Science
    • Driven by a business environment that includes advanced telecommunications, accelerated business globalization, and rapid technology innovations, emphasis in service has evolved from a traditional labor-based business to sources of innovation, collaboration, and value co-creation.
    • However, the focus shift to service has created a research and education gap due to the complexity of inter-disciplinary issues across service business strategy and modeling, operations research, information technologies, industrial engineering, management science, social and cognitive science, work force management, and legal science, etc.

    The Goal of Service Science

    • To provide concepts, methods and techniques to understand and engineer service based systems
    • To ensure the social benefit of service based systems
    • Ultimately to provide a sound and complete theory for bringing Service Economy at global scale through IT

    Services

    • The word service is used in several contexts:
      • Communication Service
      • Ticket Reservation Service
      • Transport Service
      • Information Service
      • Finance Service
      • E-government Service

    But what is a Service?

    What is a service?

    Main Entry: ser·vice

    Function: noun

    Etymology: Middle English, from Anglo-French servise, from Latin servitium condition of a slave, body of slaves, from servus slave

    1 a: the occupation or function of serving service> b: employment as a servant service>

    2 a: the work performed by one that serves service> b: help , use , benefit service> c: contribution to the welfare of others d: disposal for use service>

    3 a: a form followed in worship or in a religious ceremony service> b: a meeting for worship —often used in plural services>

    4: the act of serving: as a: a helpful act service> b: useful labor that does not produce a tangible commodity —usually used in plural services> c: serve

    5: a set of articles for a particular use service>

    6 a: an administrative division (as of a government or business) service> b: one of a nation's military forces (as the army or navy)

    7 a: a facility supplying some public demand service> service> b: a facility providing maintenance and repair service>

    8: the materials (as spun yarn, small lines, or canvas) used for serving a rope

    9: the act of bringing a legal writ, process, or summons to notice as prescribed by law

    10: the act of a male animal copulating with a female animal

    11: a branch of a hospital medical staff devoted to a particular specialty service>

    What is a service?

    • For different people the term Service has different meaning
    • In Business and Economics
      • a service is seen as a business activity that often results in intangible outcomes or benefits
      • a service is the non-material equivalent of a good. Service provision has been defined as an economic activity that does not result in ownership, and this is what differentiates it from providing physical goods.
      • a process that creates benefits by facilitating either a change in customers, a change in their physical possessions, or a change in their intangible assets.
    • In Computer Science
      • the terms service and Web service are often regarded as interchangeable to name a software entity accessible over the Internet. 
      • a (Web) service is seen software system designed to support interoperable machine-to-machine interaction over a network

    Service vs. Web Service

    • Service
      • A provision of value in some domain (not necessarily monetary, independent of how service provider and requestor interact)
      • Example: Let’s consider a user who wants to book a train ticket from Innsbruck to Munich on a given date. The service he is looking for, is the provision of a train ticket with the specified constraints. Such provision is independent on how the supplier and the provider interact, i.e., it does not matter whether the requester goes to a train tickets office or uses the train Web site to book his trip.
    • Web Service
      • Computational entity accessible over the Internet (using Web Service Standards & Protocols), provides access to (concrete) services for the clients.
      • Example of a Web Service: a railway company might provide a software component accessible via Web service standards, i.e., a Web service to request the booking of a trip. Thus, the Web service is an electronic means by which a client is able to request a specific service from a provider, but not the service itself.

    Web Service properties

    • Functional
      • contains the formal specification of what exactly the service can do.
    • Behavioral
      • how the functionality of the service can be achieved in terms of interaction with the service and as well in terms of functionality required from the other Web services.
    • Non-functional properties
      • captures constraints over the previous mentioned properties

    Web Service related tasks

    • Discovery: Find services that matches to the service requester specification” .
    • Selection and Ranking: “Choose the most appropriate services among the available ones”
    • Composition: “Assembly of services based in order to achieve a given goal and provide a higher order of functionality”.
    • Mediation: “Solve mismatches among domain knowledge used to describe the services, protocols used in the communication, data exchanged in the interaction (types used, and meaning of the information) and business models of the different parties”.
    • Execution: “Invocation of a concrete set of services, arranged in a particular way following programmatic conventions that realizes a given task”.
    • Monitoring: “Supervision of the correct execution of services and dealing with exceptions thrown by composed services or the composition workflow itself”.
    • Handover: “Replacement of services by equivalent ones, which solely or in combination can realize the same functionality as the replaced one, in case of failure while execution”.

    What is Service Oriented Architecture (SOA)?

    • “A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.”[1]
    • “Service-oriented architecture (SOA) provides methods for systems development and integration where systems group functionality around business processes and package these as interoperable services. An SOA infrastructure allows different applications to exchange data with one another as they participate in business processes. SOA separates functions into distinct units, or services, which developers make accessible over a network in order that users can combine and reuse them in the production of business applications “ [2] 
    • Is not a computing architecture but a style of programming 
    • An SOA application is a composition of services
    • A “service” is the building block/ unit of an SOA
    • Services encapsulate a business process
    • Service Providers Register themselves
    • Service use involves: Find, Bind,
      Execute
    • Most well-known instance is Web

    SOA Actors

    • Service Provider 
      • From a business perspective, this is the owner of the service. From an architectural perspective, this is the platform that provides access to the service
    • Service Registry
      • This is an information space of service descriptions where service providers publish their services and service requesters find services and obtain binding information for services. 
      • Allows service consumers to locate service providers that meet required criteria
    • Service Consumer
      • From a business perspective, this is the business that requires certain function to be fulfilled. From an architectural perspective, this is the client application that is looking for and eventually invoking a service.

    SOA Principles

    • Formal contract
    • Loose coupling
    • Abstraction
    • Reusability
    • Autonomy
    • Statelessness
    • Discoverability
    • Composability

    SOA Principles – Loose coupling

    • SOA is a loosely coupled arrangement of services and service consumers. At design time, loose coupling means that services are designed with no affinity to any particular service consumer. Inside the service, no information is assumed as to the purpose, technical nature or business nature of the service consumer. Thus, a service is fully decoupled from a service consumer.
    • However, the service consumer is dependent on the service (that is, it embeds literal references to service interfaces). Thus, SOA is asemi-coupled (or loosely coupled) architecture. It differs from an event-driven architecture, in which all participating software components are decoupled from others, and also from a monolithic architecture, in which all software components are designed to operate only in the initially intended context (that is, logically tightly coupled).
    • Design-time loose coupling is essential to SOA because it enables the non-intrusive reuse of service interfaces. However, tools can't guarantee design-time loose coupling. Poorly designed services, which are logically locked into their service consumers, may render the entire application monolithic —despite the use of SOA-style technologies.

    SOA Principles – Abstraction

    • This principle emphasizes the need to hide as much of the underlying details of a service as possible. 
    • By using abstraction previously described loosely coupled relationship is directly enabled and preserved
    • There are 4 levels of abstraction in SOA as suggested in [4]:
      • technology abstraction
      • functional abstraction
      • programming logic abstraction
      • quality of service abstraction

    SOA Principles – Formal contract

    • According to SOA Formal contract principle every service needs to have an official, standardized, formal contract.
    • A great deal of emphasis is placed on specific aspects of contract design, including:
      • the manner in which services express functionality (functional description contract)
      • how data types and data models are defined (information model)
      • how policies are asserted and attached. (non-functional description contract)
      • how interaction with the service is to be performed (behavioral contract)

    SOA Principles – Reusability

    • The reusability principle suggest to contain and express agnostic logic as services that can be positioned as reusable enterprise resources
    • Reusability will:
      • Allow for service logic to be repeatedly leveraged over time so as to achieve a high ROI
      • Increase business agility on an organizational level
      • Enable the creation of service inventories that can be easily integrated and used in various use-cases

    SOA Principles – Autonomy

    • SOA Autonomy principle implies that services have control over the solution logic they implement.
    • SOA Autonomy/ Service Autonomy can be observed as various levels:
      • Runtime autonomy – represents the amount of control a service has over its execution environment at runtime
      • Design-time autonomy – represents the amount of governance control a service owner has over the service design

    SOA Principles – Statelessness

    • This means a service must do its best to hold onto state information pertaining to an interaction for as small a duration as possible, e.g., do not retain awareness of a message once it is processed.
    • Statelessness in a service means that if the service is enlisted in a flow, than it doesn’t retain any state referring to the enclosing flow. Form a message perspective, it means that once a service has received and processed a message, it doesn’t retain memory of the passage of that message.
    • This helps with concurrent access scaling

    Statelessness in SOA and REST

    • SOA and REST share the Statelessness principle
    • REST provides explicit state transitions
    • REST Servers are stateless and messages can be interpreted without examining history.
    • Persistent data can be given explicit URIs on the server.
    • Messages can refer to persistent data through links to URIs.

    Statelessness in SOA and REST

    • In SOA
      • Stateless communication although communication can be stateful as well 
        • Received or sent messages can trigger state change 
        • Operations requiring sequence of messages
      • Capable to support transactions 
        • set of operations with pass or fail results
      • Tighter coupling between components
    • In REST
      • Stateless communication
        • Document transfer only 
        • A party is not aware of its partner current state
      • Party receiving information can decide how to process it
      • HTTP caching possible 
      • Looser coupling between components

    SOA Principles – Discoverability

     
    • SOA Discoverability is meant to help one avoid the accidental creation of services that are either redundant or implement logic that is redundant. The discoverability principle can be referred to the design of an individual service so that it becomes as discoverable as possible – no matter whether the discoverability extension or product actually exists in the surrounding implementation environment.
    • Discovery is a central task in SOA. SOA Discoverability is centered on Service Discoverability. Service Discoverability is meant to refer to the technology architecture’s ability to provide a mechanism of discovery, for example a service directory, service registry or a service search engine.
    • Services be designed as resources that are highly discoverable in some fashion. Each service should be equipped with the metadata that is required to properly communicate its capabilities and meaning.

    SOA Principles – Composability

     
    • Allow us to chain services together to provide new services
    • Composition has the advantage that one can put together composite applications at a speed greater than writing one from scratch
    • Building new services and application becomes quicker and cheaper

    SOA Properties – Self-* Properties

    • Most service architectures aim for „self-*“ properties to reduce management load by design: 
      • Self-Configuration
      • Self-Organization
      • Self-Healing
      • Self-Optimization
      • Self-Protection

    Self-Configuration

    • Service architectures comprise of a huge amount of different components (services and hardware). Configuration is a challenging task in such environments.
    • The idea of self-configurationis the adoption of the self-organization and fully distributed cooperation capabilities known from groups with cooperative social behavior which collaborate to solve a problem. Every member of the group can decide which part of the problem it can solve and which “QoS” it can provide.

    Self-Organization

     
    • A system is self-organizing if it automatically, dynamically and autonomously adapts itself to achieve global goals more efficiently under changing conditions.

    Self-Healing

    •  The task of self-healing is to assure that a system meets some defined conditions as far as possible, i.e. to guarantee that all services running in the framework stay available, even in the case of partial outages in the system.

    Self-Optimization

    • The self-configuration is responsible to find a good distribution of the services in terms of the given resources of the service description. The target of the self-optimization is to distribute the services of the application in a way that the considered resources are utilized evenly. 
    • A typical approach is to find an adequate configuration at the beginning and to optimize the application during runtime.

    Self-Protection

    • Self-protection techniques cope with intentionally or unintentionally malicious peers or services in a framework. The behave as the “immune system” of a service framework as they are permissive to good-natured services and messages but can detect appearing malicious events.

    SOA Benefits

    • Business Benefits
      • Focus on Business Domain solutions
      • Leverage Existing Infrastructure
      • Agility
    • Technical Benefits
      • Loose Coupling
      • Autonomous Service 
      • Location Transparency
      • Late Binding

    SESA

    • Currently, computer science is in the next period of abstraction.
    • A generation ago we learnt to abstract from hardware and currently we learn to abstract from software in terms of SERVICE oriented architectures (SOA).
    • It is the service that counts for a customer and not the specific software or hardware that is used to implement the service.
    • In a later stage, we may even talk in terms of problem-oriented architectures (or more positively expressed in terms of problem solving oriented architectures) because SOAs are biased towards the service provider and not towards the customer that has a problem that needs to be solved.
    • Service-oriented architectures will become quickly the leading software paradigm.
    • However, SOAs will not scale without signification mechanization of – service discovery, service adaptation, negotiation, service composition, service invocation, and service monitoring; and data and process mediation.
    • Therefore, machine processable semantics needs to be added to bring SOAs to their full potential.
    • Development of open standards (languages) and open source architectures and tools that add semantics to service descriptions

    Three Layers of SESA

    • Problem-Solving Layer
      • Turns a service-oriented architecture into a domain specific problem-solving environment
    • Common Services Layer
      • The execution environment and the supporting infrastructure that maps the problem descriptions generated at the Problem Solving Layer to the services that can solve the problems
    • Resource Layer
      • Covers the deployment and provisioning of physical resource being responsible for the actual execution of the applications 

    Problem solving layer

    • This layer turns a service-oriented architecture into a domain specific problem-solving environment. 
    • It represents the transparent interface to the user(s), where all computing resources are turned into or expressed as services
    • Supports the full set of operations from an e-commerce framework: information negotiation, etc.
    • Provides clear separation between business/process logic on one hand and the common service layer

    Common Services Layer

     
    • Provides an adaptive execution environment and the supporting infrastructure that maps the problem descriptions generated at the Problem Solving Layer to the services that can solve the problems. 
    • Existing architectures and standards from Web service and Grid areas (e.g. OGSA, WSRF, WSDL) which operate only at a syntactic level are semantically enriched and integrated into this layer.
    • Semantically enrichment of SOAs that implement the Common Service Layer capabilities will help to automate: service discovery, service adaptation, negotiation, service composition, etc.
    • This layer could be implemented using the W technology

    Resource Layer

    • Responsible for actual execution of applications. 
    • All tasks that involve resources such as resource discovery, selection and negotiation for advanced or on-the-fly reservation of resources are supported and implemented in this layer. 
    • Covers the deployment and provisioning of physical resource (e.g. computers, data servers, and networks, usually connected into a Grid) and logical resources (e.g. application components or common services). 
    • This layer may relay on two prominent and widely discussed areas that deal with distributed resources in the context of service oriented computing are Ubiquitous Computing and Grid Computing

    WTriple

    • W<Triple> which stands for:
      • WSMO: A conceptual model for describing service oriented architectures
      • WSML: A formal language for describing service oriented architectures
      • WSMX: A service oriented architecture
      • Triple space: A shared space for heterogeneous services that communicate via persistent publication

    WTriple: WSMO

    WTriple: WSML

    A set of concrete languages for the various tasks:

    • Ontology / Rule Languages (static view)
      • WSML Core
        • efficiency and compatibility
      • WSML DL
        • decidability, open world semantics
      • WSML Rule
        • efficient existing rule engines
      • WSML Full
        • unifying language, theorem proving
    • Languages for dynamics
      • Transaction Logic over ASMs
    • Mapping languages
      • for dynamics (process mediation)
      • or data (data mediation)

    WTriple: WSMX

    • WSMX: The Web Service EXecution Environment
    • A service oriented architecture.
    • Reference implementation of SESA and WSMO

    WTriple: Triple Space Computing

    • Email:
      • Human to Human communication (Human net)
      • Dissemination of information was based on message exchange (Message)

    • Web:
      • Human to Human communication (Human net)
      • Dissemination of information based on publishing (Publishing)

    WTriple: Triple Space Computing

    • Web Services:
      • Machine to Machine communication (Machine net)
      • Dissemination of information based on messages (Message)

    • Triple Space:
      • Machine to Machine communication (Machine net)
      • Dissemination of information based on Web principles (Publishing)

    WTriple: Triple Space Computing

    • Communication platform for Semantic Web services based on Web principles:
    • “Persistently publish and read semantic data that is denoted by unique identifiers”
    • Fundamentals
      • Space-based computing – sharing information, knowledge
      • RDF triples of the form: 
      • URI – Uniform Resource Identifier
    • Triple Spaces allow for:
      • Time autonomy
      • Location autonomy
      • Reference autonomy
      • Vocabulary autonomy
    • Triple Spaces provide a communication paradigm for anonymous, asynchronous information exchange that ensure the persistency and unique identification of the communicated semantic data.

    Service Science: why this matter?

    • SOA will be a reality
      • It can knit together a diverse world
    • SOA makes BPM possible
      • SOA’s benefits are fundamentally about improving business processes
    • Service-oriented architectures are an arising software paradigm with big potential for the IT market.
    • Bringing service orientation to its full potential requires its combination with semantics to mechanize important aspects and make it scalable.

    Summary

    •  Services rather than goods become the focus of economic and social exchange
    • The service industry is increasing very rapidly. A new disciplinededicated to the study, design, and implementation of service systems, called Service Science, is emerging.
    • Service Oriented Architecture (SOA) is in the center of this discipline.
    • However SOA will not scale without proper solutions for service related tasks such as discovery and mediation. 
    • Semantics offera a scalable solutions for the above mentioned problems.
    • Integrating semantics into SOA will result into the next generation of intelligent service-based systems - SESA

    References

    • Dieter Fensel, Mick Kerrigan, and Michal Zaremba (eds.). Implementing Semantic Web Services - The SESA Framework, Springer, 2008. ISBN: 978-3-540-77019-0
    • Jim Spohrer and Stephen K. Kwan. Service Science, management, Engineering, and Design (SSMED): Outline & References
    • Jim Spohrer, Paul P. Maglio, John Bailey, Daniel Gruhl, "Steps Toward a Science of Service Systems," Computer, vol. 40, no. 1, pp. 71-77, Jan. 2007, doi:10.1109/MC.2007.33 
    • Thomas Erl, SOA Principles of Service Design, Prentice Hall 2007 ISBN:0132344823 
    • YefimV. Natis, Roy W. Schulte. Introduction to Service-Oriented Architecture, 14 April 2003
    • http://en.wikipedia.org/wiki/Service_Science,_Management_and_Engineering
    • http://en.wikipedia.org/wiki/Service_economy
    • http://en.wikipedia.org/wiki/Service_(systems_architecture)
    • http://en.wikipedia.org/wiki/Webservice
    • http://en.wikipedia.org/wiki/Service-oriented_architecture
    • http://en.wikipedia.org/wiki/Cloud_computing
    • http://en.wikipedia.org/wiki/Amazon_Elastic_Compute_Cloud
    • http://en.wikipedia.org/wiki/Amazon_Mechanical_Turk

    Agenda

    • Motivation
    • SOAP protocol and related specifications
    • WSDL interface definition langiage
    • WS-Policy
    • WS-BPEL
    • Illustration by a larger exampe
    • Possible Extensions
    • Summary
    • Referneces
     

    SOA

    • Service-Oriented Architecture
    • For large-scale distributed computing
    • For interoperability within and among enterprises
    • Business-oriented services
      • Coarse-grained service interfaces
      • Improves evolvability, manageability
    • Needs a suitable set of technologies

    Solutions needed to implement SOA lifecycle

    • SOA is a programming style
    • An SOA application is a composition of services
    • A ‘service’ is a building block/unit of an SOA
    • Service encapsulates a business process
    • A Service Provider registers services
    • Service consumption involves Find-Bind-Execute pattern
    • Questions
      • How to specify data involved in the process?
      • How to specify the way to access a service functionality?
      • How to communicate to services?
      • Can we use some existing solutions?

    Web Services

    • Technology for SOA
    • Client-server messaging approach
      • With predefined Message exchange patterns
      • Independent of network protocols
    • Application-specific interfaces
      • Similar to RPC, CORBA
    • Most data in XML
      • Descriptions in XML Schema

    RPC vs. Web Services

    • Remote Procedure Calls
    • Aim to hide the network
      • Distributed system looks like a local system
      • Some calls happen to go over the network
    • But network is important
      • Latency, bandwidth
      • Reliability – connection, nodes
    • RPC is harmful

    Why is RPC considered harmful?

    • Introduces semantics of a synchronous, blocking invocation
      • SOA needs a more flexible implementation technology
    • Usage of statically typed interfaces
      • Late binding is one of the premises of SOA
    • Restrictive, inflexible and doesn’t provide the required level of abstraction
      • Implicit introduction of the behavior which characterizes unified memory space solutions
    • Hinders resolution of the interoperability issues
      • Harder to adapt
    • An appropriate SOA underlying technology needs to shift from the single-machine-centric vision towards the network-centric vision

    CORBA vs. Web Services

    • CORBA = Distributed Objects
      • Encourages fine-grained design
    • Much more advanced than RPC
    • High barrier to entry
      • Caused by binary protocols, high core complexity
    • Initial big interoperability problems
      • Due to the above, and incomplete specifications

    Web Service Stack

    Overview

    • née Simple Object Access Protocol
      • In fact, simple messaging protocol
    • Current version: 1.2 @ W3C
    • Message structure
    • Processing model
    • Protocol bindings

    Messages

    • XML Envelope 
    • Body
      • Application payload
      • Faults
    • Headers
      • Metadata, processing instructions
      • May be marked as mandatory 
      • Possibly targeted at intermediaries

    Message Example

    SOAP Message Envelope

    SOAP Processing Model

    • Processing a message
      • Selecting headers targeted at me
        • The current intermediary or ultimate receiver
      • Checking for understanding
        • Do I understand all that is targeted at me and marked as mandatory?
      • Processing everything in some order

    SOAP Mandatory Headers

    • mustUnderstand="true"
      • The recipient must understand them
      • Implies agreement to act in accordance to the spec
      • Non-mandatory headers can be ignored
    • This mechanism enables gracious evolution
      • If a new feature can be ignored, its introduction won't harm older nodes
      • If a new feature must be understood, its introduction will be discovered early by older nodes, without unexpected behavior

    SOAP Protocol Bindings

    • Transporting the message over a network
    • Addressing
      • What an endpoint address looks like
    • Serialization
      • How to put the XML message in on-the-wire bits and bytes
    • Connection
      • How to send the bits to the endpoint

    SOAP HTTP Binding

    • Addressing: URIs
    • Serialization: HTTP message body
      • Media type application/soap+xml
    • Connection: TCP
    • Possibly Web-friendly
      • SOAP 1.1 only used HTTP POST

    SOAP MEPs

    • Message Exchange Patterns
    • Request-Response
      • Input message followed by output or fault
    • SOAP-Response
      • Request without SOAP (e.g. HTTP GET)
      • SOAP output or fault

    SOAP Summary

    • Still pretty simple even if the name doesn’t say so any more
    • Extremely extensible
    • HTTP binding for easy communication
    • The value of SOAP:
      XML and Processing Model

    SOAP Attachments

    • XML is nice, but… not binary
    • XOP: XML-binary Optimized Packaging
      • Binary data in XML logically in the tree
      • On serialization, it is outside, raw, efficient
        • MIME multipart message
    • MTOM: XOP for SOAP
      • Message Transfer Optimization Mechanism
      • Extends SOAP HTTP binding

    WS-Addressing

    • Simple routing protocol
    • Endpoint References for addressing
      • With parameters or metadata in addition to the service address
    • Message headers for routing & correlation
      • Many headers use endpoint references

    WSA Msg Info Headers

    • To – let the middleware deliver the message
    • From, ReplyTo, FaultTo – channels back
    • MessageID, RelatesTo – simple correlation
    • Action – semantics implied by the message

      <S:Header>
      <wsa:MessageID>unique ID </wsa:MessageID>
      <wsa:ReplyTo> endpoint </wsa:ReplyTo>
      <wsa:To> address </wsa:To>
      <wsa:Action> URI </wsa:Action>
      </S:Header>

    Overview

    • Web Service Description Language
      • Interface Definition Language (IDL) for Web Services
    • Current version: 2.0 @ W3C
      • Version 1.1 still in widespread use
    • Interface – reusable, abstract
      • Operations with MEPs
    • Binding – reusable, concrete
    • Service implements an interface
      • Endpoints use bindings

    WSDL Component Structure

    • The main component of WSDL is, of course, the Web service. A single WSDL file can describe multiple services.
    • A Web service can have a number of endpoints- network addresses where the service is accessible.
    • A service implements a single interface. In WSDL 1.1, the previous, unstandardized version, this was not enforced. An interface is an abstract view on what the operation does. A single WSDL file can describe multiple interfaces.
    • Interfaces contain descriptions of operations and faults. In WSDL 2.0, interfaces can one another, which basically includes all the operations and faults of the extended interface in the extending interface.
    • Since an interface is abstract, WSDL adds a binding component to specify how the interface is actually accessed over a network. Each endpoint of a service can have a different binding.
    • The structure of a binding follows the structure of an interface; the binding can even specify networking details for each operation or fault. 

    WSDL Component Structure

    Now let's take a closer look at the interface.

    • An interface operation contains message references and fault references. Message references refer to message exchange patterns . To illustrate: a request/response operation will have two message references, one for the request message, and one for the response message. Fault references in an operation point to fault definitions. In this way, fault definitions are shared among operations.
    • For describing the content of the messages and faults, WSDL contains a section called types that contains data schemas.
    • In XML Schema, the most common language, there are element declarations type definitions . Type definitions describe the inner structure of an element, whereas element declarations give elements their names.
    • Each operation message reference and each fault generally points to a single element declaration. The element declaration describes the body of the message, or the fault details of the fault.

    WSDL Interface

    • Design of application interface
      • Possibly extending other interfaces
    • Operations
      • Message exchange pattern (MEP)
      • Input/output messages, faults
      • Referencing XML elements defined in types
    • Faults
      • Used and reused by operations

    WSDL Interface Example


    <interface name=“Banking”> <operation name=“transfer” pattern=“http://www.w3.org/2004/08/wsdl/in-out”> <input element=“Transfer”/> <output element=“Balance”/> <outfault ref=“ InvalidBankAccount ”/> <outfault ref=“ InsufficientFunds ”/> </operation> <operation name=“balance” safe=“true” pattern=“http://www.w3.org/2004/08/wsdl/in-out”> <input element=“ BalanceRequest ”/> <output element=“Balance”/> <outfault ref=“ InvalidBankAccount ”/> </operation> <fault name=“ InvalidBankAccount ” element=“ InvalidAccountInfo ” /> <fault name=“ InsufficientFunds ” element=“ InsufficentFundsInfo ” /> </interface>

    WSDL Predefined MEPs

    WSDL Invocation MEPs

    • In-only: a single input message
      • No faults
    • In-out: a single input message, a single output message
      • A fault may replace output message
    • Out-only and Out-in mirror images of the above

    WSDL Messaging MEPs

    • Robust in-only: a single input message
      • May trigger a fault
    • In-optional-out: a single input message, possibly an output message
      • Either message may trigger a fault
    • Robust out-only, Out-optional-in mirrored

    WSDL Bindings

    • Networking details necessary for accessing the service
    • Copies interface structure
    • SOAP and HTTP bindings provided
      • SOAP binding:
        • XML message in SOAP envelope
        • Transport using a SOAP protocol binding (HTTP)
      • HTTP binding:
        • Web-friendly
        • XML message in payload, or as parameters in the URI

    WSDL Service

    • A logical node of the application
    • One interface
    • Multiple alternate endpoints
    • Endpoints may have different bindings
      • E.g. SOAP over HTTP for a public endpoint, and SOAP over JMS for the intranet
    • WSDL Service Example
      <service name=“HypoTirol ” interface=“Banking”>
      <endpoint name=“visible” binding=“HTTP” address=“http://ht.at/bankingSvc” /> <endpoint name=“tls ” binding=“SecureHTTP ” address=“https://ht.at/bankingSvc” />
      </service>

    WSDL Summary

    • Concrete service
    • Abstract and reusable Interface
    • Network binding
    • WSDL does not imply implementation
      • CORBA IDL requires objects
    • Exchange of XML business documents
    • Extensible in many ways

    UDDI

    • Universal Description, Discovery and Integration
    • A Web service registry API specification
      • Business-oriented service publication, discovery (initially limited search capabilities)
      • Itself has Web service interface
      • Useful for intranet registries
    • A failed public service
    • UDDI Structure
    • Business entity
      • Organization information, contact
    • Business Service
      • A group of related services
    • Binding Template
      • Information on how to access the service
    • tModel (technical model)
      • Any kind of specification, e.g. WSDL
      • Also for classification, categorization

    Overview

    • None of the previous solutions is addressing the non-functional aspects in the context of Web Services
      • e.g., a Web Service can be accessed only if a particular security constrains (like secure channel communication) hold.
    • WS-Policy is an XML-based set of specifications to advertise and specify service-related non-functional metadata
      • Security, Quality of service, Privacy, Transactional policies
    • WS-Policy main specifications
      • WS-Policy Framework
        • Provides model and syntax to describe and communicate policies
    • WS-Policy Assertions
      • Defines a common set of policy assertions for Web services
    • WS-Policy Attachments
      • General-purpose mechanisms for associating such policies with the subjects to which they apply
    • Capability vs. requirement policy

    A Policy

    • Policy is a collection of policy alternatives (OR)
      • Auth tokens: Kerberos OR X509
    • Policy alternative is a collection of policy assertions (AND)
      • Auth token AND secure channel
    • Policy assertions specify
      • traditional policies that will ultimately manifest on the wire (authentication scheme, transport protocol selection), and
      • critical to proper service selection and usage (privacy policy, QoS characteristics).
    • Two "operators" (XML tags) are used to make statements about policy combinations:
      • wsp:ExactlyOne - asserts that only one child node must be satisfied.
      • wsp:All - asserts that all child nodes must be satisfied.
    • The intersection is a new policy that complies with both their requirements/capabilities

    An Example of the Security Policy

    <wsp:Policy> <wsp:ExactlyOne> <wsse:SecurityToken> <wsse:TokenType>wsse:Kerberosv5TGT </wsse:TokenType> </wsse:SecurityToken> <wsse:SecurityToken> <wsse:TokenType>wsse:X509v3 </wsse:TokenType> </wsse:SecurityToken> </wsp:ExactlyOne> </wsp:Policy>

    Overview

    • WS-BPEL is an orchestration executable language for specifying interactions with Web Service
      • Defines an interoperable integration model for Web Service-based processes.
      • Describes high-level state transition interactions of a process.
    • The language supports following basic facilities:
      • Message exchanges,
      • Property-based message correlation mechanism,
      • XML and WSDL typed variables,
      • Structured programming-language concepts such as if-then-else, while, sequence, and flow,
      • Scoping system to allow encapsulation of logic with local-variables, fault-, compensation- and event- handlers,
      • Serialized scopes to control concurrent access to variables,
      • Language plug-in model which allows expression writing in the language such as XPath

    WS-BPEL v2.0 MetaModel

    Main elements

    • Process
      • Root element for a WS-BPEL process specification 
    • Variable
      • Holding messages that constitute a part of the state of a business process.
    • Activity
      • Perform the process logic.
      • Basic vs. structured activities.
    • PartnerLink
      • Models peer-to-peer conversational partner relationships.
    • Catch
      • Scope-based custom fault-handling activities. 
    • Correlation
      • Used to differentiate instances of the business processes.
      • The declaration of correlation relies on declarative properties of messages
    • onEvent
      • Scope-based concurrent answering to events
      • onEvent vs, onAlarm

    An Example

    • The operation of the process is very simple, and is represented in Figure: Purchase Order Process Outline. Dotted lines represent sequencing. Free grouping of sequences represents concurrent sequences. Solid arrows represent control links used for synchronization across concurrent activities. Note that this is not meant to be a definitive graphical notation for WS- BPEL processes. It is used here informally as an aid to understanding. On receiving the purchase order from a customer, the process initiates three paths concurrently: calculating the final price for the order, selecting a shipper, and scheduling the production and shipment for the order. While some of the processing can proceed concurrently, there are control and data dependencies between the three paths. In particular, the shipping price is required to finalize the price calculation, and the shipping date is required for the complete fulfillment schedule. When the three concurrent paths are completed, invoice processing can proceed and the invoice is sent to the customer.

    An Example (cont')


    <process name="purchaseOrderProcess" targetNamespace=http://example.com/ws-bp/purchase xmlns=http://docs.oasis-open.org/wsbpel/2.0/process/executable xmlns:lns="http://manufacturing.org/wsdl/purchase"> <partnerLinks> <partnerLink name="purchasing” partnerLinkType="lns:invoicingLT” myRole="invoiceRequester" partnerRole="invoiceService" /> <partnerLink name="shipping" partnerLinkType="lns:shippingLT” myRole="shippingRequester" partnerRole="shippingService" /> <partnerLink name="scheduling” partnerLinkType="lns:schedulingLT” partnerRole="schedulingService" /> </partnerLinks> <variables> <variable name="PO" messageType="lns:POMessage" /> <variable name="Invoice" messageType="lns:InvMessage" /> <variable name="shippingRequest"messageType="lns:shippingRequestMessage" /> <variable name="shippingInfo"messageType="lns:shippingInfoMessage" /> <variable name="shippingSchedule"messageType="lns:scheduleMessage" /> </variables> <faultHandlers> <catch faultName="lns:cannotCompleteOrder"faultVariable="POFault" faultMessageType="lns:orderFaultType”> <reply partnerLink="purchasing"portType="lns:purchaseOrderPT" operation="sendPurchaseOrder" variable="POFault" faultName="cannotCompleteOrder" /> </catch> </faultHandlers> …

    An Example (cont')


    … <sequence> <receive partnerLink="purchasing" portType="lns:purchaseOrderPT” operation="sendPurchaseOrder" variable="PO" createInstance="yes”> </receive> <flow> <links> <link name="ship-to-invoice" /> <link name="ship-to-scheduling" /> </links> <sequence> <assign> <copy> <from>$PO.customerInfo</from> <to>$shippingRequest.customerInfo</to> </copy> </assign> <invoke partnerLink="shipping" portType="lns:shippingPT" operation="requestShipping" inputVariable="shippingRequest" outputVariable="shippingInfo"> <sources> <source linkName="ship-to-invoice" /> </sources> </invoke> <receive partnerLink="shipping” portType="lns:shippingCallbackPT" operation="sendSchedule" variable="shippingSchedule”> <sources> <source linkName="ship-to-scheduling" /> </sources> </receive> </sequence> …

    An Example (cont')


    … <sequence> <invoke partnerLink="invoicing” portType="lns:computePricePT" operation="initiatePriceCalculation” inputVariable="PO”> </invoke> <invoke partnerLink="invoicing" portType="lns:computePricePT" operation="sendShippingPrice" inputVariable="shippingInfo”> <targets><target linkName="ship-to-invoice" /></targets> </invoke> <receive partnerLink="invoicing” portType="lns:invoiceCallbackPT” operation="sendInvoice" variable="Invoice" /> </sequence> <sequence> <invoke partnerLink="scheduling” portType="lns:schedulingPT” operation="requestProductionScheduling” inputVariable="PO"> </invoke> <invoke partnerLink="scheduling” portType="lns:schedulingPT” operation="sendShippingSchedule” inputVariable="shippingSchedule”> <targets><target linkName="ship-to-scheduling" /></targets> </invoke> </sequence> </flow> <reply partnerLink="purchasing" portType="lns:purchaseOrderPT” operation=”sendPurchaseOrder" variable="Invoice”> </reply> </sequence> </process>

    The Rest of the Specs

    •  Security: authentication, encryption
    • Reliable messaging
      • “Get the message there or tell me”
    • Transactions: ACID, Compensating
    • WS-BPEL: Scripting Web Services
    • Interoperability: WS-I Basic Profile
    • … and still more

    Virtual Travel Agency

    Blue Hotel WSDL


    <?xml version="1.0" encoding="utf-8" ?> <description xmlns ="http://www.w3.org/ns/wsdl" targetNamespace = "http://www.bluehotel.com/wsdl/BlueHotelService" xmlns:tns = "http://www.bluehotel.com/wsdl/BlueHotelService" xmlns:bhns = "http://www.bluehotel.com/schemas/BlueHotelService" xmlns:wsoap = "http://www.w3.org/ns/wsdl/soap" xmlns:soap ="http://www.w3.org/2003/05/soap-envelope" xmlns:wsdlx = "http://www.w3.org/ns/wsdl-extensions"> <documentation> This document describes the Blue Hotel Web service. </documentation>

    Blue Hotel WSDL (cont')

    <types> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.bluehotel.com/schemas/BlueHotelService" xmlns="http://www.bluehotel.com/schemas/BlueHotelService"> <xs:element name="checkAvailability" type="tCheckAvailability"/> <xs:complexType name="tCheckAvailability"> <xs:sequence> <xs:element name="checkInDate" type="xs:date"/> <xs:element name="checkOutDate" type="xs:date"/> <xs:element name="roomType" type="xs:string"/> </xs:sequence> </xs:complexType> <xs:element name="checkAvailabilityResponse" type="tCheckAvailabilityResponse"/> <xs:complexType name="tCheckAvailabilityResponse"> <xs:sequence> <xs:element name="roomType" type="xs:string"/> <xs:element name="rateType" type="xs:string"/> <xs:element name="rate" type="xs:double"/> </xs:sequence> </xs:complexType> <xs:element name="invalidDataError" type="xs:string"/> </xs:schema> </types>

    Blue Hotel WSDL (cont')


    <interface name = " BlueServiceInterface " > <fault name = " invalidDataFault " element = " bhns:invalidDataError "/> <operation name=" opCheckAvailability " pattern="http://www.w3.org/ns/wsdl/in-out" style="http://www.w3.org/ns/wsdl/style/iri" wsdlx:safe = "true"> <input messageLabel ="In" element=" bhns:checkAvailability " /> <output messageLabel ="Out" element=" bhns:checkAvailabilityResponse " /> < outfault ref=" tns:invalidDataFault " messageLabel ="Out"/> </operation> </interface>

    Blue Hotel WSDL (cont')


    <binding name=" BlueServiceSOAPBinding " interface=" tns:BlueServiceInterface " wsoap:protocol ="http://www.w3.org/2003/05/soap/bindings/HTTP/" type="http://www.w3.org/ns/wsdl/soap"> <fault ref=" tns:invalidDataFault " wsoap:code =" soap:Sender "/> <operation ref=" tns:opCheckAvailability " wsoap:mep = "http://www.w3.org/2003/05/soap/mep/soap-response"/> </binding> <service name=" BlueService " interface=" tns:BlueServiceInterface "> <endpoint name=" reservationEndpoint " binding=" tns:BlueServiceSOAPBinding " address="http://www.bluehotel.com/BlueService"/> </service> </description>

    Blue Hotel UDDI Binding Template


    <bindingTemplate bindingKey= "uuid:36F1B765-BDB3-4837-828D-8284301E5A2A" serviceKey= "uuid:40E6D5A8-3E16-4f01-99DA-035229685A40"> <description xml:lang="en"> SOAP binding for Blue Hotel service </description> <accessPoint URLType="http"> http://www.bluehotel.com/hotel:80/soap </accessPoint> <tModelInstanceDetails> <tModelInstanceInfo tModelKey= "uuid:AE1B645F-CF2F-491f-811A-4868705F5904"/> </tModelInstanceDetails> </bindingTemplate>

    Blue Hotel UDDI tModel


    <tModel tModelKey= "uddi:WE1B6Q5F-CF2F-491f-811A-4868705F5904" operator="http://www.bluehotel.com/hotel" authorizedName="George Blue"> <name>BlueHotelInterface Port Type</name> <description> An interface for the Blue Hotel service </description> <overviewDoc><overviewURL> http://www.bluehotel.com/services/ BlueHotelService.wsdl </overviewURL></overviewDoc> </tModel>

    Blue Hotel SOAP Request


    POST /InStock HTTP/1.1 Host: www.example.org Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:Envelope soap:encodingStyle= "http://www.w3.org/2001/12/soap-encoding" xmlns:soap="http://www.w3.org/2001/12/soap-envelope"> <soap:Body xmlns:bhns= "http://www.bluehotel.com/wsdl/BlueHotelService"> <bhns:checkAvailability> <bhns:checkInDate>2009-03-24</bhns:checkInDate> <bhns:checkOutDate>2009-03-30</bhns:checkOutDate> <bhns:roomType>Single</bhns:roomType> </bhns:checkAvailability> </soap:Body> </soap:Envelope>

    Blue Hotel SOAP Response

    HTTP/1.1 200 OK Content-Type: application/ soap+xml ; charset =utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:Envelope soap:encodingStyle = "http://www.w3.org/2001/12/soap-encoding" xmlns:soap ="http://www.w3.org/2001/12/soap-envelope"> <soap:Body xmlns:bhns = "http://www.bluehotel.com/wsdl/BlueHotelService"> <bhns:checkAvailabilityResponse> <bhns:roomType > Single </bhns:roomType> <bhns:rateType > Discount </bhns:rateType> <bhns:rate > 150.50 </bhns:rate> </bhns:checkAvailabilityResponse> </soap:Body> </soap:Envelope>

    Web Services Summary

    • Technology for service-oriented systems
    • Core: protocol + IDL (SOAP + WSDL)
    • Many extension specifications
    • Messaging paradigm
      • Sometimes RPC
    • Biggest benefit: XML
      • Vendor-neutral, platform-independent
      • Interoperable
      • Easy to begin and play with
      • But hidden in the frameworks 
        • Unless you're a developer of the framework

    Possible Extensions

    • Semantic Web Services
      • Automating the use of Web services
      • Using semantic technologies
    • RESTful services
      • Real Web services
      • Integrated with the Web

    References

    • G. Alonso, F. Casati, H. Kuno, V. Machiraju. Web Services, Concepts Architectures and Applications. Springer Verlag ISBN 3-540-44008-9
    • WSDL http://w3.org/TR/wsdl20
    • SOAP http://w3.org/TR/soap12
    • UDDI http://uddi.xml.org/
    • XOP http://w3.org/TR/xop10
    • MTOM http://w3.org/TR/soap12-mtom
    • WS-Addressing http://w3.org/TR/ws-addr-core
    • WS-Policy http://w3.org/TR/ws-policy
    • WS-BPEL http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html
    • OASIS http://oasis-open.org/
    • W3C http://w3.org/
    • http://en.wikipedia.org/wiki/Web_Services
    • http://en.wikipedia.org/wiki/Web_Services_Description_Language
    • http://en.wikipedia.org/wiki/SOAP
    • http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration
    • http://en.wikipedia.org/wiki/Business_Process_Execution_Language
    • http://en.wikipedia.org/wiki/WS-Addressing
    • http://en.wikipedia.org/wiki/XML-binary_Optimized_Packaging
    • http://en.wikipedia.org/wiki/WS-Policy
    • http://en.wikipedia.org/wiki/Web_services_protocol_stack

    Agenda

    • Motivation
    • REST Conceptual Overview
    • REST Web Service Technologies
      • HTTP
      • XML
      • JSON
      • AJAX
      • WADL
    • Illustration by a larger example
    • Extensions
    • Summary
    • Resources
     

    Motivation Examples

    •  YouTube video portal - free upload and download of videos
      • Exceeds 2 billion views a day1
      • 24 hours of video uploaded every minute
      • 70% of YouTube’s traffic comes from outside the U.S.
      • Google paid 1.6 Billion dollars for YouTube in 2006.

    The need for Web 2.0 services?

    • Large quantities of data are on the Web
      • The data needs to be managed in an appropriate manner.
      • Retrieved, queried, analyzed, transformed, transferred, stored, etc.
    • Easy integration of data and services
      • Web apps should work with the other Web apps
        • LinkedIn can import your
        • Facebook can import your Dopplr trips 
      • Mashups should be enabled
        • Easy service composition
      • Desktop apps should work with Web apps
        • Flickr uploadr , Google calendar update/sync
    • Technical solutions are needed to enable a truly Programmable Web
      • The solution can be seen in the form of Web 2.0 services (a.k.a. Web APIs)
    • Data providers are offering Web APIs
      • Web 2.0 services enabling easy access to the Web 2.0 data.
        • Google maps, Geonames, phone location…
        • Microformats (vcard, calendar, review…)
        • Data feeds  
      • Various functionalities are supported through Web APIs 
        • Publishing, messaging, payment…
      • Web 2.0 facilitates user involvement through “reverse” APIs (leveraging on human computation)
        • Amazon Mechanical Turk, ESP game… 
      • Overall Web APIs are powering the vision of the Web 2.0 as a collaborative and computational platform 

      Requirements

      • Requirements supported by Web APIs stem from the requirements addressed by any system following Web architecture: 
        • Simplicity
          • Low barrier of entry, fast adoption of Web APIs.
        • Extensibility
          • Allowing growth, flexibility, and composition.
        • Distributed hypermedia
          • Relying on the established concepts of hyperlinked content already accepted by Web users.
        • Scalability at the Web level
          • Should rely on technologies/protocols supporting scalable solutions.
        • Independent deployment
          • Coexistence of old and new

      Representational State Transfer (REST)

      • The requirements for WebAPIs are met by Representational State Transfer (REST)
        • A style of software architecture for distributed hypermedia systems such as the World Wide Web.
      • REST is basically client/server architectural style
        • Requests and responses are built around the transfer of "representations" of Web "resources".
      • HTTP is the main and the best example of a REST style implementation
        • But it should not be confused with REST

      RESTful Web Service definition

      • Another way of realizing services, other then SOAP/WSDL/UDDI approach
        • Closely follows the Web principles (REST principles)
      • A RESTful Web service...
        • ... exposes its data and functionality through interlinked Web resources indentified by URI and meant to be consumed by an autonomous program (i.e., machine).
        • ... is more data-centric, and less functionality-centric (as opposed to SOAP services).
        • ... embeds functionality of the service in the uniform HTTP interfaces for interaction: GET, PUT, DELETE, POST.
        • ... uses HTTP as the application protocol instead of SOAP
      • Like a Web application, but for machines.
      • Like WS-*, but focused on Web resources (i.e., data).
        WS-* stands for a variety of specifications related to SOAP-based Web Services.

      WS-* vs REST: A quick comparison

      • A SOAP service (WS-*) has a single endpoint that handles all the operations
        • It has to have an application-specific interface.
        • Functionality is hidden behind the interface.
        • Data is processed “behind” the interface by a service implementation.
        • The focus is on the functionality.
      • A RESTful service has a number of Web resources, so the operations are distributed over the resources
        • The functionality is “embedded and intertwined” with the data interaction protocol (i.e., HTTP).
        • The focus is on the data.
        • Data is “close” to the prosumer.

      Overview

      • Hotel booking workflow includes following steps:
        • Retrieve service description
          • Getting to know how to use the RESTful service
          • Usually written in natural text on some Web page
        • Submit search criteria according to description
        • Retrieve linked details of interesting hotels
        • Submit payment details according to selected rate description
        • Retrieve confirmation of booking
        • Retrieve list of user's bookings

      Hypermedia model

      WSDL model


      WS-* vs RESTful

      Technologies

      • Todays’s set of technologies used to empower RESTful paradigm:
        • HTTP as the basis,
        • XML and JSON for data exchange, and
        • AJAX for client-side programming (e.g. browser).
      • There exists an attempt to develop WSDL-like definition language for describing RESTful services
        • Web Application Description Language (WADL)

      Overview

      • HTTP
        • A protocol for distributed, collaborative, hypermedia information systems.
        • A request/response standard typical of client-server computing.
        • Currently dominant version is HTTP/1.1.
      • Massively used to deliver content over the Web
        • Web browsers and spiders are relying on HTTP.
      • The protocol is not constrained to TPC/IP
        • It only presumes a reliable transport.
      • Resources accessed by HTTP are identified by URIs (more specifically URLs), using the http URI schemes. 

      HTTP Request-response format

      • Request consists of
        • Request line, such as GET /images/logo.gif HTTP/1.1, which requests are source called /images/logo.gif from server.
        • Headers, such as Accept-Language: en
        • An empty line
        • An optional message body
      • Response consists of
        • Status line which includes numeric status code and textual reason phrase
        • Response headers
        • An empty line
        • The requested content

      HTTP Request methods

       
      • HTTP request methods indicate the desired action to be performed on the identified resource:           
        • GET
          • Requests a representation of the specified resource. GET should not be used for operations that cause side-effects (problematic with robots and crawlers). Those operations are called safe operations.
        • POST
          • Submits data to be processed (e.g., from an HTML form) to the identified resource. The data is included in the body of the request.
        • PUT
          • Uploads a representation of the specified resource.
        • DELETE
          • Deletes the specified resource.

      HTTP Example – Retrieving FOAF profile

      • Example is relying on curl which is a command line tool used to transfer data with URL syntax
        • Supports many protocols such as FTP, FTPS, HTTP, HTTPS, SCP, SFTP, etc.
        • More information can be found at http://curl.haxx.se
      • curl usage pattern is simple:

        $ curl -v http://www.google.at
        * About to connect() to www.google.at port 80 (#0)
        * Trying 74.125.87.104... connected
        * Connected to www.google.at (74.125.87.104) port 80 (#0)
        > GET / HTTP/1.1
        > User-Agent: curl/7.19.6 (i686-pc-cygwin) libcurl/7.19.6 OpenSSL/0.9.8o zlib/1.2.3 libidn/1.18 libssh2/1.2
        > Host: www.google.at
        > Accept: */*
        >
        < HTTP/1.1 200 OK
        < Date: Sun, 13 Jun 2010 15:13:15 GMT
        < Expires: -1
        < Cache-Control: private, max-age=0
        < Content-Type: text/html; charset=ISO-8859-1
        < Set-Cookie: PREF=ID=29937d127162f98f:TM=1276441995:LM=1276441995:S=wQcvUApkDnuGPQEa; expires=Tue, 12-Jun-2012 15:13:15
        < Server: gws
        < X-XSS-Protection: 1; mode=block
        < Transfer-Encoding: chunked
        <

      HTTP Example – Retrieving FOAF profile

      Srdjans-MacBook-Pro:~ skomazec$ curl -v http://www.sti-innsbruck.at/fileadmin/scripts/foaf.php?id=215

      * About to connect() to www.sti-innsbruck.at port 80 (#0)

      * Trying 138.232.65.141... connected* Connected to www.sti-innsbruck.at (138.232.65.141) port 80 (#0)

      > GET /fileadmin/scripts/foaf.php?id=215 HTTP/1.1

      > User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3

      > Host: www.sti-innsbruck.at

      > Accept: */*

      < HTTP/1.1 200 OK

      < Date: Sun, 06 Jun 2010 15:55:57 GMT

      < Server: Apache

      < X-Powered-By: PHP/5.2.0-8+etch16

      < Content-Length: 944

      < Content-Type: text/html; charset=UTF-8

      xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

      xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

      xmlns:foaf="http://xmlns.com/foaf/0.1/">

      Srdjan Komazec

      Srdjan

      Komazec

      7348d8f19c568de04c7718880f700fad7acdfab9

      * Connection #0 to host www.sti-innsbruck.at left intact

      * Closing connection #0

      Requested resource

      Overview

      • eXtensible Markup Language (XML) 
        • A set of rules for encoding documents electronically. 
        • De-facto standard (W3C Recommendation).
      • Ubiquitous presence on the Web and the Semantic Web
        • Storage and transportation of data (RDF/XML and SOAP),
        • Visualization of data (XHTML),
        • Application configuration (XML configuration files), etc.
      • As such it can not be avoided as a possible data format for Web 2.0 Web Services. 

      XML Characteristics

      • As opposed to JSON XML can be verified against a schema expressed in a number of languages such as Document Type Definition (DTD), and XML Schema:
        • the vocabulary (element and attribute names),
        • the content model (relationships and structure), and
        • the data types.
      • Founded on the standards laying in the core of Web
        • Uniform Resource Identifiers (URI)
        • Unicode
      • Well-formedness an XML document
        • Properly encoded legal Unicode characters,
        • Special syntax characters such as < and & are used only as markup delineation,
        • Element tags are correctly nested,
        • Element tags are case sensitive,
        • There exists a single “root” element.

      XML Example

        
      <?xml version="1.0" encoding="UTF-8"?> <Person> <firstName>John</firstName> <lastName>Smith</lastName> <age>25</age> <address> <streetAddress>21 2nd Street</streetAddress> <city>New York</city> <state>NY</state> <postalCode>10021</postalCode> </address> <phoneNumber type="home">212 555-1234</phoneNumber> <phoneNumber type="fax">646 555-4567</phoneNumber> <newSubscription>false</newSubscription> <companyName /> </Person>

      Overview

      • JavaScript Object Notation (JSON)
        • A lightweight computer data interchange format.
        • Specified in Request For Comment (RFC) 4627.
      • Represents a simple alternative to XML
        • A text-based, human-readable format for representing simple data structures and associative arrays (called objects).
      • Used by a growing number of services
      • JavaScript-friendly notation
        • Its main application is in Ajax Web application programming.
      • A serialized object or array
      • No namespaces, attributes etc.
      • No schema language (for description, verification)

      Data types

      • Number (integer, real, or floating point)
      • String (double-quoted Unicode with backslash escaping)
      • Boolean (true and false)
      • Array (an ordered sequence of values, comma-separated and enclosed in square brackets)
      • Object (collection of key:value pairs, comma-separated and enclosed in curly braces)
      • null

      Example

      {

        "firstName": "John",

        "lastName": "Smith",

        "age": 25,

        "address":{

        "streetAddress": "21 2nd Street",

        "city": "New York",

        "state": "NY",

        "postalCode": "10021",

        },

        "phoneNumbers": [

        {"type": "home", "number": "212 555-1234"},

        {"type": "fax", "number": "646 555-4567"}

        ],

        "newSubscription": false,

        "companyName": null

      }

      Overview

      • Asynchronous JavaScript and XML (AJAX)
        • A group of interrelated web development techniques used on the client-side to create interactive web applications
        • Web apps can fetch data from the server without refreshing the page 
      • AJAX is used to increase interactivity and dynamism of web pages
      • Since the technological base is partially shared AJAX and RESTful services make a good match
        • Enriching Web pages with the data operated through RESTful services

      AJAX Constituent technologies

      • (X)HTML and CSS
        • Information styling and marking.
      • Document Object Model (DOM)
        • A cross-platform and language-independent convention for representing and interacting with objects in HTML, XHTML and XML documents.
        • Objects are accessed through JavaScript
      • XMLHttpRequest object
        • Present in all major browsers
        • Method to exchange data between the server and browser in async manner
      • XML or JavaScript Object Notation - JSON
        • Interchange, manipulation and display of data.
      • JavaScript
        • Language which brings all these technologies together

      Overview

      • Web Application Description Language
        • No real uptake
        • W3C Member Submission
      • Application ( = our Web service)
        • Has resources
        • Resources have HTTP methods
        • Inputs and outputs can contain links to resources
      • WADL focuses on resources and hypertext
        • As opposed to operations (WSDL)

      Example

      Twitter REST API

      • Twitter is social networking and microblogging service that enables its users to send and read messages known as tweets.
      • Tweets are text-based posts of up to 140 characters displayed on the author's profile page and delivered to the author's subscribers who are known as followers.
      • Twitter has offered a comprehensive set of RESTful APIs to access core Twitter data: update timelines, status data and user information.
      • User sensitive data is protected by the HTTP Basic authentication mechanism.

      Twitter REST API – Retrieve User Timeline

      • Retrieves collection of 20 most recent tweets posted by user.

      Method:

      statuses/user_timeline

      Description:

      Returns the 20 most recent statuses posted from the authenticated user. It's also possible to request another user's timeline via the id parameter.

      URL:

      http://api.twitter.com/1/statuses/user_timeline.format

      Formats:

      xml, json, rss, atom

      HTTP Method:

      GET

      Parameters:

      id

      optional

      Specifies the ID or screen name of the user for whom to return the user timeline.

      since_id

      optional

      Returns only statuses with an ID greater than (that is, more recent than) the specified ID.

      max_id

      optional

      Returns only statuses with an ID less than (that is, older than) or equal to the specified ID.

      Twitter REST API – Retrieve User Timeline

      Srdjans-MacBook-Pro:~ skomazec$ curl -v http://api.twitter.com/1/statuses/user_timeline/google.xml * About to connect() to api.twitter.com port 80 (#0) * Trying 168.143.162.45... connected * Connected to api.twitter.com (168.143.162.45) port 80 (#0) > GET /1/statuses/user_timeline/google.xml HTTP/1.1 > User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3 > Host: api.twitter.com > Accept: */* > < HTTP/1.1 200 OK < Date: Sun, 06 Jun 2010 16:04:48 GMT < Server: hi < Status: 200 OK … < Vary: Accept-Encoding < Connection: close < <?xml version="1.0" encoding="UTF-8"?> <statuses type="array"> <status> <created_at>Sat Jun 05 15:24:45 +0000 2010</created_at> <id>15493557859</id> <text>#subsaturday @youtube channels: Forbes http://goo.gl/BKnh; NHLvideo http://goo.gl/kGlK; CelebrityPlaylists http://goo.gl/BL1y</text> <source>web</source> <truncated>false</truncated> <in_reply_to_status_id></in_reply_to_status_id> <in_reply_to_user_id></in_reply_to_user_id> <favorited>false</favorited> <in_reply_to_screen_name></in_reply_to_screen_name> <user> <id>20536157</id> <name>A Googler</name> <screen_name>google</screen_name> <location>Mountain View, CA</location> <description>News and updates from Google</description> <profile_image_url>http://a3.twimg.com/profile_images/77186109/favicon_normal.png</profile_image_url> <url>http://www.google.com/support/</url> …

      Twitter REST API – Showing Single Tweet

      • Retrieves a single tweet.
      • Status is a Web resource!!!

      Method:

      statuses/show

      Description:

      Returns a single status, specified by the id parameter below.  The status's author will be returned inline.

      URL:

      http://api.twitter.com/1/statuses/show/id.format

      Formats:

      xml, json

      HTTP Method:

      GET

      Parameters:

      id

      required

      The numerical ID of the status to retrieve.

      Twitter REST API – Showing Single Tweet

      Srdjans-MacBook-Pro:~ skomazec$ curl -v http://api.twitter.com/1/statuses/show/9627441680.xml * About to connect() to api.twitter.com port 80 (#0) * Trying 128.242.245.93... connected * Connected to api.twitter.com (128.242.245.93) port 80 (#0) > GET /1/statuses/show/9627441680.xml HTTP/1.1 > User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3 > Host: api.twitter.com > Accept: */* > < HTTP/1.1 200 OK < Date: Sun, 06 Jun 2010 16:09:31 GMT < Server: hi < Status: 200 OK < X-Transaction: 1275840571-6663-24393 < X-RateLimit-Limit: 150 … < Vary: Accept-Encoding < Connection: close < <?xml version="1.0" encoding="UTF-8"?> <status> <created_at>Thu Feb 25 14:23:37 +0000 2010</created_at> <id>9627441680</id> <text>From our European public policy blog, Amit Singhal explains just how tough search is: http://bit.ly/9UbBSD</text> <source>&lt;a href=&quot;http://bit.ly&quot; rel=&quot;nofollow&quot;&gt;bit.ly&lt;/a&gt;</source> <truncated>false</truncated> … <user> <id>20536157</id> <name>A Googler</name> <screen_name>google</screen_name> <location>Mountain View, CA</location> <description>News and updates from Google</description> <profile_image_url>http://a3.twimg.com/profile_images/77186109/favicon_normal.png</profile_image_url> <url>http://www.google.com/support/</url> <protected>false</protected> <followers_count>2266241</followers_count> …

      Twitter REST API – Posting new Tweet

      • Posts a new tweet.

      Method:

      statuses/update

      Description:

      Updates the authenticated user's status.  Requires the status parameter specified below.  A status update with text identical to the authenticated user's current status will be ignored to prevent duplicates.

      URL:

      http://api.twitter.com/1/statuses/update.format

      Formats:

      xml, json

      HTTP Method:

      POST

      Parameters:

      status

      required

      The text of your status update. URL encode as necessary.

      lat

      optional

      The location's latitude that this tweet refers to.

      long

      optional

      The location's longitude that this tweet refers to.

      in_reply_to_status_id

      optional

      The ID of an existing status that the update is in reply to.

      Twitter REST API – POST example

       

      <?xml version="1.0" encoding="UTF-8"?> <status> <created_at>Sun Jun 06 16:30:08 +0000 2010</created_at> <id>15566102131</id> <text>APITest</text> <source>&lt;a href=&quot;http://apiwiki.twitter.com/&quot; rel=&quot;nofollow&quot;&gt;API&lt;/a&gt;</source> <truncated>false</truncated> <in_reply_to_status_id></in_reply_to_status_id> <in_reply_to_user_id></in_reply_to_user_id> <favorited>false</favorited> <in_reply_to_screen_name></in_reply_to_screen_name> <user> <id>20307518</id> <name>Srdjan Komazec</name> <screen_name>skomazec</screen_name> <location>Innsbruck, Austria</location> <description></description> <profile_image_url>http://s.twimg.com/a/1275689140/images/default_profile_0_normal.png</profile_image_url> <url></url> <protected>false</protected> … <friends_count>3</friends_count> <created_at>Sat Feb 07 12:51:45 +0000 2009</created_at> <favourites_count>0</favourites_count> <utc_offset>3600</utc_offset> <time_zone>Vienna</time_zone> … </user> <geo/> <coordinates/> <place/> <contributors/> </status>

      Mashup –Wheather Bonk

      • Rich mashup with live weather, forecasts, webcams, and more on a Google Map.
      • Relies on a number of RESTful APIs
        • Google AdWords
        • Google Maps
        • hostip.info
        • Microsoft Virtual Earth
        • NASA
        • NOAA Weather Service
        • WeatherBug
        • Yahoo Geocoding
        • Yahoo Maps
        • Yahoo Traffic

      Mashup –Wheather Bonk (cont')



      Extensions

      • Semantic descriptions of RESTful services
        • hRESTS like a simplified WSDL to annotate Web pages describing service functionality
        • MicroWSMO adds semantic annotations (like SAWSDL)
        • Annotations can target WSMO-Lite descriptions
      • Discovery of RESTful services
        • Methods to analyze JavaScript in AJAX sites
        • The present trend is to pack RESTful functionality in the form of JavaScript libraries
          • E.g., Google AJAX Search API (http://code.google.com/apis/ajaxsearch)
        • Analysis of the code could unveil information about the used services

      Summary

      •   Web 2.0 technologies are ubiquitously present on today’s Web
        • Users are dominant producers of data.
        • Data is opened for further processing and integration.
      • Representational State Transfer (REST) is an architectural style especially suitable to exploit the Web of data and offer services on top of the data
        • The RESTful systems are compliant with the Web requirements.
        • REST brings the data residing on the Web near to the prosumers and the ways to process it.
      • RESTful-approach represents a natural way to offer Web Services as opposed to the SOAP-based Web Services
        • It builds on top of the architectural style which pervades the Web
        • It relies on the proven Web protocol (HTTP) and data formats (XML, JSON).
        • It integrates easily with the dominant visualization tool (a.k.a. Web browser) through JavaScript and AJAX.
      • RESTful-based services are dominating the Service Web
        • 68% RESTful services vs. 19% SOAP services*.
        • It is expected that the dominance of RESTful services will grow up in future.

      References

      • Fielding, Roy T.; Taylor, Richard N. (2002-05), "Principled Design of the Modern Web Architecture”, ACM Transactions on Internet Technology (TOIT) (New York: Association for Computing Machinery) 2 (2): 115–150
      • Fielding, Roy Thomas (2000), Architectural Styles and the Design of Network-based Software Architectures, Doctoral dissertation, University of California, Irvine
      • Web 2.0: http://en.wikipedia.org/wiki/Web_2.0
      • REST: http://en.wikipedia.org/wiki/REST 
      • JavaScript: http://en.wikipedia.org/wiki/Javascript 
      • AJAX: http://en.wikipedia.org/wiki/AJAX 
      • JSON: http://en.wikipedia.org/wiki/JSON 
      • Atom: http://en.wikipedia.org/wiki/Atom_(standard)
      • Mashups: http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid)
      • HTTP: http://tools.ietf.org/html/rfc2616

      Untitled



      Agenda

      • Introduction to Semantic Web
      • Architecture and languages
      • Semantic Web - Data
      • Extensions
      • Summary
      • References


      The Semantic Web is about…

      • Web Data Annotation
        • connecting (syntactic) Web objects, like text chunks, images, … to their semantic notion (e.g., this image is about Innsbruck, Dieter Fensel is a professor)
      • Data Linking on the Web (Web of Data)
        • global networking of knowledge through URI, RDF, and SPARQL (e.g., connecting my calendar with my rss feeds, my pictures, ...)
      • Data Integration over the Web
        • seamless integration of data based on different conceptual models (e.g., integrating data coming from my two favorite book sellers)

      Web Data Annotating


      Introduction

      • Data integration involves combining data residing in different sources and providing user with a unified view of these data
      • Data integration over the Web can be implemented as follows:
        • Export the data sets to be integrated as RDF graphs
        • Merge identical resources (i.e. resources having the same URI) from different data sets
        • Start making queries on the integrated data, queries that were not possible on the individual data sets.

      Export first data set as RDF graph

      • For example the following RDF graph contains information about book “The Glass Palace” by Amitav Ghosh

      Export second data set as RDF graph

      • Information about the same book but in French this time is modeled in RDF graph below

      Merge identical resources from different data sets

        • Merge identical resources (i.e. resources having the same URI) from different data sets

        Merge identical resources from different data sets

        • Merge identical resources (i.e. resources having the same URI) from different data sets

        Start making queries on the integrated data

        • A user of the second dataset may ask queries like: “give me the title of the original book”
        • This information is not in the second dataset 
        • This information can be however retrieved from the integrated dataset, in which the second dataset was connected with the the first dataset

        Web Architecture

        • Things are denoted by URIs
        • Use them to denote things
        • Serve useful information at them
        • Dereference them

        Semantic Web Architecture

        • Give important concepts URIs
        • Each URI identifies one concept
        • Share these symbols between many languages
        • Support URI lookup

        “Semantic Web Language Layer Cake”

        Identifier, Resource, Representation

          URI, URN, URL

          • A Uniform Resource Identifier (URI) is a string of characters used to identify a name or a resource on the Internet
          • A URI can be a URL or a URN
          • A Uniform Resource Name (URN) defines an item's identity
          • the URN urn:isbn:0-395-36341-1 is a URI that specifies the identifier system, i.e. International Standard Book Number (ISBN), as well as the unique reference within that system and allows one to talk about a book, but doesn't suggest where and how to obtain an actual copy of it
          • A Uniform Resource Locator (URL) provides a method for finding it
          • the URL http://www.sti-innsbruck.at/ identifies a resource (STI's home page) and implies that a representation of that resource (such as the home page's current HTML code, as encoded characters) is obtainable via HTTP from a network host named www.sti-innsbruck.at

          XML Schema Definition (XSD)

          •   A grammar definition language
            • Like DTDs but better
              • Uses XML syntax
            • Defined by W3C
          • Primary features
            • Datatypes
              • e.g. integer, float, date, etc…
            • More powerful content models
              • e.g. namespace-aware, type derivation, etc…

          Introduction

          • The Resource Description Framework (RDF) provides a domain independent data model
          • Resource (identified by URIs)
            • Correspond to nodes in a graph
            • E.g.: 
              • http://www.w3.org/
              • http://example.org/#john
              • http://www.w3.org/1999/02/22-rdf-syntax-ns#Property
          • Properties (identified by URIs)
            • Correspond to labels of edges in a graph
            • Binary relation between two resources
            • E.g.: 
              • http://www.example.org/#hasName 
              • http://www.w3.org/1999/02/22-rdf-syntax-ns#type
          • Literals
            • Concrete data values
            • E.g.: 
              • "John Smith", "1", "2006-03-07"

          Triple Data Model

          • Triple data model:
            <subject, predicate, object>
            • Subject : Resource or blank node
            • Predicate : Property
            • Object : Resource, literal or blank node
          • Example: 
            < ex:john , ex:father -of, ex:bill >
          • Statement (or triple) as a logical formula P(x, y), where the binary predicate P relates the object x to the object y. 
          • RDF offers only binary predicates (properties)

          Graph Model

          • The triple data model can be represented as a graph
          • Such graph is called in the Artificial Intelligence community a semantic net
          • Labeled, directed graphs
            • Nodes: resources, literals
            • Labels: properties
            • Edges: statements

          Introduction

          • RDF Schema (RDFS) is a language for capturing the semantics of a domain, for example:
            • In RDF:
              <#john, rdf:type, #Student>
            • What is a “#Student”?
          • RDFS is a language for defining RDF types:
            • Define classes:
              #Student is a class”
            • Relationships between classes:
              #Student is a sub-class of #Person
            • Properties of classes:
              #Person has a property hasName

          RDF Types

          • Classes:
            <#Student, rdf:type, #rdfs:Class>
          • Class hierarchies:
            <#Student, rdfs:subClassOf, #Person>
          • Properties:
            <#hasName, rdf:type, rdf:Property>
          • Property hierarchies:
            <#hasMother, rdfs:subPropertyOf, #hasParent>
          • Associating properties with classes (a):
            • “The property #hasName only applies to #Person
              <#hasName, rdfs:domain, #Person>
          • Associating properties with classes (b):
            • “The type of the property #hasName is #xsd:string
              <#hasName, rdfs:range, xsd:string>

          Example




          Introduction

          • RDFS has a number of Limitations:
            • Only binary relations
            • Characteristics of Properties, e.g. inverse, transitive, symmetric
            • Local range restrictions, e.g. for class Person, the property hasName has range xsd:string
            • Complex concept descriptions, e.g. Person is defined by Man and Woman
            • Cardinality restrictions, e.g. a Person may have at most 1 name
            • Disjointness axioms, e.g. nobody can be both a Man and a Woman
          • The Web Ontology Language (OWL) provides an ontology language, that is a more expressive Vocabulary Definition Language for use with RDF
            • Class membership
            • Equivalance of classes
            • Consistency
            • Classification

          Introduction (cont')

          • OWL is layered into languages of different expressiveness
            • OWL Lite: Classification Hierarchies, Simple Constraints
            • OWL DL: Maximal expressiveness while maintaining tractability
            • OWL Full: Very high expressiveness, loses tractability, all syntactic freedom of RDF
          • More expressive means harder to reason with
          • Different Syntaxes:
            • RDF/XML (Recommended for Serialization)
            • N3 (Recommended for Human readable Fragments)
            • Abstract Syntax (Clear Human Readable Syntax)

          Example: The Wine Ontology

          • An Ontology describing wine domain
          • One of the most widely used examples for OWL and referenced by W3C.
          • There is also a wine agent associated to this ontology that performs OWL queries using a web-based ontological mark-up language. That is, by combining a logical reasoner with an OWL ontology.
          • The agent's operation can be described in three parts: consulting the ontology, performing queries and outputting results.

          Example: The Wine Ontology Schema

          Querying RDF

          • SPARQL
            • RDF Query language
            • Based on RDQL
            • Uses SQL-like syntax
          • Example:

          Queries

          • PREFIX
            • Prefix mechanism for abbreviating URIs
          • SELECT
            • Identifies the variables to be returned in the query answer
            • SELECT DISTINCT
            • SELECT REDUCED
          • FROM
            • Name of the graph to be queried
            • FROM NAMED
          • WHERE
            • Query pattern as a list of triple patterns
          • LIMIT
          • OFFSET
          • ORDER BY

          Example Query 1

          “Return the full names of all people in the graph”

          result: 

          fullName

          =================

          "John Smith"

          "Mary Smith"  

          Example Query 2

          “Return the relation between John and Mary”

          result:

          p

          =================

          <http://example.org/#marriedTo>

          Example Query 3

          “Return the spouse of a person by the name of John Smith”

          result:

          y

          =================

          <http://example.org/#mary>

          SPARQL and Rule languages

          • SPARQL
            • Query language for RDF triples
            • A protocol for querying RDF data over the Web
          • Rule languages (e.g. SWRL) 
            • Extend basic predicates in ontology languages with proprietary predicates
            • Based on different logics
              • Description Logic
              • Logic Programming

          Introduction

          • A set of dialects to enable rule exchange among different rule systems

          Goals

          • Exchange of Rules 
            • The primary goal of RIF is to facilitate the exchange of rules
          • Consistency with W3C specifications 
            • A W3C specification that builds on and develops the existing range of specifications that have been developed by the W3C
            • Existing W3C technologies should fit well with RIF
          • Wide scale Adoption
            • Rules interchange becomes more effective the wider is their adoption ("network effect“)

          Architecture