web services foundations

Web Services Foundations

© Copyright 1999–2004 IONA Technologies PLC. All rights reserved

IONA Technologies PLC IONA Technologies Inc. The IONA Building 200 West Street Shelbourne Road Waltham, MA 02451 Dublin 4, Ireland USA Telephone: + 353 1 637 2000 Telephone: +1 781 902 8000 Fax: + 353 1 637 2888 Fax: +1 781 902 8001 IONA Technologies Japan, Ltd. Training: [email protected] Akasaka Sanchome Building 7/F Sales: [email protected] 3-21-16 Akasaka, Minato-ku FTP site: [email protected] Tokyo, Japan 107-0052 Web: www.iona.com Telephone: +813 3560 5611 Fax: +813 3560 5612

Table of Contents

Chapter 0: Introduction, Overview, Schedule 1 Chapter 1: Web Services – Setting the Stage 5 Chapter 2: Why Web Services? 17 Chapter 3: Web Services Technologies 23 Chapter 4: Web Services Tools and Demo 57 Chapter 5: Service Oriented Architecture 87 Chapter 6: Web Service Design Aspects 99 Chapter 7: Advanced Topics 109 Chapter 8: Summary, References and Useful links 119

© Copyright 1999 - 2004 IONA Technologies PLC. All rights reserved.

©Copyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 1

1

Web Services FoundationsSean Baker

Eric NewcomerWolfgang Schulze

Rich BonneauAdrian Trenaman

IONA Technologies

Version 8

0-2

What you will see/learn …

• Real Web services in action• An overview of the major WS technologies• Live demos of typical WS development tools• Insight into Service Oriented Architecture as a

way to design Web Service-based systems– Design and best practices

• An overview of advanced Web Services topics and futures


0-3

What This Course is About

• In scope– Grand tour of Web service technology– Using services to migrate and contain legacy applications and

legacy middleware– Consolidating redundant functionality – Incrementally building enterprise-wide infrastructure

• Close, but out of scope– Methodology– Model-Driven Architecture– Web (development) technology in a broader sense– “Classical” B2B (RosettaNet, ebXML, EDI, UCCnet,…) – Utility computing, Grid computing, agent technology

• Intended Audience

0-4Course Schedule

Break3:15Service Oriented Architecture and Web Services52:30

Web Services Design Aspects63:30

Why Web Services?29:50Break10:15

87

4

3

10

Chapter Number

Advanced Web Service Topics and Futures4:15Summary/References/Useful Links/Q&A4:45

WS – Development Tools and Demo1:00Lunch12:00

WS Technologies: XML, SOAP, WSDL, UDDI 10:30

Setting the stage: An introductory WS demo9:15Overview and Schedule9:00

TopicsTime


0-5

Acronyms (For Reference Purposes)

• SOA Service Oriented Architecture• UDDI Universal Definition, Discovery and Integration

(of Web Services)• W3C World Wide Web Consortium• WS Web Service• WSDL Web Service Description Language• WS-I Web Services Interoperability organization• WSID Web Services Interoperability Demonstration• XML Extensible Markup Language• XSLT XML Stylesheet Language (Transform)


1

Chapter 1Web Services – Setting the Stage

A simple, live, interactive demo illustrating Web Services as XML document exchange between a client and a server

Version 12

1-2

A simple live interactive scenario

• Stock quote example– Supply a symbol– Get a price quote back

• How ?– Build up the Web Service XML request document– Invoke the service, supplying the document – Review the XML response document


1-3

Let’s go – using a simple environment• We could use any number of tools for this demo

but to show the simplicity of WS, we will use:

– A simple text editor (Text Pad) to construct the XML document

– A small part of the popular XMLSPY tool: to invoke the service and review the results

– A remote, independent Web Service server to return the quotes

• The SOAP protocol will carry the message to the service, and the reply back to the client

1-4

How will all of this work? A Web Services Infrastructure

WS Client WS ServerXML document

XML document

Web Service

SOAP Support

SOAP Support

SOAP message

SOAP message

HTTP Support over network


1-5

The simplest of data - a stock symbol!

1-6

Self-identify as a stock symbol


1-7Extend our XML document to indicate the type of message (request)

1-8Wrap the document within a SOAP message (envelope and body)


1-9

One “technical detail” re namespaces

1-10Transmit to a waiting Web Service Server. We’ll use XMLSPY to transmit the SOAP message

FORD</


1-11

Response message from server

1-12Change the symbol to “IBM” and re-send.Here’s the response:


1-13Here’s a more complex document returnedfrom a different stock quote service:

1-14How did we know what structure of XML to send; and what we’d get back in response?

• The WSDL (Web Services Description Language) file specified the Stock Quote service:– Operations – names and parameters– Message formats– Endpoint URL

• Let’s look quickly at the WSDL file for the original simple Stock Quote service


1-15

Screen shot of WSDL file

1-16Web Service Technologies RelationshipsRun time vs Design Time

E.g.,HTTP

Client WebService

SOAPRequest

SOAPResponse

XML

Run

time

exec

utio

n

WSDL Specifies …

Operations,Structure and

Typing of Messages

EncodingAnd Transport of

Messages

PhysicalEndpoint

ServiceCommunicationsRequirements:

Des

ign

and

Dep

loy

time

XML Schema


1-17

What is the Web Service Server Doing?

• The typical server pattern …

– Wait on arriving XML documents contained within a SOAP envelope

– Extract and analyze the document– Interact with other software components to complete

the processing of the document– Optionally return another XML document in response

WebService

SOAPRequest

SOAPResponse

server

1-18

Points to be made about demo

• This is not the same as Web pages– No browsers, web servers, HTML, CGI, ASP pages,

GUIs, etc• Rather – exchange of XML documents between

“co-operating” programs– Web Services is intended for program-to-program

communications – Not human-to-web page communications


1-19

../cont.

• Uses newer information exchange standards– XML technologies for documents

• ASCII, human-readable, self-describing, extendable, simple, and portable across OS, hardware, programming languages

– SOAP as vehicle for transmitting/receiving XML documents– WSDL to specify definition/structure/rules of the service

• Messages/documents • Location of service for access• Transport options, etc.

• More enterprise-level WS standards emerging for such aspects as transactions, security, choreography of services, etc.

1-20

Points to be made about demo (cont.)

• We accessed the service using Web Services

– Web Services is an “interfacing technology”

→ It is not a technology for implementing servers (or clients)


1-21

Final points …• Can easily read, edit, re-transmit and interpret the XML

documents and SOAP messages - because it’s all text• There are simple tools to help you to make WS calls

from inside your programs, and to accept such calls into your server programs– Create and send SOAP messages from the client programs– Accept and handle them in server programs

• Remember that some XML documents can be very complex (as we’ve seen)– So these tools can save you a lot of effort

• We’ll see some of these tools in later chapters

1-22

Transition to the rest of the course

• We will explore in greater detail the list of technologies touched upon in this short demo:– XML technologies – how to represent documents

• Including XML Schema (not introduced yet)– SOAP – how to wrap documents to be sent out– WSDL – how to describe services and document exchanges– UDDI (not discussed yet) – how to register, find services

• Also we will present alternative solutions and approaches beyond what we have seen– Other transports, protocols, options, etc.– Best practices for designing WS-based systems


Chapter 2Why Web Services?

Version 7

2-2BrainstormingWhy might I want to use Web Services?

Some of the vague reasons seen often in the press:

• I read so much about it, and I’m afraid to get left behind• Our CIO told me to• Our competitor claims to have saved 2 million dollars with it• I hate vendor lock-in!• Because it’s cool!• Because vendor XY tells me it’s useful• Everyone uses it!• Do I even have a choice?• It’s cheaper

Let’s get serious . . .


2-3

Why Web Services? – Overview of this chapter

• Different reasons for different people!– Cost-centric – largest IT cost is labor– Integration-centric– Business-driven– Reuse-centric– The answer is always a mixture

• But: Web Services are not for everything!– In a later chapter, we’ll talk about when Web Services

is not the right technology• Summary

2-4Why Web Services?Cost-centric reasons

• Situation– Currently, we use <xyz> to interconnect applications

that costs x million $ in annual support and maintenance• Yet integration is still a major challenge for us

– If integration was easier, we could spend more time building new useful functionality

– Experts are needed for design and implementation• Benefits of Web Services

– Simple technology, short learning curve– Standards minimize the risk of vendor lock-in– Cheap, no huge initial investment

• Example – Replacing “homegrown” solutions


2-5Why Web Services?Integration-centric reasons (EAI scenario)

• Situation– Two or more applications need to be integrated– Business need and budget for solving the problem – Choices: “traditional EAI tool” vs. Web Services

• Benefits of Web Services– Instead of just doing a point-to-point integration between two

applications, you can build a set of services that can be used by other applications in your enterprise

• You can avoid a short-term tactical point-to-point integration• Services can call other services, so you can do even better than

integration: you use services to consolidate some of your enterprise systems

• Potential to rip out some middle-tiers / hubs (“disintermediation”)– Implementations on all platforms available (incl. mainframe)

