Abstract

While Web Services have received a lot of attention, they are only one specific set of technologies for implementing loosely coupled heterogeneous distributed systems. The term Web-based services used in this course is less focused on a specific set of technologies. Instead, it focuses on general principles of how to design services in a loosely coupled environment based on Web technologies.

About Me

• Apprenticeship at Hahn-Meitner-Institut Berlin (HMI) (85-88)
• Computer Science at Technical University of Berlin (TUB) (88-91)
  • working on DAPHNE, an SGML-based document preparation system
• Ph.D. at ETH Zürich (92-97)
  • thesis on Group and Session Management for Collaborative Applications
• Post-Doc at ICSI, Berkeley (97/98)
  • book on Technical Foundations of the World Wide Web
• Various activities back in Switzerland (98-06)
  • teaching at ETH Zürich and FHNW
  • working as independent consultant (training, courses, consulting)
  • research in various XML-related areas
  • starting and leading the ShaRef project

About this Course

• Course Web page: http://dret.net/lectures/services-fall06/
• Course mailing list: subscribe at majordomo@sims.berkeley.edu
  • no subject (leave blank)
  • body of message: subscribe wbs
• Grading is letter grade only

About these Slides

• Generated from XSLidy XML
  • all Slidy presentations are generated from this source
  • 242.xml for importing the syllabus into SylViA
  • toc.html for displaying the summary on the course's Web page
• Designed for online presentation and use (lots of links!)
  • for printing, use a (all slides), and s (smaller font) a couple of times
• A good real-world example for XML applications
  • XSLidy is useful, but there is no interface (XML editing only)
  • SylViA is useful, but there is no interface (XML editing or XSLidy export)
  • SylViA is over-modeled in some areas and too monolithic
  • UCB-wide management of course material and syllabi would be great

Additional Resources

• My Online Glossary at http://dret.net/glossary/
  • suggestions, updates, corrections are very welcome
  • another exercise in how to use XML and XSLT for information management
• My bibliography at http://dret.net/biblio/
  • suggestions, updates, corrections are very welcome
  • produced by an XML-centric system for managing bibliography data
• The World Wide Web Consortium (W3C)
  • the organization which invented HTTP and SOAP
  • as well as many other technologies covered in this course
• The Organization for the Advancement of Structured Information Standards (OASIS)
  • the organization which controls many important Web Service specifications

Web vs. Internet

• The Web has become synonymous with the Internet
  • the Internet is a global network supporting end-to-end data transmission
  • the Web is a distributed hypermedia system that uses Internet data transport
• Other services are also using the Internet
  • e-mail for asynchronously sending messages
  • IM applications for synchronously sending messages
  • VoIP used by Internet phones
  • FTP for transmitting files
  • Web Services for transmitting data
• This lecture is about services which:
  1. consume or provide services from/on the Web
  2. use technologies originating in the Web area

*2* Acronyms

• A number of *2* acronyms have become popular
  • B for Business (B2B)
  • C for Consumer or Citizen (B2C)
  • G for Government (G2C or G2G or G2B)
  • P means something completely different (peer-to-peer)
• Anything with a C in it usually means HTML Forms
  • services offered on the Web (browser GUI)
  • the interface is a Web interface (i.e., designed for human users)
  • the service can be implemented in any way (print, e-mail, API)
• Anything without a C in it usually means Web Services
  • services offered on the Internet (through an API)
  • the interface is a Web Service (using XML/HTTP)
  • the service implementation is API-driven

Goals of this Course

• Present the whole spectrum of Web-based services
  • look at the evolution and the connections of technologies
  • look at some side-effects (such as design issues)
• Putting Web Services into context
  • implementing a SOAP interface on top of an API is easy
  • designing it in a way that it is open and extensible is hard
  • managing evolution and a heterogeneous environment is even harder

The Web as User Interface

