A lightweight, faulttolerant,secure, loadbalanced Messaging service enabling scientific Collaborator

1
A lightweight, fault-tolerant,secure,
load-balanced Messaging service enabling
scientific Collaboratories

• February 2002
• TASSL
• Vincent Matossian

2
What ?

• The Goal
• Optimize COMMUNICATION among
• Users Applications Data distributed entities
• The means
• Networked heterogeneous computers
• Protocols
• Software and ideas

3
Overview

• Introduction to DISCOVER
• solutions provided and problems raised
• redefining the problem
• A Message Service approach
• Proposed Solution
• Towards the goal

4
Introduction to DISCOVER

• DISCOVER middleware-based scientific
  collaboratory
• Initial problem statement
• A Collaboratory enabling interactions between
  web-based clients and back-end high-performance
  scientific applications

5
Problem Solved ?

• DISCOVERs initial goals were reached!!
• Application exports interfaces to middleware
• Clients can monitor and steer this application
  over the web
• Clients collaborate through shared views, chat
  and whiteboard tools
• Application responses are logged_at_middleware
• Distributed Discover servers communicating
  through CORBA, enables clients to log on to
  closest server therefore optimize efficiency
• but issues were raised

6
Issues raised _at_ Client

• Need for group formation among users_at_applications
• Improve management of sharing of information
  among groups (one-to-one, one-to-many)
• To better understand the needs of collaborating
  scientists
• Viewers, Manipulation tools
• Enable offline portal for users providing working
  environment and access to logged information
• Provide a more advanced management interface to
  back-end resources through the use of detachable
  UI components

7
Issues raised _at_ Middleware

• The Middleware
• WWW server Servlet Engine DataBase Message
  Queues Management Collaboration Handler
• All messages btw Clients and Applications have to
  transit through
• Scalability issues
• Points not addressed by current deployed
  middleware
• message filtering and aggregation
• group management
• Efficient message distribution model
• Fault Tolerance and Replication
• Security

8
Issues raised _at_ Application

• Talks only to DISCOVER Server
• No Rule-based triggers on each object
• Soft-I/O Application to Data communication
• Current metadata is homebrewed, what should be
  its format ? XML ?
• No code mobility

9
Redefinition of the problem

• A lightweight, fault tolerant,secure,
  message-based, application-level overlay network,
  enabling distributed resources monitoring and
  steering.

10
Messaging Overview

• Raw Network
• Remote Procedure Calls - RMI
• Electronic Mail
• Message-Oriented-Middleware

11
Messaging models

• 2 common models
• Point-to-Point
• Direct connection between two endpoints
• Each point understands the protocols and can
  handle the communication and processing
• Publisher-Subscriber
• Each node is connected through a message broker
• Producers publish information to which consumers
  register interest for.

12
Current /- Messaging in DISCOVER

• MOM Req/Resp model
• Clients poll server
• Server polls applications
• State is maintained at middleware
• End-to-end argument better off providing
  services closer to the application rather than at
  a low level (e.g kernel or network level)
• No semantic information embedded in message
• No message delivery semantics
• No transactional model

13
Example Message in DISCOVER A client requests a
View

• HTTP POST from Client ? Server (CommandHandler.cla
  ss)
• AppID,theAppid
• ClientID,theClID
• type,ViewRequest
• Command,someCmd
• ObjectID,someOid
• ViewName,someVn
• mode,(no)Collab

• Query is Passed from Server (CommandConnection.cl
  ass) ? Application (Gateway.cpp)
• OBJECT_QUERY_MESSAGE
• OBJECT_ID 2-D Transport Application NODE 0 OBJ
  0 OBJECT_ID_END
• OBJECT_INTERFACE_NAME AppDetails
  OBJECT_INTERFACE_NAME_END
• OBJECT_QUERY_MESSAGE_END

• Response from Application ? Server ? Clients
• OBJECT_RESPONSE_MSG
• OBJECT_ID 2-D Transport Application OBJECT_ID_END
  
• OBJECT_INTERFACE_NAME AppDetails
  OBJECT_INTERFACE_NAME_END
• OBJECT_INTERFACE_RETURN_TYPE TEXTDISPLAY
• OBJECT_INTERFACE_RETURNTYPE_END
• OBJECT_RESPONSE OBJECT_RESPONSE_END
• OBJECT_RESPONSE_MSG_END

14
What happened ?

• The user clicked on a GUI component part of a
  tree of objects which HTTP POSTed a request on to
  a servlet

• The server added this command to a queue of
  commands to be passed to the application when
  ready to take commands

