W3C Constraints and Capabilities for Web Services

October 2004

©2004 Layer 7 Technologies Inc.©2004 Systinet Corporation

W3C Constraints and W3C Constraints and Capabilities for Web ServicesCapabilities for Web ServicesToufic Boubez – Layer 7 TechnologiesLuc Clement – Systinet

Oct 2004

W3C Constraints and Capabilities for Web Services 2


AgendaAgenda Introduce fundamental position and beliefs Discuss proposed use case Quick coverage of some additional use cases Moving up the stack:• The evolution from Web services to dynamic SOA Open Issues

Oct 2004



Web Services – PrefaceWeb Services – Preface

“A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable.” – Leslie Lamport

• Flexibility was and still is one of the most dominant themes of software engineering.

• Brittleness is still one of its most dominant realities.

Oct 2004



The Promise and Reality of Web ServicesThe Promise and Reality of Web ServicesThe Promise: Business agility through Just-in-time Integration

• How to build flexible systems: loose coupling between software components eliminate unnecessary dependencies between a service and its

consumers make late binding between them possible.

The Reality: Brittle connections, programmed at each endpoint

• Promise of loose coupling is only real for the simplest, most “vanilla” Web services (e.g. no security requirements)

• Usage preferences for services have to be hard-coded• Any changes in these preferences will cause breakages (“render your

own computer unusable”)• WSDL is essentially an IDL and only and IDL – conveys API

necessary but not sufficient only goes so far in describing access a service (could be argued

that the “D” in WSDL is not quite complete)

Oct 2004



Fundamental Beliefs and PositionFundamental Beliefs and Position Programmers should only have to worry about writing business functionality. Everything else should be:• Declarative• Configurable• Centrally managed• Delegated to the infrastructure

From a Programmer’s perspective:• WSDL describes the elements that should go in the <Body>

element of a SOAP message.• There is no agreement on a language to describe what goes

in the <Header> element. We call that “Policy”.• These two aspects of a service description are

complementary and need to be discovered dynamically using similar mechanisms.

Oct 2004



Concept of Policy Missing From WSDLConcept of Policy Missing From WSDLA Policy is simply a set of constraints and capabilities that governs how a Web service and its consumers interact.

Simple policies typically include rules describing• Who can access that service;• What kind of credentials are acceptable;• Whether encryption or signatures are required;• How messages get routed to the service;• What endpoint to use for a particular request;• If there are any necessary transformations to be applied.

The Policy concept is a very prevalent and common requirement in every aspect of IT, but nonexistent in Web services

Oct 2004



Proposed Use CaseProposed Use Case A Web service wishes to stipulate that clients:• are required to support a reliable messaging protocol, AND• encrypt a specific header with WS-Security

using a X.509 OR user name security token in order to send an acceptable

request message• Furthermore, the service has a P3P policy associated with its

operations.

(Such constraints and capabilities might be associated with the Web service via a SOAP header or a WSDL file)

Oct 2004



Proposed Use Case DiscussionProposed Use Case Discussion1. “Reliable Messaging Protocol”• Issues of semantics aside, the term is ambiguous

Is there a reference to a commonly accepted list of such protocols?

Issues of versioning of this definition.• More acceptable is a list of protocols acceptable to the service.

This is common usage pattern in other mechanisms (e.g. negotiation of encryption)

2. “Discoverability”• Although complete from an endpoint perspective, does not take into

account context of a SOA deployment: From the perspective of organizational policies, the ability to push

or replace global “corporate” policies needs to be addressed. Registering and discovering these policy documents needs to be

addressed by this group through integration with UDDI.

Oct 2004



