Extended Web Services Standards

Extended Web Services Standards

Innoq Web services standards

overview

Groups of Web services (WS*)

standards

●

Messaging

●

Description and discovery / Metadata Specifications

●

Reliability / Reliable messaging

●

Transactions

●

Security

●

Business processes

Messaging WS* standards

●

These messaging standards and specifications are

intended to give a framework for exchanging

information in a decentralized, distributed

environment.

– SOAP 1.1 (Note)

– SOAP 1.2 (Specification)

– Web Services Addressing, Web Services Eventing, Web

Services Enumeration

– Web Services Notification (WS-BrokeredNotification,

WS-BaseNotification, WS-Topics)

– Web Services Attachments Profile 1.0

MTOM

● MTOM (Message Transmission Optimization Mechanism) is

helpful when SOAP messages contain a large amount of binary data, for example, when transmitting binary files such as bitmap images and movies. In order to be transported in a SOAP

envelope, binary data normally must be encoded using base 64 (base64binary) to ensure it can be correctly parsed by the

receiver in all cases. This effectively increases its size in the SOAP envelope by a third. MTOM allows binary data to be pulled out of the SOAP envelope and attached in a more

MTOM in WCF

● Method with [MessageContract] attribute, not [DataContract], or

"primitive" types;

● Byte array properties - [MessageBodyMember] attribute, not

[DataMember] nor [MessageHeader], and all the other properties - [MessageHeader] attribute;

● Byte[] or Stream object, the results are the same

● All eventual classes that the parameter or return classes derive

from must also have the [MessageContract] attribute;