• Example– Integrate a set of J2EE and .NET applications, and later allow some of

these services to be used by other environments

2-6Why Web Services?Integration-centric reasons (B2B scenario)

• Situation– need to link up my business processes with partner– Can’t or don’t want to agree on a heavyweight B2B

protocol, or none applies for this problem• Benefits of Web Services

– We can create light-weight B2B protocols– Web Services rely only on Internet standards– Both partners can use development tools from different

vendors (incl. Open source)– Low cost of entry (no expensive software purchases)

• Example– Low cost alternative to EDI


2-7Why Web Services?Provider scenario

• Situation– Useful service (e.g. check flight status, shipping status) to

be made available programmatically• Short term goal: Market share• Long term goal: Charge!

– Requirements for delivery: Open, widely used, reach maximum number of clients, secure, etc.

• Benefits of Web Services– Web Services rely only on internet standards– Low cost of entry (no expensive software purchases)

• Example– Amazon.com’s virtual storefront services

2-8Why Web Services?Consumer scenario

• Situation– Number of useful web services is growing

(Just look at www.salcentral.com or www.xmethods.net !)• You may want to use some of these in your programs and/or on your web

pages– Albeit that most of these public Web Services don’t come with any guarantees

– Some of these offer services that you couldn’t implement yourself • e.g. validate CC transaction

• Benefits of Web Services– It’s easier to incorporate useful features into client apps or web pages

• regardless whether they are hosted internally or on the internet

• Example– Your own web page with automatically updated stock prices and

sports scores (what more would you need in life).


2-9Why Web Services?reuse-centric (intra-enterprise)

• Situation– Most enterprises would benefit from sharing services

• Rather than re-implementing them in many projects (and supporting all of these)

• These days, lowering costs and consolidation are key– The many technology ‘wars’ have given us many technology islands

within each enterprise• Benefits of Web Services

– Web Services can be used to bridge across these technology islands• We can use it to create an architecture aimed at re-use

– Expect lower resistance than with prior technologies• Because Web Services isn’t used to implement clients or servers

– It’s a “neutral interface technology”– Growing internal use of XML, so often no need to transform data

• Example– Reuse existing services across technology islands

2-10

Overview of web service usages-Scope-Organizational impact-Complexity

-Number of involved applications/services

Niche usage

Provider-centric

Consumer-centric

Integration usage

EAI

Enterprise infrastructurefocus: reuse

Architecture for re-use of

servicesB2B


2-11SummaryWhy should I use Web Services?

• To replace existing or homegrown middleware with cheaper off-the-shelf, standards-based solution (cost-centric)

• I need to integrate these two (or more) applications in order to achieve a certain business goal (integration-centric, EAI)

• I want to build a link with a business partner over the internet(integration-centric, B2B)

• I have built a cool service and I would like others to use it (provider only)

• I could add a cool feature to my application if I could easily make use of that web service which I found (consumer only)

• I am an Enterprise Architect and it would be great if we could achieve better reuse by sharing as many common services as possible between different applications. Avoiding redundancy could save a lot of money. (reuse-centric)


1

Chapter 3Web Services Technologies

XML and SOAPWSDL and UDDI

Version 10

3-2

Web Services Technologies

• A collection of XML technology standards that work together to provide Web Services capabilities– We will provide an overview of the more prominent WS standards

• Web Services Technologies are primarily an integration or interfacing technology – NOT an application development technology– Still can develop in existing or new software development

environments• Web Services Technologies make it easier to tie together

existing or planned software components – Due to the language-, platform-, OS-, hardware-neutral

characteristics of the standards• As we will see a later chapter, Web Services

Technologies provide one approach to implementing the interfaces and messages for a Service Oriented Architecture-based system


3-3Participants in a Web Services Environment:the roadmap for this chapter

3-4

XML / Web services – in action

IntegratedApplicationOr domain

LocalTransforms

LocalData Model

UDDI Registry IntegratedApplicationOr domain

LocalTransforms

LocalData Model

WS/SOAP client

XML mapping

SOAP server

ServiceDescription

(WSDL)

SOAP server

ServiceDescription

(WSDL)

1) Register2) Inquire

4) Request/Response

SOAP messages

(XML)3) Get WSDL


3-5

Web Services Technologies Overview• XML Technologies

– “Extensible Markup Language”– Base XML for documents– XML Schema for describing XML documents

• SOAP– “Simple Object Access Protocol”

• A simple way to send documents (some people have calledi t “email for documents”)

– How to format XML documents for transmission• WSDL

– “Web Services Description Language”– Defines all details about a service

• UDDI– “Universal Definition, Discovery and Integration”– One way to advertise and discover services

3-6Participants in a Web Services Environment:Part 1 - XML Technologies

XML documentswithin

SOAP messagesdefined by

WSDLdiscovered via

UDDI


3-7

XML Technologies

• Collection of extensible information representation and manipulation technologies – XML itself – the base document standard– XML Schema – for data typing and document

structuring– XSLT – for transforming XML to other XML or other

formats– Parsing strategies for XML document processing

• DOM – Document Object Model• SAX – Simple API for XML

– Others: XPATH, XQUERY, etc.

3-8XML TechnologiesXML – eXtensible Markup Language

• Originally a derivative of SGML in the family of markup languages

• Similar to HTML in appearance, but with a very different goal→ to separate data content from data presentation

• Now, a full and evolving W3C standard• Parsable, extensible and self-describing text format for

exchanging information– Platform-, hardware-, programming-language-neutral– Highly portable across heterogeneous networks

• Reference: http://www.w3.org/XML/

SGML : Structured Generalized Markup Language

W3C : World Wide Web Consortium


3-9XML TechnologiesImportant characteristics of XML• Similar in appearance to HTML

– HTML has a fixed set of tags, XML has a variable set• Two major structuring mechanisms:

– Elements that may contain other elements– Attributes characterize elements with simple strings

• Elements are demarcated by Tags at the start and end:• E.g., a MyElement element

<MyElement> …. </MyElement> • Nested elements are used to model complex data

• We’ll see many examples of this

• Extensible – can define new elements and attributes easily• But – sometimes considered “as wasteful and inefficient”!!

• Let’s look at very simple XML documents – teach by example

3-10XML TechnologiesSimple XML Document Exchange

Example of an XML-based request documentFour elements:getQuotesymbol

getQuoteResponseReturn

Two containother elements.

Two containsimple text content.

<getQuote><symbol>FORD</symbol>

</getQuote>

Example of an XML-based response document

<getQuoteResponse><Result>56.5</Result>

</getQuoteResponse>

Each XML document can have only one top-most element.


3-11XML TechnologiesSimple XML Document Exchange with attributes

<getQuoteResponse date=“02-01-2004”><Return>56.5</Return>

</getQuoteResponse>

Date attributeExample of an XML-based request

<getQuote date=“02-01-2004”><symbol>FORD</symbol>

</getQuote>

Example of an XML-based response document Date attribute

3-12Shortcut if there is no value between

the tags• if the symbol was changed to be an attribute, then

you could write either this:

<getQuote smybol=“FORD”date=“02-01-2004”>

</getQuote>

<getQuote smybol=“FORD”date=“02-01-2004” />

• Or use a shortcut:


3-13XML TechnologiesXML Namespaces

• Used to avoid element and attribute name clashes when creating complex XML documents

• Attributes of the form xmlns:prefix=identifier are used to introduce a namespace and establish the prefix– Subsequently, names within the namespace must be written as

prefix:name

• There is also a way of setting up a default namespace so you do not have to write the prefix: xmlns=identifier

• As we’ll see, the identifier is typically a URL.• Let look at some examples

3-14XML TechnologiesNamespaces – a simple example• Example of a simple XML request document with a

namespace

<WSMsg:getQuote xmlns:WSMsg=“http://www.WS.com/msg”><WSMsg:symbol>FORD</WSMsg:symbol>

</WSMsg:getQuote>

• Example of a simple XML response document with a namespace

<WSMsg:getQuoteResponse xmlns:WSMsg=“http://www.WS.com/msg” ><WSMsg:Result>78.9</WSMsg:Result>

</WSMsg:greetMeResponse>


3-15SOAP OverviewMore Complex Namespace Example

<?xml version='1.0' encoding='utf-8'?><ENV:Envelope

xmlns:ENV="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:m1="http://IONA.com/HelloWorld"><ENV:Body>

<m1:greetMe > <m1:stringParam0 xsi:type="xsd:string">

Hello From WS Client</m1:stringParam0>

</m1:greetMe></ENV:Body>

</ENV:Envelope>

3-16XML TechnologiesXML Schema – Data Typing for XML documents• How do we know what elements and attributes to use?

• XML Schema provides the way to define an XML document type

• So, the structure of a document is expressed in an XML Schema file– The schema is an XML document itself – It supplies the definitions of elements and types

• XML tools can check if a given XML document conforms to a given XML Schema

• Resource: http://www.w3.org/XML/Schema– the primer document is quite readable

