Business Process Engineering

Module 1 - Web Services

Unit 1 – Web Protocols

Ernesto Damiani

Università di Milano

Lesson 3 – Site Design

Basic Elements of Web Service Design

1. Resources: primal elements of the Web

2. URLs: identify every resource

3. Content Types: adaptability and survival on the Web

4. Information Exchange: trade documents, not arguments

5. Links: connect, don't encapsulate

6. Payload versus Protocol: the right information in the right place

7. Viewpoints: information from any perspective, in any direction

Resources

• Resources are the basic building blocks of the Web

• Every activity on the Web is one of CRUD (Creating, Retrieving, Updating and Deleting) resources

• A resource is a conceptual entity

– It's not about the Web service, but it's about the information

– A Web service is only a means to get at a resource

– There's nothing special about Web services: the focus shouldn't be on Web services, it should be on resources

Resources and information

• Like information, resources are abstract, conceptual things concretely "represented" in many different forms

• While information are represented in text form, in audio form and in pictorial form, resources are represented in HTML form, in XML form and in MP3 form

Identifying Resources

• The Boston airport (BOS) has these airplanes (tail number): FX12 and BA99. FX12 flies this route: BOS-LAX. BA99 flies this route: BOS-ALT

– The resources are:The Boston airport, BOS

Airplane with tail number FX12

Airplane with tail number BA99

Route BOS-LAX

Route BOS-ALT

Boston Airport Resources

BOS

FX12

BOS-LAX

BA99

BOS-ALT

URL and Resource Identification

• The Web is all about resources. If you can't address a resource, you can not do anything with it!

• Law of resources: each resource must be identified by a URL

– This law is fundamental to the Web that Tim Berners-Lee calls Web Design, Axiom 0

• Benefits:

– Individually reachable resources are discoverable by search engines (e.g., Google)

– Individual resources may have individualized metadata for cataloging

Web Design, Axiom 0

• Axiom 0: all resources on the Web must be uniquely identified by a URI

resource1URL1

resource2URL2

resource3URL3

Identification of the Airport Resources by URLs

Content Types (1)

• In nature, variety breeds adaptation which means survival

• Many different types of clients use the Web and require information in different "representations"

• Representations are expressed through content type (MIME)

– HTML, GIF, JPEG, XML, MP3, MPEG, SVG, Text, CSS, SOAP

Content Types (2)

• A Web service lives in an ecosystem, serving many different types of clients, and therefore must work with information in a representation matched to each

• The more content types a Web service offers, the more clients can use the service

– (A Web service that offers only one content type is destined for extinction)

Resources and Representations

• A resource is a conceptual entity, but the contents you work with are real

• Issue a URL to a resource and you get back a (real) representation of it

• The power of the Web comes from navigating through conceptual resources, but working with real representations

Example of Resource and Representation (1)

Boeing747Aircraft

BrowserClient

Boeing747.html

Fuel requirementsMaintenance schedule...

http://www.aircraftsInc.com/boeing747

Example of Resource and Representation (2)

• The client invokes a Web resource by issuing its identifier (URL)

• A representation of the resource is returned (in this case as an HTML document)

• The content type (MIME) a resource should return is dynamically based on the capabilities or desires of the recipient and the nature of the resource

Content (MIME) Types

• There are over 350 content types

HTMLTextXMLSOAPGIFCSSSVGJPEGMPEG…

text/htmltext/plainapplication/xmlapplication/soap+xmlimage/giftext/css application/svg+xml image/jpegvideo/mpeg…

MIME TypeCommonName

Information Exchange

• The Web is a new programming environment

• The challenge of the Web is to think in terms of information exchange with resources

• On the Web you work with resources in the form of documents with specific content types

• The architectural principles underlying the scalability of the Web dictate that documents avoid information specific to the intended processing, the destination service, or other details of implementation

Bridge Crossing (1)

Resources, information exchange, content types, URLs

Programming the Web

Bridge Crossing (2)

• Structured programming taught us to break a problem into logical units of code (subroutines)

• OOP introduced the manipulation of objects in place of blocks of processing

Coupling versus Loose Coupling (1)

Coupling versus Loose Coupling (2)

• Contains process-specific info

– e.g., the name of the subroutine

• It couples the client to the Web service

• Tainted by prior experience with OO and structured programming

Coupling versus Loose Coupling (3)

Coupling versus Loose Coupling (4)

• Documents free of processing-specific information

– client and service can evolve independently

– the document (data) can be used by other services

– the document (data) can be used in unanticipated ways

Links

• Links enable a scalable, loosely coupled network of information

• Links facilitate easy, quick assembly of information

• Changes to document content instantly propagate to any document that references to it

• The relations implied by links are themselves information

• Don't embed information! Link to information!

Link to Fuel and Maintenance

• The Web paradigm is a network of information; thus, the representation doesn't embed the fuel and

maintenance data, but it links to it

Boeing747Aircraft

BrowserClient

Boeing747.html

Fuel requirementsMaintenance schedule...

http://www.aircraftsInc.com/boeing747

Payload versus Protocol (The Right Information in the Right Place)

• The payload is the body of the message and is specific to the transaction

• The protocol is the header of the message and is general information for the transport

• By design, information in the payload is hidden

– Application-specific information should be placed in the payload

• By design, information in the header is visible to all

– Information applicable to the Web community at large should be placed in the header

Terminology: Header and Payload

Advantages

• The Web doesn't have a first page, a last page, sections or chapters

– It allows you to jump into its huge collection of information at any point

• You land at a web site, you examine the links and then you choose a link which defines your viewpoint and your organizing principle

• Unlike taxonomies, which define single viewpoints, the Web embraces many organizations of information

• Designing information resources is not a matter of deciding on the right hierarchy or organization, but ensuring that links exists for all meaningful relationships between individual elements of information

Viewpoint of the Airport Ground Crew

FX12

BOS-LAX

BA99

BOS-ALT

Viewpoint of the Pilot

Links enable both viewpoints!

BOS-LAX

FX12

BOS-ALT

BA99

Link and your Mental Model

• Suppose that you are a member of the airport's ground crew and your mental model is that "an airplane flies a route“, in the information for a route you may be tempted to just provide information about the route, but resist the temptation! Insert a link to the plane that flies the route and it will support other mental models, e.g., the pilots

Plane: BA99

BOS-ALT.htmlFINE