1 / 21

W3C Constraints and Capabilities for Web Services

W3C Constraints and Capabilities for Web Services. Toufic Boubez – Layer 7 Technologies Luc Clement – Systinet. Agenda. Introduce fundamental position and beliefs Discuss proposed use case Quick coverage of some additional use cases Moving up the stack:

xue
Download Presentation

W3C Constraints and Capabilities for Web Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. W3C Constraints and Capabilities for Web Services Toufic Boubez – Layer 7 Technologies Luc Clement – Systinet

  2. Agenda • 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 W3C Constraints and Capabilities for Web Services 2

  3. Web 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. W3C Constraints and Capabilities for Web Services 3

  4. The Promise and Reality of Web Services The 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) W3C Constraints and Capabilities for Web Services 4

  5. Fundamental 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. W3C Constraints and Capabilities for Web Services 5

  6. Concept of Policy Missing From WSDL A 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 W3C Constraints and Capabilities for Web Services 6

  7. Proposed 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) W3C Constraints and Capabilities for Web Services 7

  8. Proposed Use Case Discussion 1. “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. W3C Constraints and Capabilities for Web Services 8

  9. Example 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? W3C Constraints and Capabilities for Web Services 9

  10. Differentiated Access Use Case Firewall Logs Web Services Server Directory Server Web Services Clients Policy for identities in group BLUE Scott Toufic Corporate Network Phil Identities in group BLUE Policy for identities in group GREEN Luc Identities in group GREEN Application X W3C Constraints and Capabilities for Web Services 10

  11.  Private Policy Use Case Web Services Provider  and  are assertions sharable to the identity  and  are assertions private to the requestor  Requestor identity-filtered policy view  Provider-side Policy Web Services Client W3C Constraints and Capabilities for Web Services 11

  12. Refresh/Fault Use Case Web Services Server Provider-side policy Web Services Client Policy replication Corporate Network Policy refresh Dimitri Local policy cache Program X W3C Constraints and Capabilities for Web Services 12

  13. Evolution To Web Services SOA Dynamic Interoperability Business Services Business Interoperability Web services reuse & governance Web Services Standard-based enablement Time • 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 W3C Constraints and Capabilities for Web Services 13

  14. Evolution To Business Services SOA Dynamic Interoperability Business Services Business Interoperability Web services reuse & governance Web Services Standard-based enablement Time • Business Services Enablement Phase • Systematic approach to Web services on enterprise level • Adding visibility, compliance, governance, security and manageability. W3C Constraints and Capabilities for Web Services 14

  15. Evolution To SOA Dynamic Interoperability SOA Dynamic Interoperability Business Services Business Interoperability Web services reuse & governance Web Services Standard-based enablement Time SOA Enablement Phase Adding and integrating higher-level infrastructure services (BPM, transactions, workflow) W3C Constraints and Capabilities for Web Services 15

  16. Business Services Compliance Cross- Selling Partner Integration Outsource/ Offshore Corporate Reuse SOA – Composable Infrastructure and Business Services Web Service Enablement Infrastructure Services MOM Packaged Applications CRM BPM &Orchestration SCM Web Services PLM Transactions J2EE - Portal .COM Visibility Reuse Adaptability Management Compliance Business Service Registry Message Routing Sales Composite Applications Purchasing Message Transformation Invoicing Pricing Security Microsoft .net SQL Management SQL Customer EAI Legacy Applications Publishing & Discovery of Services Integration, Management & Mediation Between Services Orders Products W3C Constraints and Capabilities for Web Services 16

  17. Capabilities and Constraints Discovery Business Service Registry Enablement Publishing Discovery Management Business Drivers Benefits Taxonomies • Service Type • Retail Accounts DB • CMS Document Publish • HR Employee Info • CRM Customer Info • Department • Retail • Securities • Wholesale • Cost Center • IT Visibility Governance • Location • New York • London • Singapore • Response Time • < 0.1 s • < 0.5 s • < 1 s • < 5 s Reusability Service Lifecycle Policy Adaptability Policies – Capabilities & Constraints • Technical • WS-I • Security • SLA • Availability • Performance • Regulatory • FDA • SarbOx • Corporate • SLA • Governance Manageability Specifications / Capabilities • Transport • HTTP • JMS • IIOP • SMTP/POP • Authentication • HTTP Digest • X.509 • Kerberos • XML Sign • Service Interfaces • WSDL • XML Schema • Documents • Functional Specification • API reference • Examples W3C Constraints and Capabilities for Web Services 17

  18. Capabilities and Constraints Key to SOA Governance Enablement Publishing Discovery Management • Administrator deploys and configures services according to policies: • Assurances – reliability, performance, scalability • Security – authentication, access control • Deployment policies • WS Developer implements web services according to policies: • Compliance to industry and corporate standards –FpML, OFX etc. • Conformance to technical standards – WS-I BP SOA Standards Compliance Configuration Security Interoperability Best Practices Reliability Design Patterns & Methodologies Dependencies, change management Access control Corporate architecture compliance QoS & SLA Corporate & Industry standards compliance • 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 • 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 W3C Constraints and Capabilities for Web Services 18

  19. Open 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 W3C Constraints and Capabilities for Web Services 19

  20. 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) W3C Constraints and Capabilities for Web Services 20

  21. Standards 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 21

More Related