• The Web started with Static Web Pages
  • HTML files were created as static files in a file system
  • ISINDEX was the only dynamic aspect of the Web
• Common Gateway Interface (CGI) was the first link to IT systems
  • a standard interface for how to connect a Web server and another process
  • the Web became just another interface for an IT system
• Various other ways were invented to create content dynamically
  • Server-Side Includes (SSI) for very basic functions
  • more powerful scripting languages such as PHP
  • binding to established languages such as Java

Dedicated Humans-only Services

• Thanks to spammers, services are often misused
  • many Internet services are free-of-charge
  • many Services on the Web are free-of-charge
  • but there is some business model behind them
• How can you keep computers from acting as humans?
  • Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA)™
  • not perfect, but good enough to prevent large-scale attacks
  • problems with accessibility and language-specificity

Service Infrastructures

• Services are increasingly composed out of other services
  • checking and approving a credit card transaction
  • providing shipping information for ordered items
  • service design should not be limited to one particular use case
• The Web happened in parallel with more IT developments
  • an increasing amount of services have IT-based interfaces
  • Web technologies provide a good way for providing interfaces
• Web-based interfaces have been successful
  • HTML pages are the majority (Java applets or Shockwave are exceptions)
  • Web services are more successful than any other integration technology
  • using standards is a good idea, deviation generally not

Services should be Reusable

• Services should not be limited to a specific interface
  • services are a fundamental concept of many businesses and activities
  • interfaces might change, but this should not affect the service itself
• Services should be able to function as sub-services
  • well-defined interfaces and semantics
  • robust with regard to versioning issues
• Services should be designed like software components
  • standard methods for describing the interface
  • encapsulation of implementation issues
  • in addition to components: independent from an execution environment
  • in addition to components: more coarse-grained

Software Components

• multiple-use
  • designed to be as flexible as possible
• non-context-specific
  • no assumptions about execution or usage
• composable with other components
  • using interfaces which are easily reusable
• encapsulated (non-investigable through its interfaces)
  • impossible to do optimizations because of implementation details
• units of independent deployment and versioning
  • development is done as necessary, not as regulated by the context

The WAP 1.0 Lesson

• How to not design an environment for services
• WAP 1.0 was marketed as the Internet in your pocket
• In fact, it was built on a stack of new protocols
  • Internet protocols tweaked in an incompatible way
  • non-HTML markup language (called WML) for content
  • the need for WAP gateways transcoding content (no end-to-end transparency)
• WAP 1.0 was a complete failure
  • iMode, on the other hand, was a success
  • WAP 2.0 is now built on top of Internet technologies
  • the separation between Web and Mobile Web is disappearing
• Lesson: Reuse is good. Parallel universes are bad.
• What WAP did: XML became even more popular

Definition: Web Service

• A service providing an API which is based on Web technologies
  1. the transport layer (how data is transported between peers)
  2. the protocol (how peers exchange control information)
  3. the payload format (how peers exchange application-level information)
• A Web Service is intended to be used by a machine
  • a Web Server is used by a human user
  • but only indirectly by using a machine…
  • which means that a Web Server provides a Web Service

Web Server Web Services

• Web Servers do more than just serving files
  • in the beginning, HTTP was file retrieval
  • HTTP interactions can be more complex, including Content Negotiation
  • one click for a human can be much more for the Web
• HTTP transmits additional information about resources
  • media types
  • caching information
  • language information
• HTTP can be used for complex interactions
  • Proxies may be chained together to complete the request
  • HTTP interactions can be more complex, including Content Negotiation
  • one click for a human can be much more for the Web

Redefinition: Web Service

• Web Services provide machine-oriented services
  • they have all properties described in the Web Service Definition
  • the interactions are designed to be used in an machine-oriented environment

HTTP Web Services

• A very basic approach for exchanging XML data
  • Transport layer: TCP
  • Protocol: HTTP
  • Payload format: HTML/XML