Example Policy DocumentExample Policy Document<Policy> <AND> <OR> <Reliability>w3c:SomeProtocol</Reliability> <Reliability>w3c:SomeOtherProtocol</Reliability> </OR> <OR> <Encrypt> <XpathExpression xpathExpressionValue="included"> <Expression stringValue="SomeXPathExpression"/> </XpathExpression> <wsse:SecurityToken> <wsse:TokenType>wsse:X509v3</wsse:TokenType> </wsse:SecurityToken> </Encrypt> <Encrypt> <XpathExpression xpathExpressionValue="included"> <Expression stringValue="SomeXPathExpression"/> </XpathExpression> <wsse:SecurityToken> <wsse:TokenType>wsse:Username</wsse:TokenType> </wsse:SecurityToken> </Encrypt> </OR> <P3P policyref="SomeURL"> </AND></Policy>

Signed?

Oct 2004



Differentiated Access Use CaseDifferentiated Access Use Case

Identities in group GREEN

Corporate Network

Web Services Clients

Policy for identities in group BLUE

LogsWeb

Services Server

Directory Server

LucApplication X

Identities in group BLUE

ScottToufic

Phil

Policy for identities in group GREEN

Firewall

Oct 2004



Private Policy Use CasePrivate Policy Use Case

Provider-side Policy

Web Services Provider

Web Services Client

Requestor identity-filtered

policy view

and are assertions sharable to the identity

and are assertions private to the requestor

Oct 2004



Refresh/Fault Use CaseRefresh/Fault Use Case

Corporate Network

Web Services Client

Local policy cache

Web Services Server

DimitriProgram

X

Provider-side policy

Policy refresh

Policy replication

Oct 2004



Web Services

Business Services

Evolution To Web ServicesEvolution To Web Services

SOA

BusinessInteroperability

Web services reuse & governance

Dynamic Interoperability

Time

Standard-based enablement

Key Issue Key Solution Leverage investments

No Rip and Replace

Heterogeneous environments

Cross Platform

Proprietary Interfaces

Standards

Web Services Enablement Phase• Developer-driven web services, standards-based interoperability (SOAP, WSDL)• Substitute for Proprietary API’s• Reuse of discrete legacy applications (Java, C++, MOM etc.) and newly created applications

Oct 2004



Evolution To Business ServicesEvolution To Business Services

Web Services

Business Services

SOA




Time


Key Issue Key SolutionBusiness Alignment Business Taxonomy

Compliance Policy-driven

Business Reuse Standards-driven

Business Services Enablement Phase• Systematic approach to Web services on enterprise level• Adding visibility, compliance, governance, security and manageability.

Oct 2004



Evolution To SOA Dynamic InteroperabilityEvolution To SOA Dynamic Interoperability

Web Services

Business Services

SOA




Time


Key Issue Key SolutionBusiness Integration

BPM, Workflow

Dynamic Services Standard infrastructure

Service Management

Enablement & Registry

SOA Enablement PhaseAdding and integrating higher-level infrastructure services (BPM, transactions, workflow)

Oct 2004



SOA – Composable Infrastructure and Business ServicesSOA – Composable Infrastructure and Business Services

Cross-Selling

Outsource/Offshore

Compliance

PartnerIntegration

CorporateReuse

Business Services

BusinessServiceRegistry

MessageRouting

MessageTransformation

Transactions

BPM &Orchestration

Security

Management

Infrastructure Services

Publishing &Discovery of Services

Integration, Management &

Mediation BetweenServices

Visibility

Reuse

Adaptability

Management

ComplianceMicrosoft .net

J2EE - Portal

Composite Applications

Packaged Applications

EAI Legacy Applications

Customer

Orders

Products

CRM

.COM

SQL

Purchasing

MOM

Web Service Enablement

Web Services

Invoicing

Pricing

SCM

PLM

Sales

SQL

Oct 2004



Business Service Registry

Taxonomies

Specifications / Capabilities

Capabilities and Constraints DiscoveryCapabilities and Constraints Discovery

Service Type• Retail Accounts DB• CMS Document Publish• HR Employee Info• CRM Customer Info

Authentication• HTTP Digest• X.509• Kerberos• XML Sign

Transport• HTTP• JMS• IIOP• SMTP/POP

Service Interfaces• WSDL• XML Schema

Documents• Functional Specification•API reference•Examples

Department• Retail• Securities• Wholesale

