Web Services

Transcript Web Services

Web Services
Overview




Why Web Services
What’s Web Services
Web Services Framework
insfrastructure
Why Web Services?
Example Problem Space
Credit
Service
Purchase
Invoice
Order
Client
Consolidate
Results
PO Service
Inventory
Service
Early (Internet) Technologies

SMTP/MIME

e-mail is still the killer app
FTP, NNTP
 HTTP/HTTPS, HTML


the protocol behind Internet’s popularity
Most of these facilitated app to human interaction
over the Internet/intranet
Early (intranet) Technologies



DCE from OSF -- RPC based, procedural
ORB -- object oriented, mostly synchronous
 CORBA, COM/DCOM from Microsoft, Java RMI/EJBs
MOM -- message oriented, synchronous as well as
asynchronous
 JMS ( Java API standard )
 Many proprietary implementations
Most of these facilitated app2app interaction within a
trusted intranet and without much consideration to
interoperability across different implementations.
Today’s Web



Web designed for application to human interactions
Served very well its purpose:

Information sharing: a distributed content library.

Enabled B2C e-commerce.

Non-automated B2B interactions.
How did it happen?

Built on very few standards: http + html

Shallow interaction model: very few assumptions made about
computing platforms.

Result was ubiquity.
The issue: Unleashing B2B
(and G2B!)



As mentioned above, most Web apps are for business-to-consumer (B2C):
person at browser
 Still too hard to build distributed applications that connect businesses
 Risk losing customers if you provide URL links to a partners' website
Business-to-business (B2B) apps have been highly touted, but suffered for
the following reasons:
 Isolation of business processes because of incompatible systems
 Microsoft's DCOM, Sun J2EE's
 Bridges available but app server vendor specific
 Solutions were too costly or too complex to implement
 Business relationships change such as mergers and acquisitions
 Accelerated pace of change in technology and standards
 ASP 2.0, ASP 3.0, ASP.NET
 EJB 1.0, EJB 1.1, EJB 2.0
Need a simple, standard framework for B2B applications
What’s next?



The Web is everywhere. There is a lot more we can do!

E-marketplaces.

Open, automated B2B e-commerce.

Business process integration on the Web.

Resource sharing, distributed computing.
Current approach is ad-hoc on top of existing standards.

e.g., application-to-application interactions with HTML forms.
Goal:
enabling systematic application-to-application interaction
on the Web.
The Web Services Way
Web Services standards (SOAP, WSDL, … ):
based on widely accepted Internet friendly
technologies (HTTP/HTTPS, XML, …), are
mostly orthogonal to each other and enjoy
broad support from vendors
Web Services: Network accessible programs, expose functionality by receiving/sending SOAP
messages over HTTP/HTTPS, and describe this interface as WSDL descriptions.
App2App Interaction -- the
Web Services Way





Transport protocol
 HTTP/HTTPS
Data Encoding
 SOAP (Simple Object Access Protocol), XML Schema
Interface Description
 WSDL (Web Services Description Language)
Service Description and Discovery
 UDDI (Universal Description, Discovery and
Integration)
Security
 WS-Security, XML-Signature, XML-Encryption, ...
What’s a Web Service?
“Web services” is an effort to build a
distributed computing platform for the Web.
Yet another one!
What’s a Web Service?

A web service is a software component
 Exposes a business function/service/chunk of data
 Can be accessed by another application over Internet
 Messages are exchanged using a standard XML format
Application Server (J2EE or .NET)
<html>
Business logic
Web Application
Business
<xml>
<html>
<xml>
Agency
Web Service
What’s a Web Service?

A program programmatically accessible over
standard internet protocols

Loosely coupled, reusable components

Encapsulate discrete functionality

Distributed

Add new level of functionality on top of the
current web
Web Services Model
Web service applications are
encapsulated, loosely coupled Web
“components” that can bind dynamically
to each other
Web Services Model
Language and platform independent =>
separation of specification and implementation
Loosely coupled =>
message based, synchronous and asynchronous
interactions.
Over the Internet =>
No centralized control, use of established
protocols, security considerations.
Inter-operable =>
Standards based.
How Web Services Helps







