IBM e Business On Demand Web Services Capabilities

IBM Software Group Overview of Presentation § Web Services Today § Policy and Metadata

IBM Software Group Web Services Today § WSDL and XML Schema together provide metadata describing what a service does by defining the business interface of the service endpoint. e. g. open. Account, process. Deposit § How the service implements the interface is equally important: what the service expects from and provides to requestors; and also, what is expected or provided by a hosting environment. § What is the subject of this information? Not just the service endpoint! The artifacts and “resources” the endpoint uses (documents, document types, data tokens, etc. ) are equally important. They also carry access characteristics and constraints. § What we need? A general purpose framework for expressing the constraints and conditions of Web service access to service endpoints and resources. WSDL is not enough since it focuses exclusively on the endpoint. § What are the basic requirements? Support for the explicit identification of available options as well as the target subjects, for a given a set of access constraints and behavioral capabilities. © 2004 IBM Corporation

IBM Software Group Web Services Policy in the Web Services Protocol Stack § What’s next for Web services? – Customers increasingly provide requirements for us to improve the fidelity and quality of Web service interactions. § New (relatively) specifications have been proposed and are in varying stages of standardization, e. g. : – Web Services Security (OASIS recommendation) – Web Services Reliable Messaging, – Web Services Addressing, – Web Services Transactions, – Web Services Coordination, and the Business Process Execution Language for Web Services (BPEL 4 WS). (OASIS) © 2004 IBM Corporation

IBM Software Group Web Services Policy in the Web Services Protocol Stack § These specifications introduce three kinds of artifacts: – Architected function enablement (infrastructure) – specific headers that augment messages with function specific information, e. g. transaction context, message sequence numbers. – Distinguished Web services – E. g. Coordinator, Trust Authority. – Endpoint protocols for implementing the enablement functions, – e. g. message retransmission, transaction protocol sets. § In a service oriented environment, the availability and support for new functions and protocols must be explicitly stated through a standardized service metadata language: – Critical to maintain loose coupling and ensure interoperability. © 2004 IBM Corporation

IBM Software Group What we need for Web Services Policy § A common framework for the expression, exchange and processing of the conditions governing the interactions between Web service endpoints. – concentrate on those conditions that provide quality of assurance (security, reliability, transactionality, privacy, etc. ). § The declarative description of the domain specific conditions and constraints. That will allow: – automated implementation by middleware and operating systems. – better user experience. – better reuse of application code by the organizations that deploy and support Web Service instances. § An extensible mechanism for associating policies with subjects. – Endpoints and more. © 2004 IBM Corporation

IBM Software Group Why declarative policies? § Each application could implement logic for every relevant condition/constraint. – This will be difficult to scale; will hinder interoperability. § Alternatively, we can factor the conditions/constraints out of business logic and express them as declarations of common capabilities: – Support for the declared function is provided by the supporting infrastructure. – Allows for the incremental evolution of the sophistication of a Web service description. – On the management side, allows businesses to modify the service assurance of a service offering without the need to rewrite the service. – The composability of Web Services can also be leveraged, allowing services to augment a business offering with additional qualities available in a deployment environment. © 2004 IBM Corporation

IBM Software Group We need to avoid boiling the policy ocean Proposal § Explore a separation of concerns with regard to classification of the varied set of information often referred to as “policy” – Define Constraints to be requirements of the endpoint or resource (e. g. username token required). – Define Capabilities to be characteristics or properties of the service presented as offerings (e. g. I can support the XYZ protocol). § Start with a simple, common framework and allow for extension § Define Web service policies to be declarative expressions of conditions and constraints for the interaction with a particular Web service or resource. – Identify processing practices for Web service endpoints (requestor and provider) to communicate any requirements or agreements that affect either endpoint or associated resources. – This includes policies that a Web service implementation declares to express requirements on a hosting environment (“the container”). © 2004 IBM Corporation

IBM Software Group What we get with WS-Policy § Common syntax for expressions. XML vocabularies to be defined by domain experts (security, reliable messaging, etc. ). § Basic framework for expressing “policy alternatives” and an associated processing model. Provides composition of independently authored policy assertions into compound document that define valid combinations of choices. Offers a simple, algorithmic approach for selecting the right policy setting between multiple options. § Flexible, extensible attachment mechanism suitable to address a variety of policy subjects. – Allows for incremental annotation. – Domain expressions defined for common web services architectural elements. – WSDL, UDDI, Endpoint References. © 2004 IBM Corporation

IBM Software Group W 3 C example § A Web service wishes to stipulate that clients are required support a reliable messaging protocol, and encrypt a specific header with WSSecurity using a X. 509 or user name security token in order to send an acceptable request message. Furthermore, the service has a P 3 P policy associated with its operations. Such constraints and capabilities might be associated with the Web service via a SOAP header or a WSDL file. © 2004 IBM Corporation

IBM Software Group W 3 C Example <wsp: Policy xml: base=http: //www. fabrikam 123. com/policies wsu: Id="SEC"> <wsp: Exactly. One> <wsse: Security. Token> <wsse: Token. Type>wsse: Username. Token</wsse: > </wsse: Security. Token> <wsse: Token. Type>wsse: X 509 v 3</wsse: Token. Type> </wsse: Security. Token> </wsp: Exactly. One> <wsse: Confidentiatlity> <Key. Info> <wsse: Reference URI="#ENCKEY" /> </Key. Info> <wsse: Alg. Encryption URI=”http: //www. w 3. org/2001/04/xmlenc#3 des-cbc/> <Message. Parts Dialect="http: //schemas. xmlsoap. org/2002/12/wsse#part > <wsp: Header() > </Message. Parts> <wsse: Confidentiality> </wsp: Policy> © 2004 IBM Corporation