● In the <binding> elements for you service (both client and

WS-MetadataExchange

●

WS-MetaDataExchange is designed to work in

conjunction with Addressing, WSDL and

WS-Policy to allow retrieval of metadata about a Web

Services endpoint. It uses a SOAP message to

request metadata, and so goes beyond the basic

technique of appending "?wsdl" to a service name's

URL

WS-Addressing

● Universal mechanism of addressing, action and message

identification

● Drawbacks of HTTP

– proxy, firewall may change addresses

– not always used (SMTP)

● Attached to SOAP as a header

● Transparent management of requests / responses

WS-Addressing

●

WS-Addressing – Core

–

provides transport-neutral mechanisms to address

Web services and messages. This specification

defines XML elements to identify Web service

endpoints and to secure end-to-end endpoint

identification in messages.

●

WS-Addressing – WSDL Binding

–

defines how the abstract properties defined in Web

Services Addressing – Core are described using

WSDL.

●

WS-Addressing – SOAP Binding

–

provides transport neutral mechanisms to address

WS-Addressing in

WCF

●

Windows Communication Foundation vs .NET Web

services

–

System.Web.Services, System.ServiceModel

–

WSDL contents for .NET WS, WCF

●

WCF

Rodzaje WCF bindings

●

Określenie charakterystyk

–

warstwa transportowa (HTTP, MSMQ, named pipes,

TCP)

–

rodzaj kanału (one-way, request-reply, duplex)

–

kodowanie (encoding) (XML, binarny)

Wybrane WCF bindings

●

HTTP - based bindings

–

BasicHttpBinding - Web service zgodny z WS-I

Basic Profile (backward compatibility)

–

WSHttpBinding - wsparcie dla większej liczby WS-*

features - WS-Addressing, transactions, reliable

messaging, MTOM

●

TCP - based bindings

–

NetTcpBinding - cross-machine between .NET

applications

●

MSMQ - based bindings

–

NetMsmqBinding - zalecany dla MSMQ -

WS-Addressing

alternative options

● Endpoint reference <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing"> <wsa:Address>http://wso2.org/addressing/sample</wsa:Address> </wsa:EndpointReference> ● Message type

– wsa:To, wsa:From, wsa:Action

– ReplayTo, MessageID, RelatesTo

● request-responce pattern, specify receiver,

sender, target response receiver

● request assignes MessageID and ReplayTo

● To used in responce, RelatesTo contains request

WS-Eventing, WS-Notification

●

WS-Eventing

–

WS-Eventing defines a baseline set of operations

that allow Web services to provide asynchronous

notifications to interested parties.

–

uses WS-Addressing to indicate subscription,

renew/cancel subscription, check status

●

WS-Notification

–

a family of related white papers and specifications

that define a standard Web services approach to

notification using a topic based publish/subscribe

pattern.

Transactions WS*

●

Transactions are a fundamental concept in building

reliable distributed applications. A web service

environment requires coordination behavior provided

by a traditional transaction mechanism to control the

operations and outcome of an application.

–

Web Services Atomic Transaction

–

Web Services Business Activity

–

Web Services Coordination

Traditional transactions

●

Atomicity: If successful, then all the operations

happen, and if unsuccessful, then none of the

operations happen.

●

Consistency: The application performs valid state

transitions at completion.

●

Isolation: The effects of the operations are not shared

outside the transaction until it completes successfully

●

Durability: Once a transaction successfully completes,

WS/Workflow transactions

●

More relaxed forms of transactions -- those that do not

strictly have to abide to the ACID properties

–

collaborations, Workflow, Realtime processing

●

Long running transaction

–

compensation vs rollback

–

example:

WS-* transactions

in WCF

● Demo

● Protokoły transakcyjne Windows

– Lightweight - single AppDomain, single Resource

Manager (system przechowujący dane)

– OleTx - cross AppDomain, machine calls, no

cross-platform

– WSAT - interoperable communication

● Transaction managers

– Lightweight TM (LTM) - Lightweight protocol

– Kernel Resource Manager (KRM) - Lightweight protocol

– Distributed Transaction Manager (DTC)

WS-* transactions

in WCF

● Transaction managers - wybór automatyczny przez system

– Promotion - zmiana managera współpracującego z RM

● Wsparcie przez WCF binding

– np. NetNamedPipeB..., NetTcpB..., WSHttpBinding

– transactionFlow="true", domyślnie wyłączone

● TransactionFlow(TransactionFlowOption.

– NotAllowed - klient nie może propagować transakcji do

serwera, ignorowany, nie wyrzuca wyjątku

– Allowed - obsługiwana transakcja, jeżeli klient żąda, jak

nie, to nie, wyrzuca wyjątek, jeżeli klient żąda transakcji, a binding nie wspiera jej

– Mandatory - wymagany binding wspierający transakcje i

WS-Coordination

●

WS-Coordination provides standard mechanisms to create

and register services, using the protocols defined in the

WS-Transaction specification that coordinate the execution

of distributed operations in a Web services environment

(for example, atomic transaction protocols, long-running

business transaction protocols, etc.). It also provides an

important foundation layer that will help developers control

operations that span across broadly interoperable Web

services.

–

Protocols for Atomic Transactions.

–

Protocols for Business Transactions

WS-Coordination

●

Activation Service

– The activation service uses the create message to:

● begin a new activity

● specify the coordination protocols available to the

activity

●

Registration service

– The registration service 'register' allows a Web service to

register and to select a protocol for the activity.

●

Coordination service

– concrete coordination protocol (WS-AtomicTransaction,

WSBusinessActivity)

– controls the activity completion processing for the

Coordination context

● Identifier: a unique name to identify the CoordinationContext

● Expires: an activity timeout value

● CoordinationType: a defined set of coordination protocols that

describe the supported completed processing behaviors

● Registration Service: address of the registration service, the

service is used to register interest and participation in a

coordination protocol for determining the overall outcome of the activity.

● Extensibility element: provides for optional

Protocols for

Atomic Transactions

●

The protocols for atomic transactions handle activities that

are short-lived. Atomic transactions are often referred to as

providing a two-phase commitment protocol. The

transaction scope states that all work is completed in its

entirety, that is, that the result of an activity, if successful,

is that all operations are performed, or if unsuccessful, that

no operations have been performed. Upon successful

completion the results of the activity are available to other

users.

Protocols for

Business Transactions

●

The protocols for business transactions handle long-lived

activities. These differ from atomic transactions in that,

such activities can take much longer to complete, and to

minimize latency of access by other potential users of the

resources used by the activity, the results of interim

operations need to be released before the overall activity

has completed. In light of this, mechanisms for fault and

compensation handling are introduced to reverse the

affects of previously completed business activities (for

example, compensation, reconciliation, etc).

Reliability WS*

●

It is not possible to solve business issues if the

participants are unable to be sure of the completion of

message exchanges. Reliable messaging, which

allows messages to be delivered reliably between

distributed applications in the presence of software

component, system, or network failures, is therefore

critical to web services.

–

Web Services Reliable Messaging

–

WS-RM Policy Assertion

Reliability WS*

●

WS-ReliableMessaging

–

describes a protocol that allows Web services to

communicate reliable in the presence of software

component, system, or network failures. It defines a

SOAP binding that is required for interoperability.

●

(WS-Reliability)

–

is a SOAP-based protocol for exchanging SOAP

messages with guaranteed delivery, no duplicates,

and guaranteed message ordering. WS-Reliability is

defined as SOAP header extensions and is

independent of the underlying protocol. This

specification contains a binding to HTTP.

WS-Reliable Messaging

●

An Application Source (AS) wishes to reliably send

messages to an Application Destination (AD) over an

unreliable infrastructure. To accomplish this they make

use of a Reliable Messaging Source (RMS) and a

Reliable Messaging Destination (RMD). The AS sends

a message to the RMS. The RMS uses the

WS-ReliableMessaging (WS-RM) protocol to transmit the

message to the RMD. The RMD delivers the message

to the AD. If the RMS cannot transmit the message to

the RMD for some reason, it must raise an exception

or otherwise indicate to the AS that the message was

not transmitted.

WS-Reliable Messaging

Delivery Assurances

● AtLeastOnce - Each message will be delivered to the AD at

least once. If a message cannot be delivered, an error must be raised by the RMS and/or the RMD. Messages may be

delivered to the AD more than once (i.e. the AD may get duplicate messages).

● AtMostOnce - Each message will be delivered to the AD at

most once. Messages may not be delivered to the AD, but the AD will never get duplicate messages.

● ExactlyOnce - Each message will be delivered to the AD exactly

once. If a message cannot be delivered, an error must be raised by the RMS and/or the RMD. The AD will never get duplicate messages.

● InOrder - Messages will be delivered from the RMD to the AD in

the order that they are sent from the AS to the RMS. This

WS-* Management

● Web services manageability is defined as a set of capabilities

for discovering the existence, availability, health, performance, usage, as well as the control and configuration of a web service within the web services architecture. As web services become pervasive and critical to business operations, the task of

managing and implementing them is imperative to the success of business operations.

● Web Services Distributed Management

● Management Using Web Services (WSDM-MUWS)

● Management Of Web Services (WSDM-MOWS)

● Web Services Manageability -- Concepts, Representation

● WS-ResourceTransfer, Web Services Service Registry and

Web Services Distributed

Management

●

Complexity of managing the business

●

Value for customers, suppliers of management

software, manufactures of devices

●

Depend on other specifications

–

WS-Resource Framework (WS-RF) Resource

Properties (WSRP) for properties

–

WS-Notification (WSN) Base Notifications (WSBN)

for management event transport

Web Services Distributed

Management

●

WS manageable printer

●

Customers gain visibility

into functional aspects of

a resource

–

print, properties

●

Business-oriented

consumers gain visibility

into management aspects

of a resource

–

toner, failures

–

start, stop

Management Using

Web Services (WSDM-MUWS)

●

Management Using Web Services (MUWS) 1.0

specifications define how to represent and access the

manageability interfaces of resources as Web services

Management Using

Web Services (WSDM-MUWS)

●

Capabilities

–

uniquely identified in time and environment,

–

has defined semantics (such as those provided by

any section in this specification that describes a new

capability),

–

is associated with a set of:

● properties, operations, events (notifications) and

metadata (including policies).

●

Composability

Management of Web Services

(WSDM-MOWS)

●

Management of Web Services (MOWS) 1.0

specification defines how to manage Web services as

resources and how to describe and access that

Management of Web Services

(WSDM-MOWS)

● Identity -- defines a unique identity for the Web service.

● Identification -- capability defines a reference to the Web service

being managed.

● Metrics -- defines a set of basic metrics for a Web service: NumberOf

Requests, NumberOfFailedRequest, NumberOfSuccessfulRequests, ServiceTime, MaxResponseTime, and LastResponseTime.

● OperationalState -- capability provides the current operational state of

the service. The valid states are Up with substates of Busy and Idle and Down with substates of Stopped, Crashed, and Saturated.

● OperationalStatus -- provides the high-level status of the services: all

Up states return Available and all Down states return as status of Unavailable, except for Saturated which returns PartiallyAvailable.

● RequestProcessingState -- capability defines a request state diagram

and provides a mechanism to define events to be sent when request processing states change.

Bibliography

●

Standards and specification:

–

OASIS

–

World Wide Web Consortium

–

Web Services Interoperability Organization

●

innoQ GmbH

–

Web Services Standards Overview, 2007

●

IBM Developerworks

–

Transactions in the world of Web services

●

MSDN