Cross-platform, cross-language support
 Java, .NET, PHP, Perl, Python
Based on industry standards (W3C)
 Catches the XML wave
 XML, SOAP, WSDL, UDDI
Supported by many vendors
 Unlike CORBA
Relatively easy to implement
Service publication and lookup
 Conduct business without prior relationship
Loosely coupled
 Low demands on network quality
 Based on request/response model
Enables public/private cooperation on information products
Web Services Framework
Web Services Framework
Web Services Framework

Framework can be described in terms of

What goes “on the wire”:
Formats and protocols.

What describes what goes on the wire:
Description languages.

What allows us to find these descriptions:
Discovery of services.
The Web Services Stack
Wire Protocols
Description
Discovery
SOAP Blocks
Agreements
SOAP/XMLP
Process
XML
WSDL Extensions
HTTP/SMTP/BEEP
WSDL
Registry (UDDI)
TCP/IP
XML
Inspection
The Web Services Stack helps us understand how each of the various pieces fit into the “Big Picture”
The Web Services Stack

Wire Protocols



Primary Role: provide a standard, flexible
communications channel
Secondary Role: provide a standard, flexible wirelevel data representation
Advantage: interoperability at the lowest level
The Web Services Stack

Description

Primary Role: provide a standard, flexible way to
describe what and how a Web service does what
it does.

Advantage: interoperability
The Web Services Stack

Discovery

Primary Role: provide a standard, flexible way to
discover where a Web service is located and
where to find more information about what the
Web service does (the description)

Advantage: interoperability, dynamic integration
WS-Resource Framework
Capabilities
Specifies how to use XML to describe and access a
resource’s properties
Clarifies how stateful resources are addressed
Defines how a resource is created and messages to
destroy resources
Provides a message subscription and notification
mechanism for Web services
 Outlines how to organize groups of resources and
services
 Adds a fault tolerance capability to WS-Addressing
 Defines a standard, extensible format for Web
services error messages
Web Services and Stateful
Resources

“State” appears in almost all applications




Data in a purchase order
Current usage agreement for resources on a grid
Metrics associated with work load on a Web
server
There are many possible ways Web services
might model, access and manage state

The WS-Resource framework proposes to
standardize this capability for Web services
The WS-Resource framework
model
Web Service
Run-time environment
WSDL
Interface
Web
Service
The WS-Resource framework
model
Invoking a Web Service
Endpoint
Reference
Run-time environment
message
message
Interface
address
Web
Service
The WS-Resource framework
model

What is a WS-Resource
 Examples of WS-Resources:
 Physical entities (e.g.. processor, communication link, disk
drive)
or Logical construct (e.g.. agreement, running task,
subscription)

Real or virtual

Static (long-lived, pre-existing) or
Dynamic (created and destroyed as needed)

Simple (one), or Compound (collection)
resource

Unique - Has a distinguishable identity and lifetime

Stateful - Maintains a specific state that can be materialized
using XML

May be accessed through one or more Web Services
The WS-Resource framework
model
Using a Web service to access a WS-Resource
Endpoint
Reference
id
Run-time environment
message
message
id
Interface
address
resource
Web
Service
contex
t
The WS-Resource framework
model
Using a Web service to access a WS-Resource
Endpoint
Endpoint
Reference
Reference
id
Run-time environment
message
message
id
Interface
address
resource
Web
Service
resource
context
The WS-Resource framework
model
Creating / Locating a WS-Resource
Endpoint
Reference
Run-time environment
message
Endpoint
Reference
id
resource
addres
s
message
Interface
address
Web
Service
Web Service
either locates or
creates a WSResource
The WS-Resource framework
model

WS-Resource Properties



Resource state and metadata
“Projected” as an XML document
Query and Set operations
WS-Resource LifeTime