(http://www.w3.org/TR/xmlschema-0/ )


3-17XML Technologies

XML Schema Fundamentals

• Define XML elements using the built-in and user-defined types:– Simple types

• Built-in types (e.g. string, numbers, unsigned bytes, characters )• Restricted & enumerated types

– Complex types by composing other types using• Sequence (an ordered record)• All (an unordered record)• Choice• Able to specify limits on repetition (e.g., 0 to N, 5 to unlimited …)

using minOccurs, maxOccurs attributes– So you can create lists

• Can access element definitions from other Schema files using the include element

3-18XML TechnologiesXML Schema - examples

• Address.xsd – a very simple schema• Company.xsd – nested schema – imports two

other schemas:– Person.xsd – referenced by Company– Product.xsd – referenced by Company

• BookStore.xsd – more complex example– A nested list of nested structures

Each of these specifies it target namespace, using an attribute.For example:

<xsd:schema targetNamespace=“http://www.address.org” ...


3-19Address.xsd – simple element with several string components

3-20

Address.xml – consistent with schema


3-21

Company.xsd – unlimited number of Persons and Products – types from ‘included’ schema files

3-22

Person.xsd – Persontype elements


3-23

Product.xsd – ProductType element

3-24

Sample Company XML file


3-25BookStore.xsd – unlimited list of Bookstructures each containing 5 fields

3-26

BookStore.XML


3-27XML TechnologiesXSLT for Transforming Data• eXtensible Stylesheet Language - Transform• Need ways to take XML data and transform it to other

forms for various purposes– XML isn’t always the format that you want to work with

• Examples– Transform XML information into HTML format for web page display– Transform XML data to conform to another XML Schema– Transform between international representations (dates, currency) – Transform data into several different presentation formats (browser

screen, handheld, pure text …)• Actually two specs: XSL (stylesheet language part) and

the Transform part• Resource: http://www.w3.org/Style/XSL/

3-28

XSLT Fundamentals• Applies transformation rules to elements found in the

XML– You tell it what elements to find, and what to output when each is

found

• It leverages the XPath specification– A powerful way to name nested elements in a document

• Uses a nested programming-language-like syntax for matching, repetition, etc. to support complex document parsing

• Let’s look at an example


3-29

XML document containing company info

3-30

(Part of) XSLT for transforming data


3-31

Transformed Data in HTML format …

3-32XML TechnologiesParsing XML documents• Processing XML documents within programs typically

requires XML parsing capabilities• Two most popular parsing approaches:

– DOM – Document Object Model• Read and represent entire document in memory as a tree of nodes

allowing for easy traversal throughout the document• You can modify the tree, and make a call to DOM to tell it to output

the new tree as a document– SAX – Simple API for XML

• Event driven parsing model that invokes callbacks for major XML elements as they are read from the document

• Can be more efficient than DOM for large document processing• Used more for extracting sub-document information and specific

processing


3-33XML TechnologiesOther XML Specifications

• XPATH– XML-based syntax to provide sophisticated access to parts of an

XML document

• XQUERY– An SQL-like dialect for querying parts of varying XML data

sources– Extension to XPATH

• XML-Encryption – (to be seen later in more detail)– Process for encrypting/decrypting parts of XML docs

• XML-Signature – (to be seen later in more detail)– To ensure origin and integrity of XML docs

3-34Participants in a Web Services Environment:Part 2 - SOAP Technology

XML documentswithin


WSDLdiscovered via

UDDI


3-35SOAP OverviewStructure of a SOAP Message

• A SOAP message consists of:– Envelope - identifies the message boundary and

includes:• Header - contains meta-data/auxiliary (optional)• Body - contains the request and response XML

documents

EnvelopeHeader

Body

• Fault informationmay also besupplied – notshown here

• Often the header contains system level data (see later chapters)

3-36SOAP OverviewSkeleton SOAP Message in XML

<?xml version="1.0"?> <soap:Envelope xmlns:soap=“ ... ">

<soap:Header>... ...

</soap:Header><soap:Body>

... ... < … message payload goes here … >

</soap:Body></soap:Envelope>


3-37SOAP OverviewOur Simple Example – in SOAP

<?xml version='1.0' encoding='utf-8'?><ENV:Envelope

xmlns:ENV="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:m1="http://IONA.com/HelloWorld"><ENV:Body>

<m1:greetMe > <stringParam0 xsi:type="xsd:string">

Hello From WS Client</stringParam0>

</m1:greetMe></ENV:Body>

</ENV:Envelope>

3-38SOAP OverviewSimple Example Response – in SOAP<?xml version='1.0' encoding='utf-8'?><ENV:Envelope

xmlns:ENV="http://schemas.xmlsoap.org/soap/envelope/"xmlns:ENC="http://schemas.xmlsoap.org/soap/encoding/"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:m1="http://IONA.com/HelloWorld"><ENV:Body>

<m1:greetMeResponse> <return xsi:type="xsd:string">

Echo: Hello From WS Client</return>

</m1:greetMeResponse></ENV:Body>

</ENV:Envelope>


3-39SOAP OverviewSOAP Processing

• Within the SOAP environment, the software responsible for the generation, transmission, reception and analysis of these messages is known as a SOAP Processor

• These processors can be standalone listeners on TCP ports– Accepting incoming SOAP messages and passing them up in

the stack

• Also, most Web Servers include a SOAP processor– but if your Web Server doesn’t include a SOAP processor, then

most Web application development environments allow you to add a “SOAP plug-in”.

3-40Participants in a Web Services Environment:Part 3 - WSDL Technology

XML documentswithin


WSDLdiscovered via

UDDI


3-41

WSDL Technology

• Web Services Description Language• WSDL is the KEY to using Web Services

– WSDL provides an OS-, platform- language-neutral definition of a Web Service

• THE contract between Web Service provider and consumer

• Completely describes a Web Service:– Messages and types of data used in messages– Operations with associated in and out messages– Bindings of operations to transports– Physical location of service (endpoint) specifications

• Large and complex standard, continually undergoing development and proposed extensions

• Reference: http://www.w3.org/TR/wsdl

3-42WSDL OverviewMajor WSDL Elements

Part

Type

Message

Operation

PortType

Binding

Port

Service

Logical aspects

Physical aspects


3-43WSDL OverviewMajor WSDL Elements

– binding: specifies concrete protocol and data formats for the operations and messages defined by a particular portType.

– port: specifies an address for a binding, thus defining a single communication endpoint.

– service: used to aggregate a set of related ports.

• The top level XML element is the definitions element<definitions> . . . </definitions>

• Services are defined using eight major elements:– types: data type definitions used to describe the messages exchanged. – message: abstract definition of the data being transmitted in a

message. A message consists of logical parts, each of which has one of the defined types.

– operation: Each operation can have an input message and an output message.

– porttype: a set of operations.

3-44WSDL OverviewThe <types> element

• Types are specialized building blocks for data content exchanged via Web Services

• Normally the <types> element uses XML Schema to define types and elements used in the WSDL document– But another type system could be used (this isn’t very well

defined now)• So normally specified in terms of XML Schema

constructs– Simple types– Complex types – including sequences and nested structures

• E.g. a purchase order with multiple items

• We’ll see examples of these later.

Part

Type

Message

Operation

PortType

Binding

Port

Service


3-45WSDL OverviewThe <message> element

• Messages are the packaging of data that are transferred (in or out) via web service operations

• A message can contain zero or more parts– And each part can contain one element or one type

Part

Type

Message

Operation

PortType

Binding

Port

Service

3-46WSDL OverviewThe <operation> element

• An operation can have an input message and an output message

Part

Type

Message

Operation

PortType

Binding

Port

Service


3-47WSDL OverviewThe <porttype> element

• A <porttype> is a collection of named operations– each with an input and/or an output message

• This is the key to the logical definition of a web service– What operations are available for access– What input message is required for each operation– What output message is generated by each operation

Part

Type

Message

Operation

PortType

Binding

Port

Service

3-48It may help to view the Logical aspects as follows:

Part

Type

Message

Operation

PortTypeLogical aspects

// interface

// method

// the messages that flow// in and out of an operation

// parameters

// type of parameters


3-49Let’s look at our simple example,within a WSDL file … HelloWorld.wsdl

3-50WSDL OverviewThe <binding> element

• The <binding> element specifies how the logical content (messages, operations) is mapped onto transports for exchange between requestor and provider

• HTTP + SOAP are the predominant binding options, but many more are becoming available to support integration throughout and among enterprises

• Note that multiple bindings for the same PortType are possible!

Part

Type

Message

Operation

PortType

Binding

Port

Service


3-51WSDL OverviewThe <port> element

• The <port> element specifies the physical location/destination for sending the service requests

• Typically supplied as a URL

Part

Type

Message

Operation

PortType

Binding

Port

Service

3-52WSDL OverviewThe <service> element

• The <service> element specifies a collection of ports –I.e. locations where the operations of the service are accessible to potential service requestors

• Typically, the ports of a service refer to the different locations where the different possible bindings specified elsewhere in the WSDL file are implemented and available

• Example: one port may supply the location where HTTP is the transport binding, another port may supply the location where it is FTP

• Let’s look at the rest of our simple example within a WSDL file … HelloWorld.wsdl

Part

Type

Message

Operation

PortType

Binding

Port

Service


3-53

HelloWorld.WSDL

3-54WSDL OverviewA Few Concrete WSDL Examples

• Stock Quote WSDL – remotely stored WSDL file at Xmethods.net– Simple data model and operations list used for our early

demo

• WS-I Manufacturer WSDL file (Warehouse.wsdl)– Imported schemas, shared among different WSDL files– Sample request and response SOAP messages

documented in the file– Documentation discipline – commentary, headers, etc.


3-55

Stock Quote WSDL File

3-56

WS-I Warehouse WSDL


3-57

WSDL Element Relationships

Part

Type

Message

Operation

PortType

Binding

Port

Service1

*

1,2

*

*

*

1

1

Logical aspects

Physical aspects

3-58Web Service Technologies RelationshipsRun time vs Design Time

E.g.,HTTP

Client WebService

SOAPRequest

SOAPResponse

XML

Run

time

exec

utio

n

WSDL Specifies …

Operations,Structure and

Typing of Messages

EncodingAnd Transport of

Messages

PhysicalEndpoint

ServiceCommunicationsRequirements:

Des

ign

and

Dep

loy

time

XML Schema

<portType> <binding> <service>


3-59Participants in a Web Services Environment:Part 4 - UDDI Technology

XML documentswithin


WSDLdiscovered via

UDDI

3-60

UDDI Technology

• Universal Description, Discovery and Integrationof Web Services

• Sponsored by the OASIS organization• Supports the ability to register and find services

on the internet– Service Providers register/publish services including

WSDL file along with searchable attributes– Potential clients search UDDI registries to retrieve

WSDL suiting their service needs• Resource: http://www.uddi.org

UDDI is the least accepted of the SOAP, WSDL, UDDI triangle. It is overly complex, and over burdened by a lot of business level aspects (e.g., descriptions of a business).


3-61UDDI OverviewUDDI – API’s

• Defined by – what else by – WSDL files– UDDI services are Web Services !

• Register/publish web services API– Register_WSDL for publishing – Major operations: save_service, save_binding, …

• Inquire for web services API– Inquire_WSDL for inquiring– Major inquire operations: find_business, find_service,

find_binding, get_binding_detail,get_service_detail, …

3-62

Sample UDDI Registry Listing


3-63Correlating the WS StandardsWeb Services Interoperability Organization (WS-I)• Web Services depend heavily on agreed-upon standards

(XML, SOAP, WSDL, etc.) that are relatively independent of each other

• Keeping up with the changes and nuances that exist among these is difficult and time-consuming

• WS-I has the mission of doing this for the IT industry– advising on how to use these WS standards appropriately and

interoperably• Primary deliverables:

– Basic Profile 1.0: this supplies advice about which combinations of the standards should be used together, and which features should be avoided or emphasized from each standard

– Test Tools for verifying compliance with the Basic Profile– Sample Applications for assisting others in building compliant

systems• Visit http://ws-I.org/ for more details …

3-64

Conclusions

• Web Service technologies allow the exchange of XML documents– XML, XML Schema define data to be exchanged– SOAP is the protocol used for the exchange of the data– WSDL specifies the details of services, messages, and endpoints– UDDI supports the publishing and locating of services

• The platform-, OS-, programming language-neutral aspects of Web Services allow heterogeneous environments to interoperate easily

• Defining the information/data structures/messages is central to the overall process– Utilize the XML Schema and WSDL types facilities to represent

your data appropriately– Let development tools provide automatic mappings between

programming language structures and Web Services structures


3-65Participants in a Web Services Environment:Review

XML documentswithin


WSDLdiscovered via

UDDI


1

Chapter 4Web Services Tools and Demo

Typical Tools for Design, Development and Deployment of Web ServicesWith demos of creating simple WS clients and WS servers

Version 11

24-2

WS tools and demos – the “How To’s” of WS

• Tools are needed for:– Creating/defining XML documents and schemas– Creating/modifying service definitions/WSDL files– Mapping WS artifacts to/from programming concepts

• Both directions may be needed depending on the integration scenario– Managing and locating deployed Web Services

• Some typical and available tools:– XMLSPY – General Purpose for XML docs and WSDL files– Artix – C++/Java-based Web Services

• Enterprise Web Services & middleware integration toolkit from IONA– VS.NET tool set - Microsoft– J2EE/App Servers – J2EE in general – e.g. EJB– Many vendors and many tools, … and more everyday

• IONA, IBM, Sun, BEA, Cape Clear, Altova (XMLSpy), etc.


34-3

Building a Web Service - Two Basic Approaches

• From Scratch – a new application or system– Start with WSDL and/or data/message schemas and produce

the application using generated application building artifacts:• “blank” client and server, client-side stubs & server-side skeletons

– Write the business logic in the “blank” server– Fill out the “blank” client code

• From Existing Systems – either– Automatically derive the WSDL from the existing interfaces for

the application or from data schema files• There are automatic WSDL generators for CORBA IDL, Java

classes, J2EE EJBs, COBOL, other middleware (MQ, Tuxedo,…), message/XML Schema files, . . .

• Often you have to enhance the generated WSDL– Do a top down design of the WSDL, and implement the service

using new code and the existing systems• You may get better WSDL. Remember that one of the main goals of

a service is to keep its clients simple.

44-4Diagrams to show these Development Approaches

WSDL File WS ServerEndpoint

Existing AppExisting App has an APIExtract WSDL from APIBuild client and server skeletonClient calls App API through WS

Extract WSDL

WSDL File WS ServerEndpoint

Create serverServiceDesign a WSDL (top down)

Create client and server skeletonImplement server/service codeClient calls service through WS

WSDL File

WSDLEditor

Create/Edit WSDLDesign/update the WSDL Utilize in above scenarios duringdevelopment/evolution of system


54-5

Typical WS Development/Deployment Components

64-6

Development Demo Scenarios …

• Automatic client generation – Seeing WS clients in action …

• Hello World – VB.NET client creation– Local Artix server

• Stock Quote – VB.NET client creation– Our original example - again

• Hello World – VB.NET Web Service Creation


74-7

Automated WS Client Generation

• A number of tools available for this task• Generate Java, VB, C#, Javascript, ASP, JSP and other• We will use Web Services Studio 2.0

– Freeware product – 114KB – simple install– Reads/analyzes a WSDL file, located anywhere on the net– Creates/displays automatically generated client/proxy code– Simplifies the invocation of WS methods with arbitrary inputs, and

then viewing the response messages– Can view the actual SOAP messages involved

• Available from:• http://www.gotdotnet.com/ - locate WebServiceStudio 2.0 page• Requires .NET SDK environment

• Let’s see it in action …

84-8

Screen Shot – WS Studio 2.0


94-9Web Service Client Created and Executed

104-10

SOAP Messages to/from Service


114-11

WSDL File display

124-12

Generated Proxy Code


134-13

Generated Client Code

144-14

A Different Stock Symbol … and result


154-15A Different Stock Quote – the SOAP messages

164-16A Different Stock Quote Web Service –more operations & more data returned


174-17

Writing Client Code – Simple Examples

• Using Visual Basic within Visual Studio.NET• Simple, unpolished examples• Illustrate the underlying theme of ease of access

to Web Services from most development environments

• Major building step– Add a “Web Reference” to the current project– Based solely on a WSDL file specification:

• Local/remote file system• Remote URL

184-18

HelloWorld VB.NET Client

• Use a remotely stored WSDL file (HelloWorld.wsdl) on our demo system– Simple data exchange service– Only two operations – greetMe and sayHi

• Create a simple client (using VB.NET)• Execute the client to invoke a remote service

– Server written in C++ using IONA Artix product running on a remote server

• Let’s do it!


194-19

204-20

Windows Application for our Examples


214-21

Key Step: Add a Web Reference

224-22

Add Web Reference Dialog


234-23

Create a Proxy object to WS server

244-24

Invoke operation via Proxy Object


254-25

264-26

Web Service response


274-27

Invoke another operation

284-28

Service response


294-29

Web Service Server Log

304-30

StockQuote Client

• Externally available service– WSDL file discovered using WWW.XMETHODS.NET site– StockQuote WSDL file

• Simple data interface – strings in and out• Single operation - getQuote• Build simple client from the WSDL and then execute the

server– Don’t even know how the service is implemented or where

located physically– But it doesn’t matter!

• Let’s do it - again

• See a slightly more advanced version of a client


314-31

Add Web Reference Wizard

324-32

More client code – invoke Stock Quote


334-33

344-34

A VB.NET Client to StockQuote Web Service


354-35

Creating a Web Service from Language Constructs

• Within most Web Service tools, it is easy to expose a function/method as a web service

• With VS.NET, we simply create an ASP.NET Web Service application, and add to any public function declaration(s) the attribute:

<WebMethod()>

• This allows the .NET framework to supply the necessary WS aspects to expose the method as WS operation and invoke from a remote client

• Let’s see simple illustrations of this using VB.NET …

Implementing a service

364-36

Create a Web Service Project …


374-37Generated Source File …

384-38

Add Code by removing comments

Need to Build the solution from here …


394-39

Using WS Studio Client – for SOAP

404-40

SOAP Messages to/from Server


414-41

Additional Operation: with a parameter

424-42

Invoke the service with a parameter


434-43Invoke the service via HTTP …

Right click here

444-44

HTTP Response – instead of SOAP!


454-45

Server Code Generation

• Web Service ToolKits can also generate server side code skeletons directly from WSDL files

– Java, C++, CORBA and other environments– Typically a collection of classes and interfaces

• Then the programmer must add the code to implement the operations (possibly implementing them using existing systems)

• Last step is to deploy the server side implementation into the web service container, to allow it to be invoked by remote clients

• No time to do here, but a later section describes how this was done for a Java-based environment (WSID)

464-46

Tools to create WSDL files

• XMLSPY – somewhat generic XML support, but it can be made to work OK for WSDL

• WSDL support embedded in other tool sets – Microsoft Visual Studio– BEA’s WebLogic, etc.

• Visually oriented (GUI) WSDL construction tools becoming available – See next few slides for a sample tool (IONA’s Artix)


474-47

Top level WSDL structure

484-48

Detailed WSDL element wizard - Port


494-49

Summary of Development Demos• These capabilities are available in most WS toolsets

• Simple to access remote service WSDL files to:– Create simplistic clients for immediate access/testing– Create simple client in programming language of choice– Create stubs for server components

• These tools mean that you don’t need to understand the details of WSDL– The tools handle the WSDL, and give you stub and skeleton

functions that you can use to program your clients and services.

50

Web Services Execution DemoWeb Services Interoperability Demo (WSID)


514-51

A Web Service Case Study

• Web Services Interoperability Demo (WSID)• Group of industry vendors (IBM, Microsoft, IONA, The

Mind Electric, Amberpoint, WebMethods …)• Joint development of specs and implementations• Development done globally, demonstrated at numerous

trade shows (e.g., XML-ONE)• Multiple platforms, OS, programming languages

– .NET, several J2EE systems, straight Java, and some unknown!

• WSDL files as the key definition / specification for the project

• Tony Hong of XMETHODS.NET was the technical leaderhttp://www.xmethods.net/wsid-03-2003/

524-52

Web Services Interoperability Demo

Client

Warehouse

Supplier

Warehouse Floor: Embedded WS Client

5. Ship Confirm

1. Send PO

4. Ship Request

3. Charge

Bank

2. Check Inventory


534-53

WSID Architecture

Customer

Supplier

CreditBureau

Warehouse

debit()

checkAvailability()

getCatalog()sendPO()getPOStatus()getInvo ice()

shipRequest()

shipCon firm()

Bank

Charge()

WarehouseGUI

WarehouseGUI

GUI

XARFiles

(Local orRemote)

Deployment

ConfigControlFiles

(Remote)

Initialization

RunTimeFiles

(Local)Run Time Logging

(Remote)

Real Time Logging and display tools

.NET clientwill be shown

544-54

Building Web Service-based Application

From Xmethods

Initial Code

Initial Code

Deployment

ImplementTo WSID

Specs

Build/Rebuild


554-55

.NET (VB) Client for WSID

564-56

Java Swing Client for WSID

Let’s see WSID in action …


574-57

Logging screen shot

584-58

Browser view of logs


594-59

WSID Demo Summary

• What we saw in this demo …

• Multiple interacting web services• Implementing a typical Supply Chain Example• Multiple Language GUI Clients• Web Service server also acting a Web Service client

• Each of these components has been implemented by a set of WS vendors– And it has been tested with arbitrary selections of these

components, running on machines distributed across the US!

604-60

Chapter Summary

• Web Services are real – here and now -– You can design, develop and deploy with them now – Both for internal use and between enterprise vendors– Existing services can be discovered and accessed easily

• Many tools available with varying degrees of maturity and complexity – and more to come– Evolution of tool capabilities ultimately drives ease of use of WS

• The most interesting part of designing a system with Web Services is the high-level architecture of the system– What services should exist, and how should they interact?– What is the right structure for the information that should pass

between clients and services?– These are the topics of the next chapter


Chapter 5Service Oriented Architecture

Version 6

25-2

Overview

– A guiding analogy– Terminology excursion

• Service, interface, architecture model, architecture style, service-oriented architecture

– Benefits of service-oriented design– Successful example of service-oriented design– What does this mean to you?

• How to prepare for SOA

– Summary

Ok, now we understand the Web Service technology, but how about Service Oriented Architectures?


35-3From just using a Web Service to

having a Service-oriented architectureIntermediate stage: Individual services broken out

Application

Application

service

service

Application

Application

service

Service-oriented architecture

service

service

service

service

Application

Monolithic applications

Application

45-4A guiding exampleBank Teller analogy for service-orientation

• Different types of tellers offer different services– Tellers specialized to perform only certain types of transactions (which

are typically closely related)– Example partitioning:

• Account Management (Opening and closing accounts)• Credits (inquiry about conditions, consulting, applying for mortgages)• Cash Register (Withdrawals, deposits, funds transfers)• Currency exchange (buy and sell foreign currencies)

• There may be several tellers offering the same set of services (for load balancing / failover)

• What happens behind the counter is not your business (bulletproof glass, iron bars)

• If you require a complex transaction, you may have to visit several tellers (customer as transaction coordinator)


55-5Terms and DefinitionsService (Definition)

– A service is a package of closely related standardized functions, which are called repeatedly in a similar fashion, and should therefore be implemented by a dedicated facility, which can be specialized to perform them.

Example: Account Management

– A service can be partitioned and have multiple service functions.

Example: Open new account

– The smallest subunits within service functions are called service primitives.

Example: Generate next available account number

65-6Terms and DefinitionsCharacteristics to completely describe a service

– Service requester (“client”)• Who/which components use or need the service?• For the service requester, the provided service is most important, and

not how it is implemented (principle of information and implementation hiding)

– Service provider (“server”)• Who/which components implement or provide the service?• is responsible for hosting the service, and ensuring the promised QoS• may charge for service usage

– Qualities of Service (QoS)• What are the parameters that allow to distinguish good service

provisioning from bad?• Examples: Reliable, predictable execution, cost, execution time, level of

privacy, other guarantees


75-7Terms and DefinitionsInterface (Definition)

• An interface constitutes the specification of a service, that is implemented by a certain component. The interface defines a contract, to which the component that implements it has to comply.

• Signature of interfaces can be described using formal languages– Web Services Description Language (WSDL)– OMG/ISO Interface Definition Language (IDL) (for CORBA)– UML Object Constraint Language (OCL)– But also: Java, C++ headers, . . .

• Type-safe interfaces sometimes introduce tight coupling– Web Services don’t force you into type-safe interfaces

• Different message types may be acceptable to a service

85-8Terms and DefinitionsSoftware Architecture (Definition)

Software architecture encompasses the set of significant decisions about the organization of a software system

• selection of the structural elements from which the system is composed, and the interfaces to these

• behavior as specified in collaborations among those elements

• (de)composition of these structural and behavioral elements into a larger system

• architectural style that guides this organization

Mary Shaw (Carnegie Mellon Univ.)


95-9

• An architectural style defines a family of systems in terms of a pattern of structural organization [Garland/Shaw 96]

• An architectural style defines:– a vocabulary of design elements

components (client, server, filter, layer, adapter…), andconnector types (pipe, broadcast, queue,...)

– a set of configuration rules (constraints) on how they can be combined

• Example styles in Software Architecture: Event-based, Repository-based, virtual machines, layered

Terms and DefinitionsArchitectural Style (Definition)

105-10

• The architectural style of an application is called service-oriented if it meets the following criteria:– It is not monolithic; common blocks of functionality are broken

out of the applications and are instead provided by services• A significant part of the overall functionality is implemented by services,

which exist otherwise independent of the application– Design elements for an SOA are:

• Components: Services (can be composites), consumers, providers• Connector type: (Remote) Service invocations

– Configuration rules for an SOA are: • No strict layering (Service implementations can use other services)• No centralized control entity• Services are designed for shared use, and for use that may not even

have been anticipated at design time

Terms and DefinitionsService-Oriented Architecture (SOA)


115-11

• Service-Orientation is an organizational principle– A set of principles for building large systems– It is not tied to any particular technology

• Examples:– Common “horizontal” services:

• Logging, authentication/single-sign-on, systems management, Directory lookup of services, event notification

– “Vertical” services, specific to your business domain• Product feature search service, Address management,

Order Status Tracking Service, Truck/trailer tracking service• As in organizations, there is always more than one way

to structure a large system• The most important question: How to decompose?

– What is the guiding abstraction mechanism?– Why would one favor one decomposition for another?

Terms and DefinitionsService-Orientation

125-12Terms and DefinitionsQuality criteria for (software) architectures

Q: What makes one decomposition better than the other?A: Depends on the priorities of your requirements!

• Quality criteria used to measure the result:

1. Derived from top rank use cases (adequateness)2. Balanced with existing assets: platform technology,

frameworks, components3. Balanced with requirements (trade-offs, performance vs. security,…)4. Compliance with (domain-specific) industry standards and

reference models (interoperability, readiness for merging)5. Designed to make the system more resilient to future

changes (20 years?) (maintainability)6. Designed for substantial reuse, and with substantial reuse7. Intuitively understandable (people buy-in!) (usability)


135-13Terms and DefinitionsForces and quality factors for software arch.

FunctionalitySoftwareArchitecture

Fault Tolerance

PerformanceCostThroughput

Capacity

Availability

Interoperability Fail safe

Maintainability

Scalability

145-14

Challenges and problems

• Technology heterogeneity of existing applications• Many integration projects during the last three years

– Have been tactical, not strategic (no enterprise focus)– Only solved problems for one project (e.g. for one channel)– Result: Stovepipe integrations

• Large organizations run literally hundreds of packaged applications and often even multiple ERP systems

• These systems were designed as stand-alone and independent of each other

• They overlap in functionality • They overlap in the data they manage

– Integration does not remove any overlap– Consolidation would be better

• SOA helps to address these issues


155-15

Benefits of service-oriented design (1)

• More flexibility (“business agility”)– Assumption: business process logic and business rules are no

longer buried inside applications– Result:

• Since they are now explicit, processes can be changed easier• Existing services can be used in different contexts• Shorter time-to market for changed processes

• Reduced cost of operation through consolidation– Assumption: Redundant functionality is eliminated– Result:

• Fewer servers • Fewer licenses • Fewer assets to manage • Lower maintenance cost

165-16


• Higher quality– Eliminating redundancy will reduce inconsistent data and

inconsistent behavior– More transparency– Improved system architecture – easier to understand

• Reduced risk, cost and complexity for development– Clean architecture ⇒ reduced cost and risk– Increased developer productivity through reuse

• Projects can leverage existing services– “Black box” reuse instead of copy&paste reuse

• Lessen the dependencies on vendors– Service implementations can be replaced as long as interfaces

stay the same– Services can be relocated from one platform to another– Services can even be outsourced to an external provider


175-17


• Good service design (partitioning) will outlive your middleware or implementation technology– All you have to do is to put a wrapper around it, if required– Many mainframe systems today provide many useful services that

should be made available to applications elsewhere in the enterprise• Commoditizing more and more parts of the IT infrastructure

– Off-the-shelf infrastructure components are moving up the layers and coming closer to the application!

– Due to existing industry standards and available products, developers stop building this stuff themselves:

• 1990: DBMS, TP Monitors• 1992: Networking stacks• 1995: CORBA, RPC Middleware, Reliable Messaging• 1998: Naming Service, Publish and Subscribe, Event Notification• 2000: Various J2EE Services

185-18Case StudyCredit Suisse’s Enterprise Architecture Model

OS/390OS/390OS/390 OS/390OS/390OS/390 OS/390OS/390OS/390 OS/390OS/390OS/390OS/390OS/390OS/390

JavaJavaJava CORBACORBACORBAJ2EEJ2EEJ2EE COMCOMCOM C++C++C++

Credit Suisse Information BusCredit Suisse Information BusCredit Suisse Information Bus

Å Implementedstandards-based interfaces everywhere…

Ç …and then enabledservices-oriented access to all applicationsystems.

ServiceServiceService ServiceServiceService ServiceServiceService ServiceServiceService ServiceServiceService

ServiceServiceService ServiceServiceService ServiceServiceService ServiceServiceService ServiceServiceService

ServiceServiceService


195-19Case StudyCredit Suisse’s Enterprise Architecture Model

"There is no need for us to dismantle our existing infrastructure to deploy on-line business opportunities. IONA enables us to leverage multiple technology generations in a flexible system, which ensures shorter development cycles and investment protection.“

Stephan Murer, Credit Suisse

§ 500 business service

§ 50-plus front-end composite applications

§ 100,000 users

§ 7 million service invocations per week

205-20

What does all this mean for you? (1)

• Your role: Developer or Software Architect– Project-focused (“get this done”)– Success metric: Project / deliverable completed in time– Goal: Minimize time and cost of development– Granularity of re-use: class libraries, source code,

classes, frameworks• What you need to do

– be familiar with Web Services standards and technologies

– get your feet wet– be aware of existing services in your enterprise

• try to (re)use them as much as possible


215-21

What does all this mean for you? (2)

• Your role: Enterprise Architect or CIO– Enterprise- or infrastructure-focused– Success metric: Resourcefulness– Goals: Minimize TCO across projects, reduce

complexity, maximize “business agility”– Granularity of re-use: services, infrastructure

• What you need to do– understand Web Services technologies– define the roadmap, act as catalyst– define the business architecture– work for the application teams and encourage them to

use the services of “your” infrastructure

225-22

Summary

• Precise terminology helps – to understand and handle the problem– to identify and debunk unbaked concepts

• Service-orientation is an architectural style• Web services are a good technology to build

service oriented architectures – Simple, easy to understand– Inexpensive technology, no major investment needed– Can start small and proceed incrementally


Chapter 6Web Service Design Aspects

Version 7

6-2

Web Services Design Aspects Overview

• Introduction• General Design Guidelines• Best practices

– For the design of individual Web Services– For the design of a collection of Web Services

• Organizational guidelines• Summary


6-3

Introduction

• Clean design and adequate architecture are more important than tools and GUIs.

• A well designed service can outlive the application context in which it was designed.

• What best practices can one follow to develop an architecture that can successfully evolve over the next 20 years?

• Once you start designing services, are there any design rules and guidelines?

6-4

General Design guidelines (1)• Re-use existing Web services

– Avoid duplication of services– Encourage developers and architects to use existing services

wherever possible• Small is beautiful

– You can’t redesign your whole enterprise IT in one shot, therefore start with small teams and small projects

– Get developers gradually used to the idea– Simple Web services first, just to get used to the technology

• Take the concept of service registries and dynamic services lookup with a grain of salt– Any introduction to Web Services must mention the purist “triangle”

• service provider → service registry → service client– But no service registry may be needed for your first experiments– The need for a registry will grow with your environment

• But dynamic look up based off a set of properties will often be inappropriate for all but initial toy systems that you’ll build


6-5

General Design guidelines (2)

• Don’t repeat the mistakes of the past– Web Services are not silver bullets. There are none!– New technologies often have great features, but they take time to

mature. Web services lack certain capabilities that took other middlewares a decade to get right

• Use the right tool for the right job– Use Web Services

• for “large grained” operations • when interoperability is key and tools from different vendors are involved• when the underlying business problem is already document-oriented

– Use other Middleware (CORBA, MQ, J2EE, .NET, …) where it is better suited

• for small-grained, more “local” operations/services (components rather than services)

• for ultra-high performance requirements• for projects with sophisticated QoS requirements which cannot wait

for Web services to mature

• Consider a technology mix

6-6Best practicesDesign of individual Web Services (1)

• Design Web Services with a clear scope and purpose– Usage, purpose and value (!) must be easy to understand

• Design Web Services as open and shared– This is the key difference from point-to-point integration– Benefits of services only achieved if they are (re)used across

multiple application systems– The higher the amount of sharing, the higher the value of a service– Shared ≈ reuse

• Web Services are not inherently stateful– Core standards don’t provide the concept of a session “memory”

• If you need logical connection between messages, you have to take care of this yourself

• Standards for this are under development (WS-CAF, WS-CTX, see Advanced Topics)



• Don’t ignore performance aspects– Location transparency does not mean that usage of a Web

Service should be treated like a local function call– Don’t ignore network latency– Bundling several short messages into one, with a larger payload,

will result in better performance– Consider offering different operations with different granularity to

reflect usage patterns for a wide range of client types• Transaction requested from a J2ME-enabled phone: One at a time• Transactions requested from partner: batch! (hundreds, thousands…)

• Find compromise for granularity– If more work gets done in one invocation, the service is typically

more specific and more difficult to re-use

6-8Best practicesDesign of individual Web Services (3)• Properly encapsulate underlying applications

– Do not allow limitations of underlying applications or products to influence your Web service interface design (too much)

• Scenario: existing mainframe application uses 5-digit account numbers• Trade-off: thin-layer (expose the 5-digits), vs. introducing a mapping

layer to make the Web service more future-proof– Avoid “blob-type” messages

• Scenario: existing application produces complex return message for transactions, non-trivial to parse

• Trade-off: leave it as is (a long string) & burden client with interpretation vs. parse the string & return an XML sequence

• Encapsulate underlying middleware– Do not allow the underlying middleware to show through Web

Services interfaces. Hide protocol and encoding dependencies!– The granularity of existing middleware service interfaces may not be

right to expose “as is” as Web Service interfaces



• Benefit from WSDL type safety and schemas– Use the built-in primitive and complex data types– Rely on schema validation by an external parser– Do not encode additional information in attributes, even if the

underlying application does• “If zip code is <00000>, this means that the address is abroad”

– SOAP with Attachments allows transmission of binary data, but…• Use binary data only where appropriate (for payload), otherwise many

XML benefits will be lost (filtering, content-based routing,…)

• Have well defined interfaces and policies– There is more to an interface than just the signatures in the WSDL– Semantics is equally important, but hard to formalize– “Quality parameters of service” (availability, security, …) and error

handling are also part of the contract


• Web Services doesn’t provide a versioning mechanism– For now, it’s up to you to find a way to handle change

management. E.g., • assign different ports to different versions

– Or use one port but use naming conventions to distinguish the operations that apply to different versions

• Design your services to ignore elements of a message that it doesn’t recognise, so it can accept extended messages from a new version of the interface

– This isn’t always safe.

• Don’t call it a service, again– The name of the Account Management service is

“Account Management”, not “Account Management Service”


6-11Best practicesDesign of multiple services (1)• Services should use other services wherever possible for

common tasks– Example: authentication, logging, etc.

• Design Web services orthogonal to each other– Avoid redundancy and functional overlap

• Any exceptions to that rule have to be scrutinized– Some call this rule the “Bauhaus Principle”

• Web service usage should not have hidden side effects– The service implementation should do only what its specification

says it does, and nothing else• Don’t break the encapsulation when communicating

between services– Service implementations may use each other, but…

• A service should not bypass another service’s interface by going directly to the underlying implementation of it

6-12Best practicesDesign of multiple services (2)• Collections of related Web Services should use the same

type system (and the same formatting and semantics for the elements within these)– Transformations at runtime are (still) expensive– Wherever available and applicable for your vertical, find and use

standardized schemas/DTDs, vocabulary, format conventions, • Type-level: encoding for money/currencies, date/time, etc.• Element-level: address, patient, funds transfer, tax payer information• Schema-level: Hundreds of specific XML-based languages exist for

every vertical, from Court Filings (Legal XML), Clinical Data Interchange, to Financial Products (FpML)

• Try to make Web services coarse-grained and consume coarse-grained parameters. Two reasons:– Sending a series of many short messages takes longer than

one with a larger payload (network latency!)– Business people find it easier to understand coarse-grained calls


6-13Best practicesFor the organization (1)• Encourage, and reward (re-)use of Web Services

– Make reuse a virtue; give incentives– Monthly award for the team/developer whose Web service was

reused the most that month– Charge-back system, where the internal users of a WS reward

those that implemented it– Awards for team/developers who build new applications writing

the fewest lines of new code.– Make sure your annual salary reviews encourage use of Web

services in your SOA• Enforce Web services reuse

– “most effective tack […] has been punishment for not reusing [services]…” (Gartner analyst Michael Blechar)

– Have Architecture Gurus (no committee), who need to approve exceptions when existing services are not used

– Have people who work between projects and teams to encourage re-use (see later)

6-14Best practicesFor the organization (2)• “Build it, and they will come”

– Web Services will be re-used• If they are good quality, and have good documentation, and• are advertised well, and• you encourage reuse in your organisation

– Every development project is done under time pressure. If using existing Web Services allows them to get there faster with manageable risk, they will use them!

• Have a Web services registry and a roadmap of future ones– Publish this to your developers– Identify low-hanging fruit and consider potential risk/benefit – Look for best practices in your vertical domain (are there

existing/relevant reference models?)– Enterprise-wide services infrastructure can only be built step by step

• Keep an eye on internal integration projects– Evaluate those already ongoing!

• They might be building another stove-pipe– With little more effort, they might be building new services


6-15Best practicesFor the organization (3)• Educate your architects and developers on services and

re-use• Do your marketing

– Communicate! (and constantly collect feedback)– Advertise benefits of Web service usage, advertise successes– Create and provide precise documentation and descriptions of

services’ interfaces• Give exact description of semantics of parameters• Precise description of the behavior

– Give regular presentations, offer mentoring and training– Have an intranet portal, providing information about provided

and potential Web services– Provide usage examples and provide sample code if possible

• Watch out for ownership issues– The “not-invented here” syndrome

6-16Best practicesFor the organization (4)

• Build an infrastructure team for Web Services– Team members

• Senior Architects (both familiar with business requirements and (almost) every piece in the IT landscape of your enterprise)

• Cross-functional experience• Good mediators, good political skills, good existing network• Compensated based on overall cost savings, not project related

– Mission• Mission is NOT to administer the enterprise infrastructure nirvana• Advisory role, organizational “helper”, not dictators• They act as “re-use” mentors • BUT, projects shouldn’t abdicate responsibility for re-use to these people

– They are there to help. They are not the scapegoats for lack of re-use.– When do you get these people involved?

• Early in each project life cycle• And also throughout it’s lifetime

– Some of the services that it needs to build won’t be clear at the start– Some of the “external” services that it needs to use won’t be clear at the start– To identify services that it can offer other parts of the organization


6-17Best practicesFor the organization (5)

effort

Project-1Business

Logic

Project-1services

InfrastructureDeployed Web services, ready for reuse

Project-2Business

Logic

Project-2services

Infrastructure

Project-3Business

LogicProject-3services

Infrastructure

Project-?Business

Logic

Developmentprocess

prioritization

time

%done

• Don’t expect too much too early• Web Services Infrastructure will grow over time

6-18

Supporting measures

• Even with Web services, fixing mistakes in production applications will be costly

• Get design mentoring and assistance from someone who has done it before– Getting consultants may sound “expensive”, but

finding out by try-and-error yourself is even more expensive

• Good quality has its price

• Invest in training– Web service early adopters did not have that luxury– Self-learning does not work well for everyone– Training can give confidence and fresh ideas


6-19

Summary

• Most guidelines are common sense– think back to the component reuse discussions of yesteryear!

• Using one or two Web services ≠ having a SOA– To justify the term “service-oriented”, a significant part of the

functionality should be implement as services– Choose Web Service tools that encourage SOA

• Building enterprise-wide service infrastructure is not easy • Start simple, start small, start building experience!• Immediate cost savings are possible, even with small

projects• Make sure the prerequisites are there

– Tools, Education– Team structure– Incentives (and lack of dis-incentives)

6-20

Summary• Most guidelines are common sense

– think back to the component reuse discussions of yesteryear!• Using one or two Web services ≠ having a SOA

– To justify the term “service-oriented”, a significant part of the functionality should be implement as services

– Choose Web Service tools that encourage SOA• Building enterprise-wide service infrastructure is not easy • Start simple, start small, start building experience!• The ROI can be short term

– Even small projects can use SOA principles to give good architectures (this is the system-level equivalent of functional decomposition)

• And good architectures are easier to implement– Re-use can happen early if you provide the incentives

• Make sure the prerequisites are there– Tools, Education, Team structure– Incentives (and lack of disincentives)


Chapter 7:Advanced Topics

Where things are now and where they are going …

Version 7

7-2

Section 7 – Advanced Topics

• Enterprise Web Services • Industry trends and organizations • Security and Reliability• Transactions• Choreography and Orchestration

– Composite web services• Interoperability Requirements

– Encoding discussion • Futures


7-3

Enterprise Web Services

• Extending WS throughout the enterprise and among enterprises ⇒ greater emphasis onQualities Of Service (QoS)

• Security, Reliability, Transactions, Scalability• Systems Management • Interoperability

• It’s also important to allow it to be used over more transports(other than SOAP over HTTP)– IIOP (CORBA)– MQ Series messaging– TIBCO Rendezvous– Tuxedo– SOAP over FTP– JMS (J2EE)

7-4

Enterprise Standards are Evolving

SOAPMessage Payload

UDDILook-Up & Discovery

WSDLService Contract

XML Encryption, XKMS,XRML, WS-Security, SAML Security

Transactions WS-CAF, WS-T & WS-C

Management Web ServicesDistributed Management (WSDM)

Orchestration BPEL4WS, WS-Choreography

Reliable Messaging WS-Reliability,WS-ReliableMessaging

Others WS-Eventing, WS-Notification, WS-Resource Framework

Competing Standards Bodies

• Microsoft & IBM• Sun & Oracle• Others

Competing Vendor Groups


7-5

Industry organizations

• Helping to develop the necessary web services related standards– W3C

• SOAP (XMLP working group), WSDL, WS Architecture, WS Choreography

– OMG• IDL to WSDL, WSDL to IDL (WSDL 1.1), WSDL to C++

– OASIS• UDDI, WS-Security, WS-Reliability, WS-CAF, etc.

– JCP (Java Community Process)• JAX-RPC, JWSDL, JAXM, JAXR, …

– Others• WS-I, etc.

7-6

Security• Confidentiality – no one can see my data• Integrity – my data gets there in one piece• Authentication – a user or program is confirmed to be

who they say they are• Authorization – ensuring access to services and data

only by those who are supposed to access them• No overall architecture yet defined

– May include firewalls, proxies, security servers, and identity management

• WS-Security a well-agreed framework (OASIS)

Security


7-7

SOAP Header example (WS-Security)

<S11:Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu="...“ xmlns:ds="..."><S11:Header>

<wsse:Security xmlns:wsse="..."> <fabtok:CustomToken wsu:Id="MyID" xmlns:fabtok="http://fabrikam123/token“ />

<ds:Signature> . . . </ds:Signature><ds:SignedInfo> . . . </ds:SignedInfo>

</wsse:Security></S11:Header>

...</S11:Envelope>

Security

7-8

Reliability requirements• Reliability of message delivery is critical to many

applications– Guarantee of message delivery (both request and response)

• At least once (duplicates are allowed)• At most once (“best effort”, ok to drop some messages)• Once and only once

– Eliminate duplicates (if any)– Preserve message ordering (when important)

• Some of these features are provided as standard when WS are carried on a connection-oriented protocol– The “sessions” and correlation IDs of the connection-oriented

protocol ensures features such as ordering– But some QoS must still be added (e.g., store-and-forward to

allow clients to send messages even if a server isn’t running)

Reliability


7-9Example message flow

(WS-ReliableMessaging)

Reliability

7-10

Web Services: Implications for TP

• Persistent sessions are missing from HTTP– Need to define a common context sharing mechanism– Transport “agnostic” means LCD

• It’s difficult to write a new WS spec that assumes a more sophisticated protocol than HTTP

• Need a solution that is also suited for document-oriented transactions– Compensation, transactional “queues” needed– Reliable messaging needed

• Business process orchestration– Cancel/adjust transactions in long-running flight – Mixture of existing and new technologies

Transaction Processing


7-11

Current status of standardization• First attempt – SOAP-TIP

– Didn’t work because it assumed persistent sessions (and these aren’t provided by HTTP)

• XAML died– No one really wanted World Wide XA

• BTP not widely implemented– A bit complex and hard to map to existing systems

• WS-Coordination and WS-Transaction not open– Difficult to implement because it’s under-specified,– and it’s not very interoperable

• WS-Composite Application Framework (WS-CAF)– Current proposal at OASIS– Is able to co-ordinate between different transaction systems

• Resolves the differences in the co-ordinator, not in the end-points

TP

7-12

Web Services Composition• Once you have a “critical mass” of Web services, you

may want to:– link them together to create (composite) complex Web services– implement whole business processes based on those services

• Of course you can “hard-code” this, but the result will be– inflexible (hard to maintain)– proprietary, not explicit (business logic will be buried in code)

• Better: Standardized high-level mechanisms for defining business processes– Standardized declarative, non-programmatic way to compose

sequences of web service calls to accomplish a business function

• Efforts ongoing to provide– WS-BPEL (seems to be winning at present)– WS-Choreography (more B2B oriented)

Composition


7-13

AdaptersMessage queuing system – A2A/B2B Integration broker

.NET Server Or App Server

With WebService APIs

Other applications

Orchestration Architecture

Database tables and stored procedures

ERP, CRM, Accounting

, etc.

Web service interfaces

Composition

Often, you have selection and loops as well just sequencing

This overall sequence is viewed as a WS from outside

You can also do transformation of data within this overall WS

7-14

Interoperability Requirements

• Within the enterprise and among enterprises– Across hardware platforms, operating systems, programming

languages, middleware and component technologies

• SoapBuilders and WS-I have been working to correlate the many WS standards into more interoperable configurations. E.g.,– Defining a consistent selection of standards– Subsetting (“profiling”) a standard

• Ensuring compatible message encoding is another key part of interoperability– As discussed in the new few slides

Interoperability


7-15

You have a choice of the encoding for complex data in msgs

• The recommendation is literal– This uses XMLSchema in the normal way

• The message references a schema that defines the elements and types for formatting arrays, sequences, records/structures, and other complex types

• The message uses these elements and types

• The alternative is SOAP encoded– This defines a set of elements that can be used for complex data

• Mostly, these elements were good at formatting data that typically arises in RPC calls

– It was first introduced before XMLSchema was available• Newer versions (SOAP 1.2) use XMLSchema.

– The difference then between it and literal is that SOAP encoded fixes the set of tags/types. This has advantages and disadvantages.

– Many existing Web Services use SOAP encoded, but literal is recommended by WS-I for SOAP 1.1

• WS-I hasn’t yet profiled SOAP 1.2, so it is silent on whether SOAP encoding is OK in SOAP 1.2

Encoding & Message Style

7-16You also have a choice between two

message styles• The choice is rpc or document

– document style is recommended by WS-I for SOAP 1.1 (albeit most existing Web services examples use rpc style)

• Recall that each operation has an input and an optional output message– In rpc style, each message can have zero or more parts

<message name=“getQuoteRequest”><part name=“symbol” type=s:string”><part name=“date” type=“s:string>

</message>– In document style, each message can have at most one part (and

this needs to be an XML element, not a type).

WS-I has yet to profile SOAP 1.2


7-17

Combining these two choices:

document RPC

literal

SOAPencoded

This combination is used by many existing services.

Encoding & Message Style

7-18

Futures – Quickly !!

• Advances in Standards– Ratification of newer versions of standards (SOAP, WSDL, etc.)– Emergence of newer standards to support the evolution of WS

into enterprise environments (WS-CAF, etc.)

• Advances in deployment support– Additional availability of transports/protocols for greater

penetration within enterprises without requiring infrastructure changes

• Interoperability advances– More shake-out of interop issues– More adoption of recommendations from WS-I, OASIS, etc

Futures


Chapter 8:Summary, References and Useful links

Version 3

8-2

Summary

• Challenges facing systems integration across heterogeneous networks, operating systems, software development environments and third party systems

• Service Oriented Architecture provides a paradigm for organizing high-level solutions to integration problems by emphasizing a simple service client and provider model

• Web Services exploit SOA concepts with implementations over ubiquitous (Web-based) transports and using platform-independent messaging technology standards

• Tools and technologies for Web Services simplify the design, development and deployment of solutions

• Stability and maturity of technologies still an issue but rapidly improving – with significant efforts in delivering enterprise Qualities of Service over Web Services


8-3

Summary (cont.)

• We have only scratched the surface of the detailed technology emerging around Web Services – We could spend much more time on each of the

technologies and tools areas you have seen today.• Plenty of reference and research material to

consider in doing your own research – See the following slides on links, references and

books– Try doing a Google Search on “Web Services” !!!

8-4Sources and Links• W3C - World Wide Web Consortium

– http://w3c.org/• OASIS - Organization for the Advancement of Structured Information Standards

– http://oasis-open.org/• WS-I - Web Services Interoperability Organization

– http://www.ws-i.org/• Worldwide Institute of Software Architects

– http://www.wwisa.org/• Enterprise Architect Online

– http://www.enterprise-architect.net/• Web Services Architect

– http://www.webservicesarchitect.com/• John McDowall’s homepage and blog

– http://www.mcdowall.com/• Mary Shaw’s homepage

– http://spoke.compose.cs.cmu.edu/shaweb/


8-5Sources and Links (Cont.)• Web Services Journal

– http://sys-con.com/webservices/• The Zachman Framework

– http://www.zifa.com• DevX web site

– http://www.devx.com/• Web Services.org

– http://www.webservices.org/• IBM DeveloperWorks – Web Services

– http://www-106.ibm.com/developerworks/webservices/• XML & Web Services Magazine

– http://www.ftponline.com/xmlmag/• .NET Magazine (now known as Windows Server System)

– http://www.ftponline.com/wss/• JavaPro

– http://www.ftponline.com/javapro/

8-6

Books

• Eric Newcomer : “Understanding Web Services: XML, WSDL, SOAP, and UDDI”, Addison-Wesley, Paper-back, 368 pages, May 2002, ISBN: 0201750813

• James McGovern (Editor): “Java Web Services Architecture”, Morgan Kaufmann, 831 pages, April 2003, ISBN: 1558609008

• William L. Oellermann Jr.: “Architecting Web Services”, Apress, Paperback, 672 pages, October 2001, ISBN: 1893115585

• Martin Fowler: “Patterns of Enterprise Application Architecture”, Addison-Wesley, 560 pages, November 2002, ISBN: 0321127420


8-7

Books (cont.)

• M. L. Brodie, M. Stonebraker: “Migrating Legacy Systems: Gateways, Interfaces, and the Incremental Approach”, Morgan-Kaufman, 1995

• Scott Seely, Eric Smith, Deon Schaffer: “Creating and Consuming Web Services in Visual Basic”, Addison-Wesley, Paperback, 394 pages, May 2002, ISBN: 0672321564

• Henry Bequet, Meeraj Moidoo Kunnumpurath, Sean Rhody, Andre Tost: “Beginning Java Web Services”, WROX, Paperback, Sept. 2002, ISBN: 1861007531

• Cauldwell et al: “Professional XML Web Services”, WROX, Paperback, 803 pages, 2001, ISBN: 1861005091

8-8

Thank You

web services foundations

Documents