slides

314 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
314
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

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
  • slides

    1. 1. October 2004 ©2004 Layer 7 Technologies Inc. ©2004 Systinet Corporation W3C Constraints andW3C Constraints and Capabilities for Web ServicesCapabilities for Web Services Toufic Boubez – Layer 7 Technologies Luc Clement – Systinet
    2. 2. Oct 2004 ©2004 Layer 7 Technologies Inc. ©2004 Systinet Corporation 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
    3. 3. Oct 2004 ©2004 Layer 7 Technologies Inc. ©2004 Systinet Corporation 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.
    4. 4. Oct 2004 ©2004 Layer 7 Technologies Inc. ©2004 Systinet Corporation The Promise and Reality of Web ServicesThe 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. 5. Oct 2004 ©2004 Layer 7 Technologies Inc. ©2004 Systinet Corporation 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.
    6. 6. Oct 2004 ©2004 Layer 7 Technologies Inc. ©2004 Systinet Corporation Concept of Policy Missing From WSDLConcept 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. 7. Oct 2004 ©2004 Layer 7 Technologies Inc. ©2004 Systinet Corporation 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)
    8. 8. Oct 2004 ©2004 Layer 7 Technologies Inc. ©2004 Systinet Corporation Proposed Use Case DiscussionProposed 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. 9. Oct 2004 ©2004 Layer 7 Technologies Inc. ©2004 Systinet Corporation 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?
    10. 10. Oct 2004 ©2004 Layer 7 Technologies Inc. ©2004 Systinet Corporation Differentiated Access Use CaseDifferentiated 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. 11. Oct 2004 ©2004 Layer 7 Technologies Inc. ©2004 Systinet Corporation 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
    12. 12. Oct 2004 ©2004 Layer 7 Technologies Inc. ©2004 Systinet Corporation Refresh/Fault Use CaseRefresh/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. 13. Oct 2004 ©2004 Layer 7 Technologies Inc. ©2004 Systinet Corporation Web ServicesWeb Services Business ServicesBusiness Services Evolution To Web ServicesEvolution To Web Services SOASOA Business Interoperability 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
    14. 14. Oct 2004 ©2004 Layer 7 Technologies Inc. ©2004 Systinet Corporation Evolution To Business ServicesEvolution To Business Services Web ServicesWeb Services Business ServicesBusiness Services SOASOA Business Interoperability Web services reuse & governance Dynamic Interoperability Time Standard-based enablement Key Issue Key Solution Business 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.
    15. 15. Oct 2004 ©2004 Layer 7 Technologies Inc. ©2004 Systinet Corporation Evolution To SOA Dynamic InteroperabilityEvolution To SOA Dynamic Interoperability Web ServicesWeb Services Business ServicesBusiness Services SOASOA Business Interoperability Web services reuse & governance Dynamic Interoperability Time Standard-based enablement Key Issue Key Solution Business Integration BPM, Workflow Dynamic Services Standard infrastructure Service Management Enablement & Registry SOA Enablement Phase Adding and integrating higher-level infrastructure services (BPM, transactions, workflow)
    16. 16. Oct 2004 ©2004 Layer 7 Technologies Inc. ©2004 Systinet Corporation SOA – Composable Infrastructure and Business ServicesSOA – Composable Infrastructure and Business Services Cross- Selling Cross- Selling Outsource/ Offshore Outsource/ Offshore ComplianceCompliance Partner Integration Partner Integration Corporate Reuse Corporate Reuse Business Services Business Service Registry Business Service Registry Message Routing Message Routing Message Transformation Message Transformation TransactionsTransactions BPM & Orchestration BPM & Orchestration SecuritySecurity ManagementManagement 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
    17. 17. Oct 2004 ©2004 Layer 7 Technologies Inc. ©2004 Systinet Corporation 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 Benefits Enablement DiscoveryPublishing Management • Cost Center • IT
    18. 18. Oct 2004 ©2004 Layer 7 Technologies Inc. ©2004 Systinet Corporation 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
    19. 19. Oct 2004 ©2004 Layer 7 Technologies Inc. ©2004 Systinet Corporation 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
    20. 20. Oct 2004 ©2004 Layer 7 Technologies Inc. ©2004 Systinet Corporation 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)
    21. 21. Oct 2004 ©2004 Layer 7 Technologies Inc. ©2004 Systinet Corporation 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

    ×