Explicit destruction or
“Soft state” time-to-live
Provides for cleanup
of resource instances
resource
<ProcessorProperties>
<ProcID>5A34C1DE03</ProcID>
<ProcArchitecture>Power6.2</ProcArchitecture>
<ProcSpeedMIPS>400</ProcSpeed>
<ProcCacheMB>256<ProcCache>
<ProcRunning>1</ProcRunning>
</ProcessorProperties>
The WS-Resource framework
model
Architecture rationale
 WS-Resource framework exploits WS-Addressing
 Web services and WS-Resources are referenced
using an “Endpoint Reference”
 Services that create or locate WS-Resources return
Endpoint References
 Web service and WS-Resource are separate:
 A Web service is stateless
 A WS-Resource provides a context for stateful
execution
 Different entities, different lifetimes, different
capabilities
Web Services Infrastructure
Language and platform independent
infrastructure for loosely-coupled, interoperable, app2app communication over the
Internet.
Additional Web Services
Infrastructure Components

Key Management (Security)


Web Services Management


XKMS
OMI (Open Management Interface)
...
Interesting thing to note is that these
are Web Services in themselves
XML Messaging: SOAP





XML based protocol for
exchange of information
 Encoding rules for
datatype instances
 Convention for
representing RPC
invocations
Designed for loosely-coupled
distributed computing
 No remote references
Used with XML Schema
Transport independent
SOAP with Attachments
allow arbitrary data to be
packaged.
SOAP1.1 Message
Structure
SOAP
Envelope
Header
Entries
[Header
Element]
Body
Element
[Fault
Element]
XML Messaging: SOAP

SOAP 1.1 defined:





An XML envelope for XML messaging,
 Headers + body
An HTTP binding for SOAP messaging.
 SOAP is “transport independent”.
A convention for doing RPC.
An XML serialization format for structured data
SOAP Attachments adds

How to carry and reference data attachments using in a
MIME envelope and a SOAP envelope.
The SOAP Envelope
<SOAP-ENV:Envelope
xmlns="http://schemas.xmlsoap.org/soap/envelope/">
< SOAP-ENV:Header>
...
</ SOAP-ENV:Header>
< SOAP-ENV:Body>
...
</ SOAP-ENV:Body>
...
</ SOAP-ENV: Envelope>
What goes on the wire


Internet-scale integration
needs a lingua-franca
 XML messaging protocol
over HTTP: SOAP
Intra-enterprise integration
needs to allow alternates:
 CORBA, RMI
 Messaging
 In-memory method calls
Context
Transactions
Routing
Reliability
Security
SOAP
W3C
Attachments


Integration requires
interoperable machineunderstandable descriptions
Agreements
Enables dynamic, delayed
binding of components.
Public Flows
Language extensibility provides
support for different levels of
application integration.
Flows and
Composition
Service QoS
Service
Interface
XML Schema
WSDL

WSFL
Descriptions: Meta-data
Web Services Description Language


Provides functional description of network services:

IDL description

Protocol and deployment details

Platform independent description.

Extensible language.
A short history:

WSDL v1.0, 9/2000

WSDL v1.1 submitted to W3C 3/2001.

A de facto industry standard.
WSDL - Overview

A WSDL document describes
What the service can do
 Where it resides
 How to invoke it

WSDL are like IDL but lot more flexible and
extensible
 Defines binding for SOAP1.1, HTTP
GET/POST and MIME
 WSDL descriptions can be made available
from an UDDI registry

WSDL - Overview

WSDL is a simple XML grammar for describing how
to communicate with a Web service




It defines the messages (both abstract and concrete) that
are sent to and from a service
It defines logical collections of messages (“port type”,
“interface”)
It defines how a given “port type” is bound to particular
wire protocols
It defines where the service is located
WSDL Overview


WSDL is extensible.
WSDL was created by IBM and Microsoft



The intent was to create something that worked,
not something that was complete
Creating a formal Web Services “data model” was
not a priority
WSDL is RDF-compatible (not RDFcompliant)
WSDL Structure
WSDL1.1 Document
Structure
WSDL
Document
[Types]
{Messages}
{Port Types}
{Bindings}
{Services}
WSDL Structure
Service

