THE DISCUS THROW · THE DISCUS THROW Channeling Power Through The Discus by Brian Bedard
DISCUS
description
Transcript of DISCUS
DISCUSDecentralised Information
Spaces for Composition and Unification of Services
Alpa ShahGail Kaiser
Programming Systems LabColumbia University
November 5th, 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
C2 C3
C1
A1
A3
A2
B3
B2B1
GK-A
GK-B
GK-C
A2
B2
C1
TREATYOperations
1. Method1 ()2. Method2 ()Parameters
Accesspartial/complete
InfoExchange/
servicecomposition
10101010101010
Trust Management
Service Space - C
Service Space - B
Service Space - A
Policy Management
Ctxt,extnt ... ...... Complete ... ...... Defcon Mo-op Partial... ... ...
Service-SpaceMethods
Summit
Access = F(Context, Credentials)
Decentralized Information Spaces for Compositionand Unification of Services
Three key phases
1. Task Delegation Service Advertising and Discovery
2. Resource Acquisition Negotiation
3. 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 NetworkJXTA Network
Service Space
P2P GK
UDDI registry
Security Manager
• Service spaces use the JXTA network to find each other
• UDDI requests are sent through the JXTA network
Service Space
P2P GK
UDDI registry
Security Manager
Service Space
P2P GK
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 1Service Space 1
Service Space 2
GateKeeper
GateKeeper
Services
Services
SecurityManager
SecurityManager
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
<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>
<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>
Verifying an incoming treaty
Access = F(Policies,Credentials)
SecurityManager
1. Verify XML document2. Compare treaty with
permissions for the requesting Service Space
3. Set methods to authorized true/false
<ExecServiceMethodRequest> <TreatyID>234989592</TreatyID> <ServiceName>service</ServiceName> <MethodName>
getDataByFooAndBar </MethodName> <Parameter>foo</Parameter></ExecServiceMethodRequest><ds:Signature>…</ds:Signature>
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 document2. Get treaty from database3. Compare method request
with methods in treaty4. 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 A Service Space Brequest
response
JXTAJXTA?
<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 A
Service Space A Service Space B Access?<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>
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-upo Use existing summits
Top-downo 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