• Uses plain HTTP between applications
  • use a service for providing data
  • publish selected data
  • consume it in another application
  • a minimal amount of overhead
  • limited to simple publish/subscribe-style scenarios

XML-RPC Web Services

• Sending XML-encoded RPC calls over HTTP
  • Transport layer: HTTP
  • Protocol: HTTP/XML-RPC
  • Payload format: XML-RPC
• Gained some popularity because of its simplicity
  • mapping function signatures to XML-RPC is easy
  • minimal processing requirements
  • small set of supported data types (no complex documents)

SOAP Web Services

• A complex, extensible and powerful approach to Web Services
  • Transport layer: HTTP
  • Protocol: SOAP (+ WS-*)
  • Payload format: XML (user-defined schema)
• Adds well-defined formats for service description
  • enables automated support for marshaling and unmarshaling
• Extensible protocol
  • WS-* specifications add functionality for new scenarios
  • basic tools and technologies remain usable

What does Web mean?

• It used to mean browsers displaying HTML pages
  • these browsers were intended for human users only
  • all interaction was HTML-based (click link, retrieve page)
• Today it means anything using Web technologies
  • this includes the old-fashioned Web
  • as well as new human-oriented Web technologies (AJAX)
  • and some machine-oriented technologies (Web Services)

Design of Web-Based Services

• Well-designed services have a greater probability of success
  • as a service in the scenario for which they were designed
  • thus influencing the success of the whole scenario
  • being reusable and thus supporting future developments
• Web-based services design is a new field of research
  • Services Science, Management & Engineering initiative
  • some technical aspects (computer science)
  • other important aspects (economics, law, organizational sociology)

Platform-Independent Software Services

• Component-oriented software development
  • many component specifications are platform-dependent (COM, JavaBeans)
  • many platform-independent components are not very wide-spread (CORBA)
  • component-based design often leads to fine-grained structures
• SOA design should be more coarse-grained than components
  • coarse-grained services are closer to the business process view
  • ideally, SOA services can be composed into business processes
  • even more ideally, business process reengineering does not affect the services

Loose Coupling

• Services should be implemented as components
  • clean interfaces with no visible implementation details
  • versioning a service should not break the infrastructure
• Coarse-grained scales better
  • finer grained services reveal more internals (which may change)
  • the ideal grain size is very hard to determine (but very important)

Coarse-Grained Services

• Real-life service users want simple interfaces
  • users don't want to be exposed to the details of service implementation
  • users would need to be re-educated when the implementation changes
• Web-based service users want simple interfaces
  • easier integration into own projects
  • less fragile and less likely to need constant updates
• Document engineering should provide the interfaces
  • service users send documents providing all necessary information
  • the service works on the input document
  • service users receive documents containing the results
  • a very Web-like way of designing and implementing services

Web Service Design

• Current Web Service design maps APIs to Web Service APIs
  • changes in the API occur frequently and require a redesign
  • possible (but expensive) in closed systems
  • impossible in open systems
• Representational State Transfer (REST)
  • no system has scaled as well as the Web
  • there is no Web Server API, every interaction is resource-oriented
  • REST is a design approach, not a technology
  • REST services can be implemented with HTTP or SOAP

Course Outline

• Foundations
  • Web Technologies and Server-Side Web Technologies
• Web Services in different flavors
  • HTTP Web Services and Simple Object Access Protocol (SOAP)
• Infrastructures and additions for Web Services
  • Web Services Description Language (WSDL) and Web Service Protocols (WS-*)
• Composing services
  • BPEL and Mashups
• Design issues
  • Representational State Transfer (REST) and XML Schema design

Service Scenario

• Assignments use a bibliography service
  • individually owned databases of hundreds or thousands of references
  • designed to be reusable in different scenarios
• Different approaches for using the service
  • access through an HTML forms interface
  • retrieve additional information from Amazon
  • mashup the bibliographic information with Google Maps