portType


Multiple bindings per
portType:



Abstract definition of a
service (set of operations)
How to access it
SOAP, JMS, direct call
Ports

Where to access it
Port
Port
Binding
Binding
(e.g. http://host/svc)
(e.g. SOAP)
portType
operation(s)
inMesage
outMessage
Abstract interface
WSDL - example
<definitions>
<types>  </types>
<message name=“getQuote_In” />
<message name=“getQuote_Out” />
<portType name=“StockQuoteServiceInterface”>
<operation name=“getQuote”>
<input message=“getQuote_In” />
<output message=“getQuote_Out” />
Definition of data types
Definition of messages
Definition of port type
Definition of the bindings
</operation>
</portType>
<binding name=“StockQuoteServiceBinding” type=“StockQuoteServiceInterface”>
<soap:binding transport=“http://schemas.xmlsoap.org/soap/http” />
…
</binding>
Definition of the service
<service name=“StockQuoteService”>
<port name=“StockQuoteServicePort” binding=“StockQuoteServiceBinding”>
<soap:address location=“http://www.acme.com/services/stockquote” />
</port>
</service>
</definitions>
Using WSDL
1.
2.
3.
4.
As extended IDL: WSDL allows tools to generate compatible
client and server stubs.

Tool support for top-down, bottom-up and “meet in the
middle” development.
Allows industries to define standardized service interfaces.
Allows advertisement of service descriptions, enables dynamic
discovery and binding of compatible services.

Used in conjunction with UDDI registry
Provides a normalized description of heterogeneous
applications.
Client invocation




Single stub can invoke services
over different bindings

Depends only on abstract
interface.
Are independent of binding (but
pluggable).

Add new bindings without
recompiling/redeploying
stub
Allows optimisations based on
the bindings of service.
Will support extended services
models if described In WSDL
RMIIIOP
Client Proxy
object
SOAP/
HTTP
JMS/
MQ
WSFL Overview

WSFL describes Web
Service compositions.
1. Usage patterns of Web
Services: describes
workflow or business
processes.
2. Interaction patterns:
describes overall
partner interactions.
[ WS]
[ WS]
A
C
B
WSFL Flow Models
Control links define
execution flow as a
directed acyclic graph
Activities represent
units of processing.
[ WS]
Flow of data is
modeled through
data links.
Activities are associated
with specific typed
service providers
Activities can be
mapped to the flow
interface
Using Flow Models

“Public flows” provide a representation of the service behavior as
required by its users.





“Private flows” are the flows executed in practice.


Typically, an abstraction of the actual flow begin executed
Defines a “behavioral contract” for the service.
Internal implementation need not be flow-based.
Flows are reusable: specify components types, but not what specific
services should be used!
WSFL serves as a “portable flow implementation language”
Same language is used in WSFL to represent both types of processes.
Global Models



Global models describe how the
composed Web Services interact.
 RosettaNet automated.
 Like an ADL.
Interactions are modeled as links
between endpoints of two
service interfaces (WSDL
operations).
An essentially distributed
description of the interaction.
A
C
B
Discovery: Finding Meta-data

Static binding requires
service “libraries”.

Dynamic binding requires
runtime discovery of metadata
Directory
UDDI
Inspection
ADS,
DISCO
UDDI Overview

UDDI is:



A Web Services API for publishing and
discovering the existence of Web services
A registry for managing information about Web
services
A coalition of organizations working together to
manage UDDI registries and to further develop
the Web Services API for accessing those
registries.
UDDI Overview

UDDI is built around a “Yellow-pages” like
data model:
Business Entity
Identities
Business Services
Categories
Service Bindings
TModels
UDDI Overview

TModel = “Technology Model”
TModel
TModel Instance
Abstract metadata definition
relating to some aspect of the
UDDI registration
Implementation specific
metadata conforming to a
given TModel.
TModel = Abstract Class
UDDI Overview

TModels
 Categories & Identifiers



Categorization and Identification taxonomies are TModels
Categories and Identifiers are TModel Instances
Keyed Referenced



Examples: NAICS, UNSPSC, D&B #
WSDL Port Types



Name + Value + TModel
WSDL Port Types are TModels
WSDL Services that are bound to a Port Type are TModel Instances
WSFL Business Processes


WSFL Flow Models are TModels
WSFL Global Models are TModel instances
TModels represent the extent of UDDI’s semantic description
capabilities.
UDDI Overview



UDDI has only limited extensibility through
TModels
UDDI was created by IBM, Microsoft and
Ariba (many companies have joined the
effort)
The intent was to put something together that
worked.
UDDI Overview




UDDI Version 1.0 – September 2000 (in
production)
UDDI Version 2.0 – June 2001
UDDI Version 3.0 - In development
UDDI will be presented to a standards body
after Version 3.0
UDDI Overview

UDDI defines the operation of a service registry:



Data structures for registering
 Businesses
 Technical specifications: tModel is a keyed reference to a
technical specification.
 Service and service endpoints: referencing the supported
tModels
SOAP Access API
Rules for the operation of a global registry
 “private” UDDI nodes are likely to appear, though.
UDDI Relationships
Web Service
Web Service
businessEntity
businessEntity
businessEntity
businessService
businessService
bindingTemplate
bindingTemplate
InstanceDetails
InstanceDetails
categoryBag
keyedReference
keyedReference
identifierBag
keyedReference
keyedReference
Rosetta-Net
BASDA
Simple.Buy
Schemas,
Interchange specification
tModels
SIC CODE
NAICS
DUNS Numbers
Thomas Registry ID
WS-Notification
 WS-Notification
Brings
enterprise quality publish and subscribe
messaging to Web services

WS
Loosely coupled, asynchronous messaging in a Web
services context
Notification exploit WS Resource framework
and Web services technologies
WS-Notification
Subscriber
indicates interest in a particular “Topic”
by issuing a “subscribe” request
 Subscriber
subscribe
notify
 Broker
(intermediary) permits
decoupling Publisher and Subscriber
 “Subscriptions”
Broker
are WS-Resources
notify
 Various
 Publisher
subscriptions are possible
need NOT be a Web Service
may be “triggered” by:
 WS Resource Property value changes
 Other “situations”
 Broker examines current subscriptions
notify
subscribe
S
 Notification
 Brokers
may
 “Transform” or “interpret” topics
 Federate to provide scalability
Publisher
notify
S
S
WS-Notification

Characteristics of WS-Notification:
 Web services integration of traditional enterprise
publish/subscribe messaging patterns
 Composes with other Web services technologies
 Facilitates integration between different messaging
middleware environments
 Standardizes the role of Brokers, Publishers, Subscribers and
Consumers
 Provides two forms of publish/subscribe:
direct publishing and brokered publishing
 Standardizes Web service message exchanges for publishing,
subscribing and notification delivery
 Defines XML model of Topics and TopicSpaces to categorize and
organize notification messsages
WS-Resource framework & WSNotification
Scenario: Grid Resource Management & Scheduling
Local processor
manager
J
J
is “front-ended” with
J
A Web service interface
Grid Scheduler
Grid “Jobs” and “tasks”
Other
processors
are also
is a
arekinds
alsoofmodeled
using
Grid WS-Resources
“modeled” as same
type ofService
Web
and
Service
Scheduler WS-Resources
Resource Properties
Level
WS-Resource used to
Service
“model” Level
physical
Agreement
processor
resources
Blades
R
R
R
A
is modeledCluster
as a
Mainframe
WS-Notification
can
be
WS-Resource
used to “inform” the Lifetime of SLA
R R
R
R Properties
R scheduler
tiedRto
WS-Resource
when Resource
“project”
processor
status the duration of
processor
utilization
the agreement
(like utilization)
changes