DISCUS

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

2. Agenda • Overview • Architectural description • Working of DISCUS • Open Issues • Conclusions

3. 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

4. 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

5. How everything fits together

6. Three key phases • Task Delegation • Service Advertising and Discovery • Resource Acquisition • Negotiation • Execution phase • Information/Service exchange

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

8. 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

9. Service Space UDDI registry Security Manager P2P GK Service Space Service Space P2P P2P GK GK UDDI registry UDDI registry Security Manager Security Manager Implementation overview • Service spaces use the JXTA network to find each other • UDDI requests are sent through the JXTA network JXTA Network

10. 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)

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

12. 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

13. Verifying an incoming treaty <Treaty> <TreatyID>0</TreatyID> <ServiceInfo> <ServiceName>service</ServiceName> <ServiceMethod> <MethodName>getData</MethodName> <Parameter>foo</Parameter> <Parameter>bar</Parameter> </ServiceMethod> </ServiceInfo> </Treaty> <ds:Signature> … </ds:Signature> Access = F(Policies,Credentials) • SecurityManager • Verify XML document • Compare treaty with permissions for the requesting Service Space • Set methods to authorized true/false <Treaty> <TreatyID>234989592</TreatyID> <ServiceInfo> <ServiceName>service</ServiceName> <ServiceMethod> <MethodName>getData</MethodName> <Parameter>foo</Parameter> <Parameter>bar</Parameter> <Authorized>true</Authorized> <MethodImplementation> getDataByFooAndBar </MethodImplementation> </ServiceMethod> </ServiceInfo> </Treaty>

14. Verifying resource use • Treaty enforces normative interaction between the ‘enlisted’ services. • Must adhere to the relevant treaty. <ExecServiceMethodRequest> <TreatyID>234989592</TreatyID> <ServiceName>service</ServiceName> <MethodName> getDataByFooAndBar </MethodName> <Parameter>foo</Parameter> </ExecServiceMethodRequest> <ds:Signature> … </ds:Signature> • SecurityManager • Verify XML document • Get treaty from database • Compare method request with methods in treaty • Return OK, or error message Error: 30 day free trial has expired! Error: Payment Overdue

15. 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

16. ? JXTA Service Space A <jxta:MSA > <MSID>urn:jxta:uuid-8574D06</MSID> <Name>discusUddi</Name> <jxta:PipeAdvertisement > <Id>urn:jxta:uuid-5961626204</Id> <Type>JxtaUnicast</Type> <ds:Signature> … </ds:Signature> </jxta:PipeAdvertisement> </jxta:MSA> DISCUS in action! • Service Space A sends a discoveryrequest to the JXTA network looking for a service. • Service Space A sends an incomplete Treaty as a request for service to Service Space B. request Service Space A Service Space B response • Service Space B checks security policies and accepts/rejects the request. Service Space A <jxta:MSA > <MSID>urn:jxta:uuid-8574D06</MSID> <Name>discusUddi</Name> <jxta:PipeAdvertisement > <Id>urn:jxta:uuid-5961626204</Id> <Type>JxtaUnicast</Type> <ds:Signature> … </ds:Signature> </jxta:PipeAdvertisement> </jxta:MSA> Service Space B Access? Security Policies

17. 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.

18. 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

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

20. 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

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

22. Programming Systems Lab