IBM Software Group To make Web services policy a reality … § Domain specific languages must be developed to represent new functions and protocols: – WS-Security. Policy. – WS-Reliable. Messaging. – WS-Transactions. § Attachment expressions must be defined to address the variety of subjects involved in a Web service exchange. – XPath expressions. – New domain expressions. § Guidelines for use with discovery mechanisms. – Goal is to support service development process as well as to enable middleware for automatic configuration. © 2004 IBM Corporation

IBM Software Group Develop Policy Ecosystems – Domain languages security internationalization Service agreements ©

IBM Software Group Policy Ecosystems § There will be multiple service assurance protocols – It is important to indicate which one a WS supports – Common syntax is used to express protocol requirements – including the types of protocols that it supports – requirements it places on potential requesters. § There will be requirements on a hosting environment – Implementation of the protocols and functions occurs in middleware and OS – Need to surface characteristics that constrain the runtime – common syntax to describe the constraints/conditions allows for incremental annotation § There will be a need to scope accountability – who is responsible for the behavior © 2004 IBM Corporation

IBM Software Group Web Service Interactions Configured Through Policy A set of constraints/capabilities behaviors may be enabled or disabled configured at each endpoint, and for every relevant resource. E 0 E 1 To completely configure the interaction, within the scope of a particular policy set, we state what constraints or capabilities are enabled at each endpoint © 2004 IBM Corporation

IBM Software Group Policy and Discovery: UDDI § Registry based discovery: UDDI –V 2 presents 2 Alternative styles: – Embed policy expressions in UDDI entities. – Register policy expressions as t. Models (roughly equivalent to a feature) the referencing and categorizing these t. Models – Use category bags to associate policies with UDDI elements – With UDDI it is possible to associate policies with the service provider itself (irrespective of the actual services it provides) – UDDI lends itself more to the publication of business oriented policies, rather than technical interoperability specifics. UDDI V 3 has query mechanisms that have not yet been exploited. © 2004 IBM Corporation

IBM Software Group Policy and Discovery: Metadata Exchange § § Scenario: Requester dynamically finds/receives service endpoint, request fresh set of policies from service endpoint itself. Providers return set of policies to apply to interaction (to this requester, in this particular context). § Allows providers to customize their policies to individual requesters and interactions. § http: //www 128. ibm. com/developerworks/library /specification/ws-mex/ 1 2 © 2004 IBM Corporation

IBM Software Group Other areas where web services policies will be important § Agreements Another aspect of a web service is its willingness to negotiate about capabilities. Expressing this could be an additional policy language (e. g WS-Agreements. ) Agreements can leverage policy metadata but to refer to items that may be “negotiated” an attribute could indicate this (Could be either domain level or framework level) § WS-I Interoperability Customers need specs to be profiled we have some early attempts at representing profiles as a policy expression © 2004 IBM Corporation

IBM Software Group Using policy to define conformance <wsp: All>  <bp: Description req="0001"/> <bp: Port 80 req="1110" wsp: Optional /> <bp: Temp. Redir req="1130" /> <bp: Cookies req="1120" /> <bp: Require. Cookies req="1121" /> <bp: Conform. RFC 2965 req="1122" /> <bp: Entity. Body. Empty req="2714" /> <bp: Wait. For 2 xx req="2715" /> <bp: Return. Fault. On. Bad. Message req="2724" /> <bp: Check. Faults. On. Bad. Message req="2725" /> <wsp: Exactly. One > <wsp: All>  </wsp: All>  <bp: Append. Response req="2729" /> <bp: Accessors. Unqualified req="2735" /> <bp: Accessor. Children. Qualified req="2737" /> </wsp: All> </wsp: Exactly. One> </wsp: All> © 2004 IBM Corporation

IBM Software Group Semantic Web § The DNA of policy - but you don’t always want to get there! Don’t need DNA analysis to determine it’s a common cold Do we need the human genome to diagnose a headache? § Something for a later stage Further characterizes the “what” § As business process semantics extend WSDL/BPEL, semantics for policy make help us reason about complex expressions We need more experience before we know how to do this © 2004 IBM Corporation

IBM Software Group Summary: What’s Next? § The timing of new initiatives is always challenging. Policy is now ready for the standardization process. § New protocols are already available, bringing up the need to represent more capabilities and requirements in service interactions. WS-Policy provides today a general purpose, extensible framework, which is by design compatible with WSDL and other existing Web services specifications. § IBM’s strategic vision: A standard must be built around WS-Policy to provide the single format for the expression of Web service and resource capabilities and requirements. Policy is more generic than WSDL: Our minority opinion on F&P should stand. © 2004 IBM Corporation

IBM Software Group Summary: Other Related Efforts. § The Web services policy space is adjacent to a vast field of related disciplines: “Rules, ” “management policies, ” “semantic descriptions, ” “ontology's, ” etc. Some of these belong to the implementation domain (rules, strategy pattern). Others (full semantic descriptions) will require a much larger effort and will take the industry years or trial and error before adoption takes place. § IBM strongly believes that the next logical, achievable and most pressing problem is to support general purpose policy framework focusing on Web services interoperability. Complementing SOAP, WSDL, UDDI and other base XML and Web services standards. Providing increased ability to capture the evolving set of standards for service assurance (transactions, security, etc. ). © 2004 IBM Corporation