• When the response to this command is received
  from the application it is multicast to all the
  interested clients through a lookup in a table of
  client entries having either subscribed interest
  to this view or are in a Collaboration mode

15
What can it Do!

• Authenticate users
• Acquire a lock for application steering
• Set or Get values on Remote Objects
• Request persistent views
• Chat with other users
• Online access to application response log

16
What can it NOT do ?

• A server crash is fatal for the system? No state
  Recovery, No Rerouting mechanism
• No Discovery Service
• Cant query object repository for all objects
  matching certain attributes
• Cant combine information from several
  applications
• Cant have a flexible access to Objects
  information (command-line query for instance)
• Not a virtual desktop approach
• Cant point to storage servers
• No offline work is possible

17
Whys ?

• Why cant we authenticate once, have a session
  key and use this in the messaging
• Why cant a request be More Important than
  another
• Why cant we dynamically, semantically select
  objects with specific attributes and perform
  operations on them
• Why cant the system dynamically handle an
  application lock, allowing users to submit a
  script to execute when granted the lock ?
  avoiding wait or abrupt lock release
• Why is there no transactional model in place

18
Messaging Service Requirements

• The use of Messages should permit
• Failure recovery
• State recovery
• Delivery Semantics
• Logging
• Semantic querying
• Resource Discovery
• Dynamic lock management
• Collaboration
• Security

19
Proposed Solution

• An application-level overlay-network composed of
  Discover Points responsible of routing messages
  across the system
• Endpoints join the overlay network and can
  semantically access information in transit based
  on interest
• DPs are synchronized across the system
• Management Servers store specific information
  relevant to the connecting endpoint

20
Components Discover Points

• Discover Points
• Each DP contains a Directory that is a current
  image of the active entities in the system
• It has routing capability on the overlay network
  based on several algorithms that can be selected
  per message type
• Authenticates users against authentication
  servers
• Stores message headers

21
Components Management Servers

• Client MS
• Information storage
• Maintains user preferences
• Application MS
• Stores Responses
• History
• Data interactions

22
Scenario client requests a view to application

• Join
• A client requests to join the overlay-network,
  he/she is assigned (through a DP Resolution
  server) an optimal (load / geography) discover
  point agent against which authentication is
  performed
• Discovery
• Applications, Data centers and resources are
  independently discovered by the DP through a
  gossip-like architecture and are presented to the
  user based on his preferences (maintained at a
  Client Management Server)
• Registration
• After user registers interest for an Application
  the Application Object List is made available to
  the CMS for RMI
• The application maintains requests in its
  Application Management Server for message
  processing

23
Scenario continued

• Query Message
• The view request message is sent to the
  application through the DP and Overlay network,
  access-control is performed at registration time
  and the DP is responsible for blocking
  unauthorized requests and maintaining an up to
  date per App Lock (token) state (Natural
  Aggregation)
• Each message should contain at least
• SourceID Source Identifier
• DestID Destination Identifier
• DisPointID Discover Point Identifier
• ManagerID The server storing User Profile (Logs
  and Storage)
• Semantic Call Method to invoke on Object(s)
• Routing
• Routing of the message through the overlay
  network can be done using different algorithms
  depending on requirements and type of the message
• On receiving the request the application
  processes it and broadcasts a short message
  indicating that the response is ready

24
Scenario continued

• Message Distribution
• Can be ABCAST, CBCAST, Best-Effort, Guaranteed
• Application Management Server could be
  responsible of storing interested clients
  addresses
• A response message header floods overlay-network,
  an interested client will read the message and
  acquire the id of the location of the response
• Fault Tolerance
• If a DP crashes, state is recovered by initiating
  a new connection to an active DP which will
  reinitialize connections to Client/App Manager
  Servers
• Client/App Manager Servers need to be replicated
  in order to maintain the system fault-tolerant

25
Conclusion

• Defined the issues that need to be addressed
• Need to settle on technologies
• JxTASOAP seems to be promising
• The main focus of my work will be
• Enabling delivery semantics of messages
• publication and subscription mechanisms
• Basic Fault-tolerance issues
• I will not address
• Security
• Collaboration

26
GAME OVER
.FOR NOW
27
Issues in DS
appendix

• Naming
• Directory and Discovery
• Coordination and Agreement
• Mutual Exclusion (coordinates access to shared
  resources)
• Elections (whos in charge)
• Multicast (order of messages arriving)
• Consensus (agreement)
• Transactions
• Locks
• Concurrency control
• Fault-Tolerance
• Replication
• Load-Balancing