• Like

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
191
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
4
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Reality check: Old quote but still valid – makes even more of a point! Flexibility, whether through procedural programming, object programming, component programming, etc
  • Fast forward 5 years. Normal maturation cycle is part of the problem.
  • That’s why you buy software! Delegate to it!
  • Caveat: We’re not proposing a solution. There might be non-Policy mechanisms to solve these use cases, but it is important to have them in mind so that any solution we come up with does not preclude these use cases.
  • Need to have a protocol and faults MetaDataExchange could be it.
  • There are three stages to SOA implementation: Web Services Enablement phase is about implementing individual endpoints Developers enable existing applications by implementing web service interfaces on top of them. There is no organized approach to web services that are used rather opportunistically for communication and basic QoS interoperability.
  • In the Business Services Enablement phase companies start realizing that in order to fully leverage web services, they need to make sure that there is more to interoperability Customers start figuring out that they can easily get to the same (interoperable) islands of applications that they had before if they not start looking at services visibility, discoverability, manageability and compliance The SOA starts to touch all aspects of the organization: business analyst, architect/developer and operations The need for governance, compliance and manageability becomes a key focus There exists a need to express constraints and capabilities The use case as presented does not recognize the dynamic nature of SOA-based deployments nor does it enact what is required to govern an enterprise’s SOA. Though the use case identifies the need for expressing constraints and capabilities, along with the need to exchange this metadata, it does not go far enough and state the additional requirement to make this information discoverable. By making policy discoverable a consumer can select for example between otherwise identical Web services the instance that exhibits the constraints for which the consumer has the capability of supporting. Constraint and capability discovery is a key enabler to this phase .
  • In the SOA Enablement phase corporations fine-tune integration of all infrastructure services (end-to-end security, reliability, discovery etc.) and start exposing business services towards internal users and external partners or customers. In this phase corporation start leveraging dynamic interoperability to improve its overall agility. In other words corporation can quickly and efficiently assemble business applications that aligns with their ever-changing business needs.
  • Enterprises are building and deploying their SOA architecture based on the implementation of higher level business services composing them with infrastructure services; This composition is driving the need to express and make discoverable capabilities and constraints of the constituent pieces of the architecture It is thus imperative that policy be expressible and discoverable Distributing constraints and capabilities in the form of policy expressed exclusively at the end points is not scalable and manageable for an enterprise. While the end point typically represents the policy enforcement point motivating the need for the ability to support the means of exchanging this policy with consumers and the author of the policy, the policy must be discoverable for consumers. The inability to support discoverability of policy by consumers significantly reduces the value of the SOA proposition. Furthermore value for the enterprise in terms of governance would be greatly enhanced by supporting the means of effecting a global policy change that can be pushed to or pulled by end points; for this to be scalable a Web services registry is required to support the need of discovering Web services and their policies.
  • Today, governance is a key business driver for enterprises Governance is driving the need to leverage registry: Governing Reuse: Proper identification and categorization of Business Services Governing Compliance: Corporate standards, WS-I, Sarbanes-Oxley Governing Conformance: To local and domain specific requirements; To Security needs Governing Assurance: Service Level Agreements; Quality of Service Registry as a means of enabling discovery of capabilities and constraints is a key requirement of enterprises: Credentialing mechanisms; Security (non-repudiation; confidentiality); Preferred transport mechanisms; Reliability rules; Transactional rules; Privacy rules; Auditing and logging rules
  • Why is registry so important? A: Policy in terms of capabilities and constraints permeates the organization – which must be implemented and enforced across people, process and software For this to scale, a centralized view of policy is required Capabilities and Constraints are key facets of SOA governance

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
  • 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.
  • 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)
  • 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.
  • 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
  • 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)
  • 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.
  • 9. Example Policy Document <Policy> <AND> <OR> <Reliability>w3c:SomeProtocol</Reliability> <Reliability>w3c:SomeOtherProtocol</Reliability> </OR> <OR> <Encrypt> <XpathExpression xpathExpressionValue=&quot;included&quot;> <Expression stringValue=&quot;SomeXPathExpression&quot;/> </XpathExpression> <wsse:SecurityToken> <wsse:TokenType>wsse:X509v3</wsse:TokenType> </wsse:SecurityToken> </Encrypt> <Encrypt> <XpathExpression xpathExpressionValue=&quot;included&quot;> <Expression stringValue=&quot;SomeXPathExpression&quot;/> </XpathExpression> <wsse:SecurityToken> <wsse:TokenType>wsse:Username</wsse:TokenType> </wsse:SecurityToken> </Encrypt> </OR> <P3P policyref=&quot;SomeURL&quot;> </AND> </Policy> Signed?
  • 10. Differentiated Access Use Case Identities in group GREEN Corporate Network Web Services Clients Policy for identities in group BLUE Logs Web Services Server Directory Server Luc Application X Identities in group BLUE Scott Toufic Phil Policy for identities in group GREEN Firewall
  • 11. Private 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     
  • 12. Refresh/Fault Use Case Corporate Network Web Services Client Local policy cache Web Services Server Dimitri Program X Provider-side policy Policy refresh Policy replication
  • 13. Evolution To Web Services Web Services Business Services SOA Business Interoperability Web services reuse & governance Dynamic Interoperability Time Standard-based enablement
    • 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
    • Cross Platform
    • Heterogeneous environments
    • Standards
    • Proprietary Interfaces
    • No Rip and Replace
    • Leverage investments
    Key Solution Key Issue
  • 14. Evolution To Business Services Web Services Business Services SOA Business Interoperability Web services reuse & governance Dynamic Interoperability Time Standard-based enablement
    • Business Services Enablement Phase
    • Systematic approach to Web services on enterprise level
    • Adding visibility, compliance, governance, security and manageability.
    • Policy-driven
    • Compliance
    • Standards-driven
    • Business Reuse
    • Business Taxonomy
    • Business Alignment
    Key Solution Key Issue
  • 15. Evolution To SOA Dynamic Interoperability Web Services Business Services SOA Business Interoperability Web services reuse & governance Dynamic Interoperability Time Standard-based enablement SOA Enablement Phase Adding and integrating higher-level infrastructure services (BPM, transactions, workflow)
    • Standard infrastructure
    • Dynamic Services
    • Enablement & Registry
    • Service Management
    • BPM, Workflow
    • Business Integration
    Key Solution Key Issue
  • 16. SOA – Composable Infrastructure and Business Services Business Service Registry Message Routing Message Transformation Transactions BPM & Orchestration Security Management Infrastructure Services Publishing & Discovery of Services Integration, Management & Mediation Between Services Visibility Reuse Adaptability Management Compliance Microsoft .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 Cross- Selling Outsource/ Offshore Compliance Partner Integration Corporate Reuse Business Services
  • 17. Capabilities and Constraints Discovery Business Service Registry Taxonomies Specifications / Capabilities
    • 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 Benefits Enablement Discovery Publishing Management
    • Cost Center
    • IT
  • 18. Capabilities and Constraints Key to SOA Governance 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 Management Discovery
    • 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
    Deploy Design Implement Manage Policy
  • 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
  • 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)
  • 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