The NaradaBrokering SystemShrideep Pallickara and Geoffrey FoxCommunity Grid Computing LabsIndiana University

What to expect?As promised this seminar isAn attempt to spruce things up a bitAs it only seems fitLest I be accused of being remiss

Seems to me that its only rationalThat the Q&A session is bi-directionalSo desist from launching another browserAs you may be called upon to answer

Dispossessed, I am not, of clairvoyanceFor aware, I am, that repay you will in kindFor putting you in a bindAnd generally being an annoyance

But then again thats how seminars should beSo without any further delays . Shall we.

Talk outlineThe Story so farWhats currently cookingWhat needs more thoughtAnd a preview of things to comeClosing remarks

NaradaBrokeringBased on a network of cooperating broker nodesCluster based architecture allows system to scale to arbitrary sizeBased on the publish/subscribe modelAlso supports another model, peer-to-peer (P2P) via JXTAIncorporates algorithms forTopic matching and calculation of destinationsEfficient routing to computed destinationsSupports local broker accessesClients do not need to reconnect to the remote broker that it was last connected to.

Controlled Uncontrolled settings

Event in NaradaBrokering

NaradaBrokering ResultsExperimental Set-upTopology of 22 broker.Each broker node on 1 Sun SPARC Ultra-5 machine.100 client Node process, Sun SPARC Ultra-60JDK 1.2 run time environmentParameters being VariedMessage Size Publish Rates Matching Rates

NaradaBrokering Results

JMS ComplianceFeatures:JMS clients written while conforming to spec JMS clients are vendor agnosticJMS providers do not interoperate with each otherRationaleProviding support for JMS clients within the system.Mature specification with several existing applicationsOpens NaradaBrokering to these applicationsBring NaradaBrokering functionality to JMS systemsDistributed solution, load balancing, scaling and failure resiliency.

Providing JMS supportJMS InteractionsSupported locally or mapped to corresponding NaradaBrokering callsJMS Interconnection BridgeOperations supported locally or mapped to corresponding NaradaBrokering interactions One bridge instance per connectionMaintains list of registered sessionsResponsible for routing events to appropriate sessionsSupport for Creation of different message types e.g. ObjectMessage, BytesMessage etc.Operations that can be invoked on these message types.

Providing JMS SupportTopicNaradaBrokering topics are created as pairs.JMS Topics are generally / separated.JMS selector mechanismWe augment NaradaBrokerings topic matching with the selector mechanism implemented by openJMS.JMS subscriptionsMapped to corresponding NaradaBrokering subscription requests.The Narada JMS Event.Encapsulates the entire JMS message as a payload for the event.Matching is done based on the topic name contained in the message.

Towards a distributed JMS solutionFeatures in NaradaBrokering best exploited in distributed settings.Clients of distributed solution to inherit NaradaBrokering featuresRouting efficiencies, load balancing, scaling etc. Eliminate the Single point of failure modelHighly Available SystemExisting systems should easily be replaced with distributed system

Broker Locators: Distributed JMS SolutionPrimary FunctionDiscovery of brokers that clients can connect toObviates need for client to keep track of broker states within the broker network.Keeps track ofBroker additions and removalsChanges to network fabricPublished Limit on concurrent connections at a broker nodeSet during broker initializationsActive connections at a broker node.Individual brokers notify changes to broker locator.

Broker Locators: Features & ConstraintsFeaturesDynamic Real time Load BalancingConnection requests forked to best available broker. Incorporation of new brokers into solutionA newly added broker is among the best brokers to handle a connection request.Slower clients could all be hosted on specific brokersEliminates broker choking resulting from servicing very slow clients.ConstraintsAvailability (multiple per domain)Should not constitute a bottleneck or single point of failure.Minimal logicShould not affect processing pertaining to any node in the system.

Broker Locator: Decision MetricsIP-address of requesting clientPublished limit on concurrent connectionsNumber of active connections still possibleAvailability of brokerA simple ping testIf broker is not available, remove broker from list of available brokers.Computing capabilities at a brokerCPU speed, RAM etc.