Response Time• < 0.1 s• < 0.5 s• < 1 s• < 5 s

Location• New York• London• Singapore

Policies – Capabilities & Constraints

SLA• Availability• Performance

Technical• WS-I• Security

Regulatory• FDA• SarbOx

Corporate• SLA• Governance

Service Lifecycle

Governance

Policy Adaptability

Manageability

Reusability

Visibility

Business Drivers BenefitsEnablement DiscoveryPublishing Management

• Cost Center• IT

Oct 2004



Capabilities and Constraints Key to SOA GovernanceCapabilities and Constraints Key to SOA Governance

Deploy

Design

Implement

Manage

Policy

Corporate & Industry standards compliance

SOA Standards Compliance

Reliability

Configuration

Security

QoS & SLA

Access control

Dependencies, change management

Interoperability

Design Patterns & Methodologies

Best Practices

Corporate architecture compliance

Enablement Publishing ManagementDiscovery

SOA Architect defines corporate policies:• Reusability/Discoverability - identification and categorization• Compliance to industry and corporate standards – Sarbanes-Oxley, FpML, OFX etc.• Conformance to technical standards – WS-I, SOAP, WSDL, WS-S, WSRM etc.• Assurances – reliability, performance, scalability

WS Developer implements web services according to policies:• Compliance to industry and corporate standards –FpML, OFX etc.• Conformance to technical standards – WS-I BP

Administrator deploys and configures services according to policies:• Assurances – reliability, performance, scalability• Security – authentication, access control• Deployment policies

Operations Manager verifies and maintains compliance with corporate policies:• Reusability/Discoverability - identification and categorization• Compliance to industry and corporate standards – Sarbanes-Oxley, FpML, OFX etc.• Conformance to technical standards – WS-I, SOAP, WSDL, UDDI, WS-S, WSRM etc.• Assurances – reliability, performance, scalability

Oct 2004



Open Issues To Be DiscussedOpen Issues To Be Discussed Processing Model• Logical expression model

Evaluates to TRUE or FALSE No order or evaluation Simple to implement and convey

• Language model Implied order in evaluation More complex to convey but more flexible (e.g. conditionals and

branching)

Scope (Private/Public)• In the context of an organizational deployment, a policy document governs

more than the visible endpoint access aspects.• Some aspects of policy (e.g. internal routing, access control lists, auditing

rules) are necessarily private and should be labeled so.• These aspects however should be exchangeable and implementable on

different platforms

Attachment and Discovery• We already have a mechanism to attach and discover metadata• Handling of WSDL in UDDI should be example

Oct 2004



Open Issues To Be Discussed (cont.)Open Issues To Be Discussed (cont.) Distribution and Enforcement• Distribution of constraints and capabilities solely at the end points will not

scale for most enterprises; policy must be discoverable• Enterprise needs to support configurable frameworks based on published

policy; policy dispersal from the centrally managed registry• Publication and discovery of policy key to make constraints based

configuration and management work

Interoperability• Undeniable trend is the emergence of different categories that handle the

SOAP message (e.g. WS Security, Management).• Policy documents span categories and should be interoperable between all

vendors.

Negotiation• Most emphasis so far has been placed on constraints and capabilities of the service.

• The service consumer is just as important in our view.• Consumer should be able to discover and negotiate mutually acceptable terms

and conditions based on a common language (e.g. TLS server/client negotiation)

Oct 2004



Standards Convergence on Web services RegistryStandards Convergence on Web services Registry Web services specifications are now converging and adopting registry to satisfy publication and discovery needs OASIS UDDI Spec Technical Committee Active in mapping SOA facets

• WSDL – publication and discovery of WSDL artifacts

• BPEL – publication and discovery of BPEL4WS abstract processes

• WSRP – publication and discovery of WSRP Producer and Portlet services

• WSDM – publication and discovery of metrics and manageability provider information

• WS-Policy – mapping of WS-policy

W3C Constraints and Capabilities for Web Services

Documents

Transcript of W3C Constraints and Capabilities for Web Services