DISCUS Decentralised Information Spaces for Composition and Unification of Services Alpa Shah Gail Kaiser Programming Systems Lab Columbia University November 5 th, 2002

Agenda  Overview  Architectural description  Working of DISCUS  Open Issues  Conclusions

Overview  Temporary alliances among existing Web Services  Assists pooling of resources  Rapidly deal with temporary or ongoing problems  Builds on Web/Internet Standards  Selective access & controlled interactions

Key Concepts  Service Spaces Logical collection of services under one administrative control Existing legacy systems, span organisational boundaries  Summits Composition of services with a mission  Treaties Contract of exchange of service  GateKeepers (GK) The Bouncer !  Security Manager

How everything fits together

Three key phases  Task Delegation Service Advertising and Discovery  Resource Acquisition Negotiation  Execution phase Information/Service exchange

Phase I – Task Delegation  Service Advertising  WSDL (Web Services Definition Language) XML description of web services Procedure-oriented information  Method, parameters  DAML-S : (Darpa Agent Markup Language) yet another XML description Why DAML ?  Content level description – not keyword  Machine readable descriptions of the services  View service as a process/task

Task Delegation – cont’d  Dynamic service discovery  UDDI (Universal Description, Discovery and Integration) Query Web Services Centralised, not good We extend with peer to peer infrastructure  Sun’s JXTA project Security awareness

Implementation overview JXTA Network Service Space P2PGK UDDI registry Security Manager Service spaces use the JXTA network to find each other UDDI requests are sent through the JXTA network Service Space P2PGK UDDI registry Security Manager Service Space P2PGK UDDI registry Security Manager

Phase II – Resource acquisition  Negotiation between Service Spaces  Policy-based information transport layer  Policies and constraints inherited from enclosing Service Space  Signed requests and responses XML Signatures  Security matrices & policies Credentials, context or mode of operation  WS-Security (Future Work)

Service Spaces communicate only through the GateKeepers The GateKeeper uses the Security Manager to create and verify treaties Service Space 1 Service Space 2 GateKeeper Services Security Manager Security Manager GateKeeper, the ‘Traffic Cop’

Treaties  Pre-existing templates  Instantiation of Treaties Without involving any global authority Formed: request Completed: request approval  Treaty Relations Unique Pair-wise Often asymmetric but never transitive  Content level security Semantics-based approval TTL, allowed number of invocations, payment, type, restricted parameter ranges

0 service getData foo bar … service getData foo bar true getDataByFooAndBar Verifying an incoming treaty Access = F(Policies,Credentials) SecurityManager 1.Verify XML document 2.Compare treaty with permissions for the requesting Service Space 3.Set methods to authorized true/false

service getDataByFooAndBar foo … Error: 30 day free trial has expired! Error: Payment Overdue Verifying resource use Treaty enforces normative interaction between the ‘enlisted’ services. Must adhere to the relevant treaty. SecurityManager 1. Verify XML document 2. Get treaty from database 3. Compare method request with methods in treaty 4. Return OK, or error message

Phase III – Execution Phase  Gatekeeper acts as a proxy Any data, resources, service exchanges must be conformant to the treaties  Summits dissolve once the mission is accomplished Could last arbitrarily long, not necessary short lived Logs maintained for post mortem analysis  Workflow Coordinates interaction among Web Services Subset of XLANG ( WSFL like) workflow language with a home brewed parser  Execution monitoring Portal based on JMX framework

DISCUS in action! 1.Service Space A sends a discovery request to the JXTA network looking for a service. 2.Service Space A sends an incomplete Treaty as a request for service to Service Space B. 3.Service Space B checks security policies and accepts/rejects the request. Service Space AService Space B request response JXTA ? urn:jxta:uuid-8574D06 discusUddi urn:jxta:uuid JxtaUnicast … Service Space A Service Space B Access? urn:jxta:uuid-8574D06 discusUddi urn:jxta:uuid JxtaUnicast … Security Policies

Current proof-of-concept  Example demo application Scenario: task of collecting information regarding a particular location Basis of intelligence analyses  Recruitment and integration of Web Services Rapid Secure Simple  Using third-party services available through xmethods.com  Authenticated information exchange with unsecured Web Services (GK)  Implementation-level independence.

Technology  Web Services Choice of platforms Interoperate with multiple backend component models (CORBA, EJB)  Runtime proxy generation  Runtime source code generation from WSDL Immediate compilation  Components developed using C#, Java Need a language with support for reflection  C# A fairly sophisticated library Especially the runtime compilation GateKeeper

Progress work: Object-orientation Summit { ServiceSpace; Treaties; Workflow; } MLSecurity_Summit { MLSManager; MLSPolicies; } ABC_Summit {... } Intl_MLS_Summit {... } An inheritance hierarchy of Summits Aggregation: Summit of Summits  Super list of policies More restrictive than original  Dynamic trust and membership model  Composition methods Bottom-up o Use existing summits Top-down o Create sub-summits to fit requirements

Open Issues  Capabilities-based customizable WSDL The interface is provided based on:  Credentials  Payment plans  Concept of transactions Roll-back in case of failures in a summit  Security Considerations Services with lower credentials participating in the summits affect service extent  Semantics, invocation protocols  XML inheritance Interface inheritance, e.g. WSDL inheritance  Other negotiation models: Economic Models

Execution Phase: Issues/Future Work  Summit level monitoring Web Services exception-handling  Improve our XLANG coverage Or migrate to another workflow notation  Enable “semantic workflows” With dynamic parameterization and substitution  Robust behavior Fault tolerance Survivability Dynamic reconfigurability of in-place Summits  Contextualisation of service operations

Programming Systems Lab