Broker Locator: Sequence of OperationsLocate valid brokerPropagate broker information to clientHostname/IP-address informationPort number on which it listens for connectionsTransport protocol over which it communicatesClient then uses info to establish communication channel with brokerDone transparently. Clients with multiple connectionsA client could sometimes have connections to multiple brokers.

JMS Performance DataSonicMQ (version 3.0) and NaradaBrokering brokerDual CPU (Pentium 3, 1 GHz, 256 MB RAM) machine.100 subscribersOver 10 different JMSTopicConnectionsAll hosted on a Dual CPU (Pentium 3, 866 MHz, 256 MB RAM) machine.Publisher and Measuring SubscriberHosted on another dual CPU (Pentium 3, 866 MHz, 256 MB RAM) machine.Operating System and Run time EnvironmentLinux (version 2.2.16)Java 2 JRE (Java 1.3.1, Blackdown-FCS, mixed-mode)

Performance Data:Factors MeasuredTransit DelayNo need for clock synchronization and accounting for clock drifts. Standard Deviation in the transit delay for the sample of messages received.System ThroughputMeasured in terms of rate at which messages are received.Factors measured under varying publish rates message payload sizes.

Performance: Transit Delay & Standard DeviationLower Payloads & Low Publish Rates

Performance: Transit Delay & Standard DeviationHigher Payloads & Low Publish Rates

Performance: Transit Delay & Standard DeviationLower Payloads & High Publish Rates

Performance: System ThroughputLower Payloads & Higher Publish Rates

Why P2PDeployments user drivenNo dedicated managementManagement of resourcesExpose resources & specify security strategyReplicate resources based on demandDynamic peer groups, fluid membershipsSophisticated search mechanismsPeers respond based on their interpretationsResponses do not conform to traditional templates.

What are the downsides?Interactions are attenuatedLocalizedFragmented world of multiple P2P subsystemsRouting not very sophisticatedInefficient network utilization (Tragedy of Commons)Simple forwardingPeer Traces (to eliminate echoing)Attenuations (to suppress propagation)

JXTASet of protocols to support P2P interactions.Planned bridges to (and from) other P2P systems.

NaradaBrokering & JXTA Interaction ModelBased on proxy modelActs as both Rendezvous peer (JXTA routers) and NaradaBrokering client.No changes to JXTA core or straitjacketing of interactionsChange made to Rendezvous layerClients are not aware that they interact with a Narada-JXTA proxy or Rendezvous peer.

What we plan to accomplishBetter routing and network utilizationBridge isolated P2P subsystemsEfficiently locate/replicate shared resourcesSince interactions are routed through the broker network, brokers can build efficient resource maps.Incorporate GXOS support in NaradaBrokering Then use JXTA search to locate resources stored in the distributed XML database.Provide the notion of reliable interactions (for peers attached to Narada-JXTA proxies)Grid/WebServices generated dynamically when complex tasks are initiated could be managed by peer groups.

Narada-JXTA ProxyGlean relevant information from JXTA interactions.Peer group advertisementsRequests/Responses to be part of peer group.Messages sent to a peer group.Subscribe to relevant topics to ensure deliveryConstruct corresponding Narada-JXTA event from interactions.

ApplicationsIntegrated NaradaBrokering-JXTA environment tested under JXTA shell and myJxta (InstantP2P)Plan to integrate myJxta into Anabas with NaradaBrokering managing P2P and middle-tier (JMS) style interactions.JXTA-Jabber interface via Narada/Anabas.(Jabber, PDA, Anabas) linkage to be combined with (Jxta, NaradaBrokering, Anabas linkage).

A preview of things to comeAdaptive protocol supportSwitch transport protocols dynamicallyTCP, UDP, HTTP/SHTTP, Multicast, RTP & SOAP. Managing lightweight GXOS-based XML databases using NaradaBrokering/JXTA Search.JXTA/Jabber/PDA linkageSecurity infrastructureKerberos/PKIWeb Services .

Closing remarksIntersection of P2P, WebServices, middleware and distributed systemsLot of interesting research.Lot of issues to be tackled/addressedWhat you need to doStart using itReport bugs suggest useful additions