15th International Command and Control Research and ......specifically for tactical Command and Control (C2) systems, are easily recognized in terms of soldier productivity, property - [PDF Document] (2024)

• Home
• Documents
• 15th International Command and Control Research and ......specifically for tactical Command and Control (C2) systems, are easily recognized in terms of soldier productivity, property

Upload: others

Post on 13-Feb-2021

2 views

Category:

Documents

0 download

Report

• Download

• 15th International Command and Control Research and TechnologySymposium (ICCRTS 2010)

  ICCRTS Theme: The Evolution of Command and Control Track:Information Sharing and Collaboration Processes and Behaviors(Track #3) Title of Paper: Enabling Tactical Edge Mashups with LiveObjects Authors: Daniel Freedman (Cornell University, Department ofComputer Science) Ken Birman (Cornell University, Department ofComputer Science) Krzysztof Ostrowski (Cornell University,Department of Computer Science) Mark Linderman (Air Force ResearchLaboratory, Information Directorate) Robert Hillman (Air ForceResearch Laboratory, Information Directorate) Albert Frantz (AirForce Research Laboratory, Information Directorate) Point ofContact: Daniel Freedman Office Address: Cornell UniversityDepartment of Computer Science Upson Hall Ithaca, NY 14853 E-mailAddress: [emailprotected] Classification: Distribution A:Approved for Public Release; distribution unlimited. (WPAFB PA #88ABW-2010-2052)

  mailto:[emailprotected]�

• (This page intentionally left blank.)

• Page 1 of 14

  Enabling Tactical Edge Mashups with Live Objects

  Daniel Freedman1, Ken Birman1, Krzysztof Ostrowski1, MarkLinderman2, Robert Hillman2, Albert Frantz2

  1 Department of Computer Science, Cornell University, Ithaca,NY, USA 2 Information Directorate, Air Force Research Laboratory,Rome, NY, USA

  We introduce the Live Objects framework, which leverages ourdistributed object-oriented programming model and enables tacticaledge mashups for battlefield command and control. Unlike mostdeployed web services, which are typically limited to client-serverinteractions, Live Objects can simultaneously support multiplepatterns of communication, including direct client-to-clientprotocols. This means that when clients are forward deployed oraccessible only through disadvantaged links, a Live Objects systemcan remain highly responsive, whereas more standard solutions mightslow down precipitously, become unresponsive, or fail outright.Here, we summarize the approach and then suggest that, when usingit, a new kind of Service-Oriented Collaboration (SOC) applicationcan be created that will combine direct client-to-client sharing ofimagery, videos, or other real-time data captured in the field,with service-hosted data, including geographic information systems,weather prediction systems, social networks, and other databases.The client-to-client solutions can include powerful newcollaboration features implemented to help the user achievetactical Command and Control (C2) goals that require split-secondcoordination, for which reach-back to a server might be impossiblyslow. We showcase key properties of our platform through afunctional, proof-of-concept Combat Search and Rescue (CSAR)scenario.

  I. INTRODUCTION

  There is a growing opportunity within information systems to useService-Oriented Collaboration (SOC) Applications in ways that canincrease individual worker productivity, revolutionize medicalinformatics and decrease preventable healthcare mistakes, spursolutions in knowledge management, and otherwise transform spheresof collaboration and communication. Similar benefits within themilitary sector, and specifically for tactical Command and Control(C2) systems, are easily recognized in terms of soldierproductivity, property book accountability, operations (S3) andintelligence (S2) planning and coordination, and tactical missionoperations. This work discusses a representative joint militarymission, namely Combat Search and Rescue (CSAR), as an example ofthe implementation of Live Objects and SOC applications within thisfield.

  Collaborative applications will need to combine two types ofcontent: traditional web service hosted content, such as data fromgeographic and topologic map servers, image repositories, personnelrecords, and other databases, with a variety of collaborationfeatures, such as chat windows, white boards, peer-to-peer videoand other media streams, and replication and coordinationmechanisms.

  Existing web service technologies make it easy to buildapplications in which all data travels through a data center.Implementing collaboration features using these technologies isproblematic because collaborative applications can generate high,bursty update rates and yet often require low latencies and tightsynchronization between collaborating users. One can often achievebetter performance using direct client-to-client (also calledpeer-to-peer, or P2P) communication, but in today’sService-Oriented Architecture (SOA) platforms, “side-band”communication is difficult to integrate with hosted content. Agrowing number of publications on the integration of web serviceswith peer-to-peer platforms (e.g., [2], [4], [9], [11], [12], [16],[17], [18], [22], [23]) reflect this challenge; the issue yetremains unresolved (see Section VI for more details).

• Page 2 of 14

  As summarized in the abstract, we see this as a real issue inmilitary settings and other kinds of systems that depart from thecanonical wired network model on which Cloud Computing providershave focused. The forward-deployed unit or the soldier in the fieldwill often have excellent connectivity to others nearby but verylimited reach-back options, with appreciable loss rates, highlatency, and perhaps low bandwidth. Thus, solutions that force datafrom the field to be transmitted through a centralized server areinappropriate. Instead, we would seek to leverage peer-to-peerprotocols while at the same time benefitting from existing powerfulserver-hosted technologies.

  Cornell’s Live Distributed Objects platform [14] (Live Objectsfor short) allows even a non-programmer to construct content-richsolutions that blend traditional web services and peer-to-peertechnologies, and to share them with others. The developer uses adrag-and-drop approach much like creating a slide show, after whichthe solution can be shared and used on other machines bynon-developers. The users are immersed in the resultingcollaborative application; they can interact with the application,and peers can see the results instantly. Updates are applied to allreplicas in a consistent manner. Moreover, P2P communication cancoexist with more standard solutions that reach back to hostedcontent and trigger updates at associated data centers. However,when an application needs high data rates, low latency, or specialsecurity, it can use protocols that bypass the data center toachieve the full performance of the network.

  This paper makes the following contributions: • We describe anew class of Service-Oriented Collaboration applications thatintegrate service-hosted

  content with peer-to-peer message streams. We analyze the CSARscenario and list the key challenges that these kinds ofapplications place on their runtime environments.

  • We describe a new class of multi-layered mashups and contrastthem with more traditional, minibrowser-based approaches that arecharacteristic of today’s web development.

  • We discuss the advantages of decoupling transport andinformation layers as a means of achieving reusability,customizability, and rapid deployment and adaptation ofcollaboration applications in new environments. We discuss theresulting object-oriented perspective, in which instances ofdistributed communication protocols are modeled uniformly asobjects similar to those in Java, .NET, Component Object Model(COM), or Smalltalk. We present our Live Objects platform as anexample of a technology that fits well with the layered,componentized model derived through our analysis.

  • We compare performance of hosted Enterprise Service Bus (ESB)solutions with peer-to-peer communication protocols as underlyingcommunication substrates for SOC applications. While we do not findan obvious winner, we identify relative strengths of each of thesesolutions. We see this as further justification for the decouplingof information and transport layers advocated above and achieved inLive Objects: instead of a “one-size fits all” approach, anapplication can select among a menu of interchangeable componentsspecialized for different environments.

  II. LIMITATIONS OF THE EXISTING MODEL

  There are two important reasons why integrating peer-to-peercollaboration with server-hosted content is difficult. The first isnot strictly limited to collaboration and peer-to-peer protocols;rather, it is a general weakness of the current web mashuptechnologies that makes it hard to seamlessly integrate data fromseveral different sources. The web development community has slowlyconverged towards service platforms that export autonomousinteractive components to their clients, in the form of what weterm minibrowser interfaces. A minibrowser is an interactive webpage with embedded script, developed using AJAX, Silverlight, Caja,or similar technology, and optimized for displaying a single typeof content, for example, interactive maps from Google Earth orMicrosoft Virtual Earth.

  The embedded script is often tightly integrated with back-endservices in the data center, making it awkward to access theunderlying services directly from a different script or astandalone client. As a result,

• Page 3 of 14

  the only way such services can be mashed up with other webcontent is by either having the data center compute the mashup (sothat it can be accessed via the minibrowser), or by embedding theentire minibrowser window in a web page. But an embeddedminibrowser cannot seamlessly blend with the surrounding content;it functions instead as a standalone browser within its own frameand operates independently of the remainder of the web page.

  To illustrate this point, examine Figures 1 and 2. These figuresare screenshots of web applications, with content from multiplesources “mashed-up” together. Figure 1 is constructed using astandard web services approach, pulling content from Yahoo! mapsand weather web services and assembling it into a web page as a setof tiled frames. Each frame is a minibrowser with its owninteractive controls, and comes from a single content source. Toillustrate one of the many restrictions, we note that the distinctframes are not synchronized; if the user pans or zooms in the mapframe, the associated map will shift or zoom, but the other framesremain unchanged.

  In Figure 2, we observe a similar application that leverages ourLive Objects model. In this case, content from different sources isoverlaid in the same window and synchronized. There are no frameboundaries, and elements of this mashup (including maps, planes,buildings, weather, chat, data, etc.) coexist as layers withinwhich the end user can easily navigate. Data can come from manysources: this example actually overlays weather from Google onterrain maps from Microsoft’s Virtual Earth platform, extractscensus data from the US Census Bureau, and includes collaborativechat windows.

  The second problem for integration of P2P with server-hostedcontent is that, with the traditional style of web development,content is assumed to be fetched from a server, either directlyover Hyper Text Transport Protocol (HTTP), or by interacting with aweb service. Web pages downloaded by clients’ browsers containembedded addresses of specific servers. Client-to-client trafficroutes through a data center. So pervasive is this model that theweb’s HTTP is often viewed as the Internet Protocol (IP) of thenext generation of applications [6], with IP relegated to a “lowlevel” role. But HTTP, of course, is a client-server protocol.

  In contrast, Live Objects allows visual content and updateevents to be communicated using any sort of protocol, not onlyclient-server, but also overlay multicast, peer-to-peerreplication, or even a custom domain-specific protocol designed bythe content provider. These protocols could also providecoordination or other kinds of tactical roles in support of amission. As noted earlier, this makes it possible to supportcritical services such as image or video sharing with extremelyhigh levels of throughput and very low latency. It also enhancessecurity as centralized servers need not see or process dataexchanged directly between peers. Thus, the trusted domain isminimized, which eases assurance of proper security.

  Figure 1: Standard Minibrowser-Style Mashup

  Figure 2: Live Objects Multi-Layered Mashup

• Page 4 of 14

  The above discussion motivates our problem statement: • Allowweb applications to overlay content from multiple sources in alayered fashion, such that the

  distinct content layers share a single view and remain wellsynchronized: zooming, rotating, or panning should cause all layersto respond simultaneously, and an update in any of the layersshould be reflected in all other layers.

  • Allow updates to be carried by the protocol best matched tothe setting in which the application is used.

  As noted earlier, the solutions discussed here are based on LiveObjects, which supports drag-and-drop application development. Ofcourse, new types of components must be created for each type ofcontent, but the existing collection of components provides accessto several different types of web service hosted content (includingall the examples given above). Once constructed, the resulting liveapplication is stored as an eXtensible Markup Language (XML) file.The file can be moved about and even embedded in email. Users thatopen this file (using the associated local Live Objects runtime)find themselves immersed into the application. Nonetheless, astechnologies such as Microsoft’s Silverlight or Google’s Waveadvance, there is no reason that the same sorts of capabilitiesshould not eventually become available through those platforms aswell: today, they are rigid by design, not by necessity.

  Examples of transport protocols optimized for various settingsinclude support for networks with: network address translators(NATs) and firewalls (Self Organizing Live Objects, or SOLO [7]),low latency (Ricochet [1]), high throughput and very large numbersof nodes (QuickSilver Multicast, or QSM [13]), large numbers ofirregularly overlapping multicast groups (Gossip Objects, or GO[3]), and strong reliability properties. Given modern power andperformance trends, it is also very important that the technologyleverage multicore parallelism [15].

  III. SERVICE ORIENTED COLLABORATION: CSAR SCENARIO

  Before describing Live Objects in more detail, we first analyzean example collaboration application to expose the full range ofneeds and issues that arise.

  Consider a military Combat Search and Rescue (CSAR) mission:large numbers of individual military members and units would likelycontribute, spanning a spectrum of joint and coalition operationsincluding ground, air, and potentially naval assets. The settingfor the scenario on which we shall focus is the urban Area ofOperations (AO) within Baghdad, Iraq, on the Western bank of theTigris River; the season is Winter, 2004, with the first modernIraqi elections scheduled to occur in scant months in January,2005. The First Cavalry Division (1CD) maintains responsibility forthis particular AO, liaising with Marine units on the opposite sideof the Tigris. Among many such routine patrols of this particularday, a vehicle convoy from 4/5 Air Defense Artillery (ADA) of 1CDbegins its daily hunt for insurgents emplacing Improvised ExplosiveDevices (IEDs); the platoon leader heading this particular convoyhas already electronically filed his operations order, riskassessment, convoy route (including phase lines and checkpoints),and personnel, vehicle, and equipment rosters with the 4/5 ADATactical Operations Center (TOC). The Live Objects-enabled TOC hasalready autonomously integrated this data with existing hostedsources: Geographic Information System (GIS) overlays, weatherforecasts, and demographic and cultural metadata; further, it hasautomatically instantiated Live Objects channels for futureexpected data feeds as the mission unfolds.

  Soon after this patrol begins, an Air Force F-16, flying CombatAir Patrol (CAP) over Baghdad and responding to reports of sporadicmortar fire from atop a mosque, develops an unforeseen enginecompressor stall at a relatively low altitude (AGL), outside of therange for an unpowered landing at Baghdad International Airport(BIAP). The pilot chooses to eject, but first transmits anemergency distress call to a circling Airborne Warning and ControlSystems (AWACS) aircraft. The E-3 Sentry aircraft inputs thisemergency call into its onboard Live Objects instance, whichimmediately integrates the last known state of the F-16 (includingfuel levels,

• Page 5 of 14

  armament status, exact Global Positioning System [GPS]coordinates, and pertinent airframe and electronics diagnostics)into the Fighter Wing’s operation center, dispatches anoperational-immediate call for CSAR teams to be dispatched to theprojected grid, interrogates the USAF personnel files for pilotdistress codes and the Army TOC for an updated IntelligencePreparation of Battlefield (IPB) to determine expected nearbyinsurgent forces, and otherwise disseminates this event throughoutthe military hierarchy. Live Objects channels thus carry emergencynotifications, both horizontally (to joint forces and neighboringunits) and vertically (up the chain-of-command) through themilitary organizational structure. Furthermore, such messagestransit both at the edge of the physical, logical, andorganizational network (in P2P fashion), as well as between theedge and the core (hosted services), as enabled by ourframework.

  Meanwhile, USAF CSAR assets take to the sky, in the form of ateam of battle-tested pararescuemen (PJs or Pedros) aboard aPavehawk helicopter; their crew chief expects to receive a steadyflow of audio and visual Situation Reports (SITREPs) whileairborne, via his Live Objects-enabled IP radio, to better vectorthe bird to the site of the downed pilot and to prepare for anypotential resistance nearby. Simultaneously, our initial Army 4/5ADA convoy is re-tasked by its battalion TOC to cordon off thereported crash site of the plane (separate from the location of thedowned pilot); the convoy leader's handheld computer authenticatesitself on the Live Object multicast channel associated with thiscontingency, joins the appropriate Publish-Subscribe (PubSub)groups pertaining to its role, and consequently both consumes andgenerates relevant data. As our convoy successfully contains thecrashed F-16, Army and Naval Explosive Ordnance Disposal (EOD)units arrive onsite to handle the unexploded ordnance (UXO) fromthe hardpoints of the F-16’s wings, so as to ensure that members ofthe local civilian population are not harmed by them. Meanwhile,throughout this controlled demolition process, the TOC has patchedin leaders in Army Psychological Operations (PSYOPs) to ensure thatIraqi civilian leaders are aware of the crash and the effortsundertaken to protect civilian life.

  See Also

  STP 21-1-SMCT, Soldier’s Manual of Common Tasks - [PDF Document]OPERATIONS SERIES ADDP 3.18 OPERATIONAL ......ADDP 3.18 Edition 1 OPERATIONS SERIES ADDP 3.18 OPERATIONAL EMPLOYMENT OF SPACE Australian Defence Doctrine Publication 3.18 (Edition - [PDF Document]Strategic Landpower Dialogue: A Conversation with GEN James RaineyFront-line Counter-sUAS in the Ground Combat Element

  Finally, the CSAR PJs hoist the pilot to safety, communicatingthis extraction to the on-scene assets as well as the centralizedTOC and then immediately using Live Objects to stream vital signsfrom the pilot to the nearest Combat Support Hospital (CSH) so asto prepare the team of nurses and doctors for their imminentarrival. In all, Live Objects ensured immediate, resilient, andpervasive collaboration as the operation unfolded.

  Having defined the scenario, we now analyze the requirementsthat it places on our tactical C2 tool. First, we emphasize thediversity of sources upon which this C2 application relies.Realistically, such sources would likely span multiple commands,and even services, within the Department of Defense; thus, tacticalinformation for ground, sea, and air units are generated by theircorresponding entities, as are topographic, weather, sensor, anddemographic information, as well as alert traffic, ad infinitum.Data from distinct sources would generally require individualinterfaces to account for independent protocols and uniqueformats.

  Second, as conditions evolve, the team (TOC, S-2, J-3, etc., asappropriate) might need to modify the application, for instance, byadding new types or sources of information, changing the way datais represented, or even altering the communication protocols amongteam members (for example, if reach-back network links fail).Whereas a minibrowser would typically be prebuilt with all theavailable features in place, our scenario demands a much moreflexible kind of tool that can be redesigned while in use.

  Third, depending on the location and other factors, the bestnetworking protocols and connectivity options may vary. In our CSARscenario, the soldiers and airmen may have to use secure wirelessP2P protocols (IP over UHF/VHF/FM) much of the time, reaching backto hosted services only intermittently when an unmanned aerialsystem (UAS) passes within radio range. More broadly, the rightchoice of protocol should reflect the operating conditions, and asthese change, the platform should be capable of changing to adifferent protocol without disrupting the end user. This argues fora decoupling of functionality. Whereas a minibrowser packages theentire application into one object, our design better distinguishesthe presentation object from objects representing informationsources and objects representing transport protocols. Decouplingmakes it possible to dynamically modify or even replace a componentwith some other (compatible) option when changing conditionsrequire it.

• Page 6 of 14

  We have posed what may sound like a very specialized scenario,but in fact we see this as a good example of a more general needarising in many kinds of military and tactical settings. Forexample, consider an Assistant S-3 who needs to deconflict navalgunfire with the axis of advance of his cavalry troop, while alsointegrating joint air missions into the mix. The mixture ofoperations information, geographic information system data, signaloperating instructions, weather reporting, etc., may be just asrich and dynamic as in our search and rescue scenario, and theunderlying communication options equally heterogeneous andunpredictable. Alternatively, a little farther afield, imagine theability and efficiency gains for a hypothetical Inspector General(IG) audit that employed Live Objects to collect and collate thelocation (combination of hand-receipt and radio-frequencyidentification [RFID]), responsible party (company Property Book),condition (most recent DA-2404), and past unit history (chain ofprior cyclic or sensitive inventories) for the every item in agiven command’s inventory, all correlated against desired end-statefrom the unit’s Table of Organization and Equipment (TO&E) andtied into operational decision-making systems that judge a unit’seffectiveness and ensure its capabilities to conduct a givenmission. Certainly, rudimentary versions of such linked informationsystems currently exist in the form of web services, but the keyoperational design decision, forcing all communication throughcentralized servers, greatly curtails the effectiveness andresilience of the application. Similarly, a minibrowserpre-designed for a wired environment might perform poorly or failoutright under more dynamic conditions.

  Thus, if we try to build this application using today’sstandard, off-the-shelf technologies such as Silverlight or GoogleWave, we will likely construct a solution that cannot actually bedeployed in the target environment. With Live Objects, we canconstruct our required mashup using a technology not limited towired local-area network (LAN) and wide-area network (WAN)protocols with fast links back to data centers.

  Throughout the above scenario, we noted a number ofrequirements; for clarity, we now summarize them below. Asmentioned, these needs are seen in many settings and typical ofmost collaboration applications.

  • We would like to enable a non-programmer to rapidly develop anew collaborative application by composing and customizingpreexisting components.

  • We would like to be able to overlay data from multiplesources, potentially in different formats, obtained using differentprotocols and inconsistent interfaces.

  • We would like to be able to dynamically customize or modifythe application at runtime, by incorporating new data sources orchanging the way data is presented, without disrupting systemoperation.

  • We would like to be able to accommodate new types of datasources, formats, and protocols that may not have been anticipatedat the time the system was released.

  • Data might be published by the individual users, and it mightbe necessary for the users to exchange their data without access toa centralized repository.

  • Data may be obtained using different types of networkprotocols, and the type of the physical network or protocols maynot be known in advance; it should be possible to rapidly composethe application using whatever communication infrastructure iscurrently available.

  • Users may be mobile or temporarily disconnected,infrastructure may fail, and the topology of the network and itscharacteristics might change over time. The system should be easilyreconfigurable.

  The requirements outlined above might seem hard to satisfy, but,in fact, the solution is surprisingly simple. Our analysismotivates a component-oriented architecture, in which the webservices and hosted content are modeled as reusable informationlayers backed by customizable transport channels, which togetherform a graph of components. A collaborative application is then aset of such graphs.

  Our vision demands a new kind of collaboration standard, inorder to facilitate the side-by-side coexistence of components thatmight today be implemented as proprietary minibrowsers: if weenable components to talk to one-another, we need to agree on theevents and representation that the dialog will employ. Thedecoupling of functionality into layers also suggests a need for astandardized layering. In the scenario above,

• Page 7 of 14

  one can identify at least four: the visualization layer, thelinkage layer that talks to the underlying data source, the layerthat generates and interprets updates, and the transport protocol).We propose that this decoupling be done using event-basedinterfaces (as originated in the Smalltalk language), which serveas a natural way to think about components.

  Thus, rather than having the data-center developer offer contentthrough proprietary minibrowser interface, the SOC applicationdeveloper would define an event-based interface between transportand information layers; the visual events delivered by thetransport could then be conveyed to an information layerresponsible for visualizing them. This layer, in turn, wouldcapture end-user mouse and keyboard input and pass such events downthe network stack. With this type of event-based decoupling, anylayer could easily be replaced with a different one.

  In this perspective, distributed peer-to-peer protocols wouldalso be encapsulated within their respective transport layers.Thus, for example, one version of a transport layer could fetchdata directly from a server in a data center, whereas a differentversion might use a peer-to-peer dissemination architecture, suchas a reliable multicast protocol; it could leverage different typesof hardware or be optimized for different types of workloads.Provided that the different versions of the transport layer conformto the same standardized event-based interfaces, the applicationcould then switch between them as conditions or users demand.

  In this event-oriented world, end-users interact through LiveObjects that transform actions into updates that are communicatedin the form of events that are shared via the transport layer. Theprotocol implemented by the transport layer might replicate theevent, deliver it to the visualization layer of our users, andreport it through the event-based interface back to the informationlayer at which the event has originated. Thus, the transport layerwith the embedded distributed protocol would behave very much likean object in Smalltalk: it would consume events and respond withevents. This motivates thinking about communication protocols asobjects, and indeed treating them much as we treat any other kindof object in a language like Java or in a runtime environment likeJini or .NET. Doing so unifies apparently distinct approaches. Justas remotely hosted forms of content, such as a map or image can bemodeled as an object, so can network protocols be treated asobjects.

  Some P2P systems try to make everything a P2P interaction. Butin the CSAR scenario examined above, several kinds of content wouldmore naturally be hosted: topographic maps and 3D images ofterrain, buildings, and targets, and other Imagery Intelligence(IMINT) sources, weather information, enemy Order of Battle (OOB),etc. On the other hand, collaboration applications are likely toembody quite a range of P2P event streams: each separate videoobject, GPS source, sensor, etc., may have its own associatedupdate stream. If one thinks of these as topics inpublish-subscribe (PubSub) eventing systems, an application couldhave many such topics, and the application instance running on agiven user’s machine could simultaneously display data from severaltopics. We have previously said that we would like to think ofprotocols as objects. It now becomes clear that further precisionis needed: the objects are not merely protocols, but in fact areindividual protocol instances. Our system will need tosimultaneously support potentially large numbers of transportobjects running concurrently in the end-user’s system, in supportof a variety of applications and uses.

  All of this leads to new challenges. The obvious one wasmentioned earlier: today’s web services do not support P2Pcommunication. Contemporary web service solutions presume aclient-server style of interaction, with data relayed through amessage-oriented middleware broker. Even though individual clientsmay remain connected to one another, if they lose connectivity tothis central server which functions as the middleware broker, theywill no longer be able to collaborate.

  Another serious issue arises if the clients do not trust thedata center: sensitive data will need to be encrypted. The problemhere is that web service security standards tend to trust the webservices platform itself. The standards offer no help at all if weneed to provide end-to-end encryption mechanisms while alsopreventing the hosted services from observing the raw data andworkloads.

• Page 8 of 14

  Finally, we encounter debilitating latency and throughputissues: hosted services will be performance-limiting bottleneckswhen used in settings with large numbers of clients, as we showbelow in Section V.

  We summarize both the positive and negative perspectives ofexisting client-server applications: Web services standardizeclient access to hosted services and data: we can easily build someform of

  multi-framed web page that could host each kind of informationin its own minibrowser. When connectivity is adequate, relayingdata via a hosted service has many of the benefits of a

  PubSub architecture, such as robustness as the set of clientschanges. The natural way to think of our application is as anobject-oriented mashup, but web services provide

  no support for this kind of client application development. Thesolution may perform very poorly, or fail if the hosted servicesare inaccessible. All data will probably be visible to the hostedservices unless the developer uses some sort of non-

  standard end-to-end cryptography.

  IV. USING LIVE OBJECTS FOR COLLABORATION

  Our Live Objects platform supports componentized, layered mashupcreation and sharing, thus overcoming many limitations of existingweb technologies. We have used Live Objects to construct a numberof SOC applications, some of which are quite sophisticated,including a solution to the CSAR scenario as formulated in SectionIII. The major design aspects are as follows:

  • The developer starts by creating (or gaining access to) acollection of components. Each component is an object that supportslive functionality and exposes event-based interfaces by which itinteracts with other components. Examples include: Componentsrepresenting hosted content Sensors and actuators Renderers thatgraphically depict events Replication protocols Synchronizationprotocols Folders containing sets of objects Display interfacesthat visualize folders

  • Mashups of components are represented as a kind of XML webpages, each describing a “recipe” for obtaining and parameterizingcomponents that will serve as layers of the composed mashup. Weterm such an XML page a live object reference. References can bedistributed as files, via email, through HTTP, or by othermeans.

  • The application is created by building a forest consisting ofgraphs of references that are mashed together. At design time, anautomated tool lets the developer drag and drop to combinereferences for individual objects into an XML mashup of referencesdescribing a graph of objects.

  • The platform type-checks mashups to verify that they composecorrectly. For example, a 3-D visualization of an airplane may needto be connected to a source of GPS and other orientation data,which in turn needs to run over a data replication protocol withspecific reliability, ordering, or security properties.

  • When activated on a user’s machine, an XML mashup yields agraph of interconnected proxies. A proxy is a piece of running codethat may render, decode, or transform visual content, encapsulate aprotocol stack, and so on. Each sub-component in the XML mashupproduces an associated proxy. The hierarchy of proxies reflects thehierarchical structure of the XML mashup.

  • If needed, an object proxy can initialize itself by copyingthe state from some active proxy (our platform assists with thissort of state transfer).

• Page 9 of 14

  • The object proxies then become active (“live”) by relayingevents from other objects into a replication channel or byreceiving events and reacting to them (for example, by redisplayingan aircraft).

  Our approach shares certain similarities with the existing webdevelopment model, in that it uses hierarchical XML documents todefine the content. On the other hand, we depart from some of thede-facto stylistic standards that have emerged. For example, if onepulls a minibrowser from Google Earth, this minibrowser expects tointeract directly with the end user and includes embeddedJavaScript that handles such interactions. In Live Objects, thesame functionality would be represented as a mashup of a componentthat fetches maps and similar content with a second component thatprovides the visualization interface.

  Although the term mashup may sound static, in the sense ofhaving its components predetermined, this is not necessarily thecase. One kind of live object could be a folder including a set ofobjects, for example extracted from a directory in a file system orpulled from a database in response to a query. When the foldercontents change, the mashup is dynamically updated, as might occurwhen an army squad enters a building or changes direction at astreet intersection during Military Operations on Urban Terrain(MOUT) warfare.

  Thus, Live Objects can easily support applications thatdynamically recompute the set of “visible” objects, as a functionof location and orientation, and dynamically add or remove themfrom the mashup. A rescuer would automatically and instantly beshown the symbols of others who are already working at thatposition and be able to follow team SITREPs or point-to-pointdialog with them, through chat objects that run over multicastprotocol objects. This model can support a wide variety ofcollaboration and coordination paradigms.

  In summary, the Live Objects platform makes it easy for anon-programmer to create the needed application. In our CSARscenario, the TOC pulls prebuilt object references from a folder,each corresponding to a desired kind of information. Hosted data,such as weather, terrain maps, etc., would correspond to objectsthat “point” to a web service over the network. Peer-to-peerobjects would implement chat windows, soldier Liquid / Ammo /Casualty / Equipment (LACE) status updates, squad video feeds, etc.Event interfaces allow such objects to coexist in a shared displaywindow that can pan, zoom, jump to new locations, etc.

  The relative advantages and disadvantages of our model can besummarized as follows: Like other modern web development tools, ourplatform supports drag-and-drop style of development,

  permitting fast, easy creation of content-rich mashups. Theresulting solutions are easy to share. By selecting appropriatetransport layers, functionality such as coordination betweensearchers can

  remain active even if connectivity to the data center isdisrupted. Streams of video or sensor data can travel directly andwill not be delayed by the need to “ricochet” off

  a remote, and potentially inaccessible, server. New event-basedinteroperability standards are needed. Lacking them, we could loseaccess to some

  of the sophisticated proprietary interactive functionalityoptimized for proprietary minibrowser-based solutions with embeddedJavaScript.

  Direct peer-to-peer communication can be much harder to use thanrelaying data through a hosted service that uses an ESB model.Furthermore, the lack of a “one size fits all” PubSub substrateforces the developers to become familiar with and choose between arange of different and incompatible options. An inappropriatechoice of transport could result in degraded Quality of Service(QoS), inferior scalability, or even data loss.

  V. PERFORMANCE EVALUATION

  Central to our argument is the assertion that hosted eventnotification solutions scale poorly and stand as a barrier tocollaboration applications, and that developers will want tocombine hosted content with P2P protocols to overcome theseproblems. In this section we present data to support our claims.Some of the

• Page 10 of 14

  results (Figure 3 and Figure 4) are drawn from a widely citedindustry whitepaper by Fiorano Software [8] and were obtained usinga testing methodology and setup developed and published by SonicSoftware [20]. The remaining measurements derive from our ownexperiments.

  In Figure 3, Fiorano Software analyzes the performance ofseveral commercial ESB products, plotting the maximum throughput(in messages per second) for 1024-Byte messages. The experimentvaries the number of subscribers while using a single publisherthat communicates through a single hosted message broker on asingle topic. Brokers are configured for message durability: evenif a subscriber experiences a transient loss of connectivity, thepublisher retains and hence can replay all messages. As the numberof subscribers increases, performance degrades sharply. Althoughnot shown, latency will also soar because the amount of time thebroker needs to spend sending a single message increases linearlywith the number of subscribers.

  In collaboration applications, durability is often not required.Figure 4 examines throughput in an experiment in which thepublisher does not log data, in which a disconnected subscriberwould experience a loss. We find that while the maximum throughputis much higher, the degradation of performance is even moredramatic. One could improve scalability using clustered servicestructures, but such a step would have no impact on latency, sinceclients would still need to relay data through the data center. Wenote that hosted ESB solutions do not necessarily scale well, andthat the client-to-data center communication path could introduceintolerable performance overheads.

  Next, we report on experiments conducted independently atCornell University, focusing on scalability of event notificationplatforms that leverage peer-to-peer techniques for disseminationand recovery. In Figure 5, we compare the maximum throughput of twodecentralized reliable multicast protocols, again with 1024-bytemessages, a single topic, and a single publisher. Unlike in theprevious external Fiorano tests, which utilized a gigabit network,these experiments use a 100 Mbps LAN, limiting the peak performanceto 10,000 messages per second. QSM [13] achieves stable highthroughput (saturating the network). JGroups, a popular product,runs at about a fifth of that speed, collapsing as the number ofsubscribers increases. Also, at small loss rates, latency in QSM isat the level of 10-15 ms irrespectively of the number ofsubscribers.

  Figure 6 demonstrates that QSM maintains its high performancewhen the number of topics is varied. Here, we report performancefor 110 subscribers within QSM, but performance for other groupsizes is similar. We examine JGroups performance, forconfigurations that vary between 2 and 110 subscribers, as afunction of number of topics. While we observe higher JGroupsperformance with smaller group sizes, this erodes as the number oftopics increases. JGroups failed when we attempted to configure itwith more than 256 topics.

  Finally, we look at two scalable protocols under conditions of“stress,” with a focus on delivery latency (y-axis) as a fixedmessage rate is spread over varying numbers of topics. Sixty-foursubscribers each join some number of topics; a publisher sends dataat a rate of 1000 messages per second, selecting the topic in whichto send at random. Our experimental setup, on Emulab, injects arandom 1% message loss rate. In Figure 7, we see that Ricochet [1],a Cornell-developed protocol for low-latency multicast, maintainssteady low-latency delivery (about 10 ms; logarithmic y-axis) asthe number of topics increases to 1024 (logarithmic x-axis). Incontrast, latency soars when we repeat this with theindustry-standard Scalable Reliable Multicast (SRM), widely usedfor event notification in commercial datacenters. As can be seen inthe graph, SRM’s recovery latency rises linearly in the number oftopics, reaching almost eight seconds with 128 groups.

  To summarize, our experiments confirm that: • Hosted enterpriseservice bus architectures can achieve high levels of PubSubperformance for small

  numbers of subscribers, but performance degrades very sharply asthe number of subscribers or topics grows.

  • JGroups and SRM, which do not leverage P2P techniques, scalepoorly in the number of subscribers or topics. QSM and Ricochet,where subscribers cooperate, scale well in these dimensions.

  • Ricochet achieved the best recovery latency when message lossis an issue (but at relatively high overhead, not shown on thesegraphs). At small loss rates, QSM achieves similar average latencywith

• Page 11 of 14

  Figure 6: Scalability of QSM and JGroups (throughput for variousnumbers of topics)

  1

  2

  3

  4

  5

  6

  7

  8

  1 4 16 128 512 2048 8192

  Thro

  ughp

  ut (k

  msg

  s/s)

  Number of Topics

  JGroups(2 nodes)

  JGroups(8 nodes)

  JGroups(32 nodes)

  JGroups(64 nodes)

  JGroups(110 nodes)

  QSM (110 nodes)

  Figure 7: Delivery latency for SRM and Ricochet with varyingnumbers of topics

  8

  32

  128

  512

  See Also

  Andrea B. on LinkedIn: IEEE Schenectady PES Chapter: Transforming Substation Protection Relay…

  2048

  8192

  1 2 4 8 16 32 64 128 256 512 1024

  Reco

  very

  Lat

  ency

  (ms)

  Number of Topics

  SRM

  Ricochet

  Figure 5: Scalability of QSM and JGroups (throughput for variousgroup sizes)

  1

  2

  3

  4

  5

  6

  7

  8

  9

  10

  1 9 17 25 33 41 49 57 65 73 81 89 97 105

  Thro

  ughp

  ut (k

  msg

  s/s)

  Group Size

  Jgroups

  QSM(1 sender)

  QSM(2 senders)

  Figure 4: Scalability of commercials ESBs (without datalogging)

  5

  10

  15

  20

  25

  30

  Fiorano MQ 2008

  Tibco EMS 4.4.0

  Sonic MQ 7.0

  Active MQ 4.1.0

  Jboss 1.4 Sun MQ 4.1

  Thro

  ughp

  ut (k

  msg

  s/s)

  1 Sub

  10 Subs

  25 Subs

  50 Subs

  Figure 3: Scalability of commercials ESBs

  0.0

  0.2

  0.4

  0.6

  0.8

  1.0

  1.2

  1.4

  Fiorano MQ 2008

  Tibco EMS 4.4.0

  Sonic MQ 7.0

  Active MQ 4.1.0

  Jboss 1.4 Sun MQ 4.1

  Thro

  ughp

  ut (k

  msg

  s/s)

  1 Sub

  10 Subs

  25 Subs

  50 Subs

• Page 12 of 14

  considerably lower network overheads, but, if a packet is lost,it may take several seconds to recover it, making it lessappropriate for time-critical applications.

  We do not see any single optimal choice here: each of thesolutions tested has some advantages that its competitors lack.Indeed, we are currently developing a new P2P protocol suite,called SOLO [7]; it builds an overlay multicast tree within whichevents travel, and is capable of self-organizing in the presence offirewalls, NATs, and bottleneck links. A separate project involvesa new protocol suite known as the Properties Framework [15]. Thegoal is to offer strong forms of reliability that can be customizedfor special needs. Thus, speed and scalability are only elements ofa broader story. Developers will need different solutions fordifferent purposes.

  VI. PRIOR WORK

  The idea of integrating web services with peer-to-peer platformsis certainly not new ([2], [4], [9], [11], [12], [16], [17], [18],[22], [23]). The existing work falls roughly into two categories.The first line of research is focused on the use of peer-to-peertechnologies, particularly Juxtapose (JXTA), as a basis forscalable web service discovery. The second line of researchconcentrates on the use of replication protocols at the web serviceback-end to achieve fault-tolerance. In both cases, P2P platformssuch as JXTA are treated not as means of collaboration or mediacarrying live content, but rather as a supporting infrastructure atthe data center backend. In contrast, our work is focused onblending the content available through P2P and web serviceprotocols; neither technology is subordinate with respect to theother.

  Technologies that use P2P protocols to support live andinteractive content already exist; an excellent example of suchtechnology is the Croquet [19] collaboration environment, in whichthe entire state of a virtual 3D world is stored in a peer-to-peerfashion and updated using a two-phase commit protocol. Other workin this direction includes the “Serverless 3D World” [21]. However,none of these systems supports the sort of componentized, layeredarchitectures that we advocate here. The types of peer-to-peerprotocols these systems can leverage, and the types of traditionalhosted content they can blend with their P2P content, are limited.In contrast, our platform is architected with such extensibility inmind; every part of it can be replaced and customized, anddifferent components within a single mashup application canleverage different transport protocols.

  Prior work on typed component architectures includes atremendous variety of programming languages and platforms,including early languages such as SmallTalk alongside moderncomponent-based environments such as Java, .NET, or COM,specialized component architectures such as MIT’s Argus system [10], flexible protocol composition stacks such as Bast [5],service-oriented architectures such as Juni, and others. None ofthese, however, has been used in the context of integratingservice-hosted and peer-to-peer content. Discussion of componentintegration systems and their relation to Live Objects, however, isbeyond the scope of this paper. Ostrowski and coauthors [14]provide more details.

  Furthermore, much relevant prior work consists of the scriptinglanguages mentioned in the discussion above: JavaScript, Caja,Silverlight, and others. As explained earlier, our belief is thateven though these languages are intended for fairly general use,they have evolved to focus on minibrowser situations in which theapplication lives within a dedicated browser frame, interactsdirectly with the user, and cannot be mixed with content from othersources in a layered fashion. Live Objects can support minibrowsersas objects, but we argue that we gain flexibility by modelinghosted content at a lower level as components that interact viaevents and by focusing on the multi-layered style of mashups asopposed to the standard tiled model.

  Finally, this paper builds extensively upon our previousdiscussion of the application of Live Objects to Service-OrientedComputing [24], with added detail and discussions that examine itsuse in tactical mashups, both generally as well as in the form ofthe specific CSAR scenario in Section III.

• Page 13 of 14

  VII. CONCLUSIONS

  To build ambitious collaboration applications, the web servicescommunity will need ways to combine (to “mash up”) content frommultiple sources. These include hosted sources that exist in datacenters and support web service interfaces, but also directpeer-to-peer protocols capable of transporting audio, video,realtime chat and other content at high data rates with lowlatency. They must allow disconnected collaboration, withoutmandatory reach-back to data centers.

  Our review of the performance of ESB eventing solutions in thestandard hosted web services model clarifies that hosted eventchannels do not have the scalability and latency properties neededby many applications. P2P alternatives often achieve far betterscalability, lower latency, and higher throughput. They also havesecurity advantages in that the data center does not see, and thuspotentially compromise, every event.

  The Live Objects platform can seamlessly support applicationsthat require a mixture of data sources, including both hosted anddirect P2P event-stream data. Further benefits include an easy touse drag-and-drop programming style that yields applicationsrepresented as XML files, which can be shared as files or even viaemail. Users that open such files find themselves immersed in amedia-rich collaborative environment that also offers strongreliability, high performance, impressive scalability and (in thenear future) a powerful type-driven security mechanism. Mostimportant of all, Live Objects are real: the platform isdistributed under a FreeBSD open-source license through Microsoft’smanaged CodePlex source repository, as well as directly fromCornell University.

  VIII. REFERENCES

  [1] Mahesh Balakrishnan, Ken Birman, Amar Phanishayee, StefanPleisch. “Ricochet: Lateral Error Correction for Time-CriticalMulticast.” NSDI 2007.

  [2] Farnoush Banaei-Kashani, Ching-Chien Chen, Cyrus Shahabi.“WSPDS: Web Services Peer-to-peer Discovery Service.” ICOMP2004.

  [3] Ken Birman, Anne-Marie Kermarrec, Krzysztof Ostrowski, MarinBertier, Danny Dolev, Robbert van Renesse. “Exploiting Gossip forSelf-Management in Scalable Event Notification Systems.” DEPSA2007.

  [4] Jorge Cardoso. “Semantic integration of Web Services andPeer-to-Peer networks to achieve fault-tolerance.” IEEE GrC2006.

  [5] Benoit Garbinato, Rachid Guerraoui. “Flexible ProtocolComposition in Bast.” ICDCS 1998. [6] Kelly Jackson Higgins.“Microsoft Report: Physical Data Theft, Trojans Up; Bug DisclosureDown.”

  Security Dark Reading (2008). [7] Qi Huang, Ken Birman. “SOLO:Self Organizing Live Objects.” Technical Report (December, 2008).[8] “JMS Performance Comparison for Publish Subscribe Messaging”.Fiorano Software Technologies Pvt.

  Ltd., February 2008. [9] Timo Koskela, Janne Julkunen, JariKorhonen, Meirong Liu, Mika Ylianttila. “Leveraging Collaborationof

  Peer-to-Peer and Web Services.” UBICOMM 2008. [10] BarbaraLiskov and Robert Scheifler. “Guardians and Actions: LinguisticSupport for Robust, Distributed

  Programs.” TOPLAS 5, 381-404 (1983). [11] Shenghua Liu, PeepKüngas, Mikhail Matskin. “Agent-based web service composition withJADE and

  JXTA.” SWWS 2006. [12] Federica Mandreoli, Antonio Perdichizzi,Wilma Penzo. “A P2P-based Architecture for SemanticWeb

  Service Automatic Composition.” DEXA 2007.

• Page 14 of 14

  [13] Krzysztof Ostrowski, Ken Birman, Danny Dolev. “QuickSilverScalable Multicast (QSM).” NCA 2008. [14] Krzysztof Ostrowski, KenBirman, Danny Dolev, Jong Hoon Ahnn. “Programming with LiveDistributed

  Objects.” ECOOP 2008. [15] Krzysztof Ostrowski, Chuck Sakoda,Ken Birman. “Self-Replicating Objects for Multicore Platforms.”

  ECOOP 2010. [16] Mike Papazoglou, Bernd Krämer, Jian Yang.“Leveraging Web-Services and Peer-to-Peer Networks.”

  CAiSE 2003. [17] Changtao Qu, Wolfgang Nejdl. “Interacting theEdutella / JXTA Peer-to-Peer Network with Web

  Services.” SAINT 2004. [18] Mario Schlosser, Michael Sintek,Stefan Decker, Wolfgang Nejdl. “A Scalable and Ontology-basedP2P

  Infrastructure for Semantic Web Services.” P2P 2002. [19] DavidSmith, Alan Kay, Andreas Raab, David Reed. “Croquet: ACollaboration System Architecture.” C5

  2003. [20] Sonic Performance test suite, available at:

  http://www.sonicsoftware.com/products/sonicmq/performance_benchmark/index.asp[21] Egemen Tanin, Aaron Harwood, Hanan Samet, Sarana Nutanong,Minh Tri Truong. “A Serverless 3D

  World.” GIS 2004. [22] Minjun Wang, Geoffrey Fox, ShrideepPallickara. “A Demonstration of Collaborative Web Services and

  Peer-to-Peer Grids.” ITCC 2004. [23] Zhenqi Wang, Yuanyuan Hu.“A P2P Network Based Architecture for Web Service.” WiCom 2007.[24] Ken Birman, Jared Cantwell, Daniel Freedman, Qi Huang, PetkoNikolov, Krzysztof Ostrowski. “Building

  Collaboration Applications that Mix Web Services Hosted Contentwith P2P Protocols.” ICWS 2009.

  http://www.sonicsoftware.com/products/sonicmq/performance_benchmark/index.asp�

  IntroductionLimitations of the Existing ModelService OrientedCollaboration: CSAR ScenarioUsing Live Objects forCollaborationPerformance EvaluationPriorWorkConclusionsReferences

Command and-control

Command and Control Systems Requirements Analysis· 2011-05-13· command and control systems requirements analysis volume 3 command and control system functions in the hierarchy

Command Control Interface

Military Surface Deployment and Distribution Command … Reg 25...· 1 sddcr 25-30 department of the army headquarters. military surface deployment and distribution command 1 soldier

JAMES R. SNIDER - BIO [Read-Only]· 2011. 5. 13.· AMC-Army READINESS Command… Supporting Every Soldier Every Day U.S. Army Materiel Command • Providing Institutional Stability

Command Control Theory - GlobalSecurity.org

ADVANCED COMMAND, CONTROL,

command and control

Nato Command and Control Model

Fort Jackson soldier competes on ‘Jeopardy!’jackson.armylive.dodlive.mil/files/2014/03/July-17.pdfh Fort Jackson soldier competes on ‘Jeopardy! ... Command Sgt. Maj. Christopher

Command Control Interface Command Reference · PDF fileSyntax ... Hitachi Command Control Interface Command Reference and , , , , ,

Introducing command control

Sanctuary™ Command Control

Command and Control Leadership

Addp 00.1 (Command and Control)

11th ICCRTS 11th International Command and Control ...· 11th International Command and Control Research and Technology Symposium ‘Coalition Command and Control in the Networked

An Exposé of Autonomous Agents in Command and Control ...An Exposé of Autonomous Agents in Command and Control Planning Christopher Matthews Communications Electronics Command Command

11th INTERNATIONAL COMMAND AND CONTROL ...11th INTERNATIONAL COMMAND AND CONTROL RESEARCH AND TECHNOLOGY SYMPOSIUM: COALITION COMMAND AND CONTROL IN THE NETWORKED ERA Convoy: Defining

NATO COMMAND AND CONTROL CENTRE OF EXCELLENCE …· 1 nato command and control centre of excellence . nato command and control centre . of excellence

SERVING THE SOLDIER SERVING THE NATION - PEO · PDF fileSERVING THE SOLDIER... SERVING THE NATION ... assist in software and hardware installation, ... • Unit Personnel System/Command

UNITED STATES SPECIAL OPERATIONS COMMANDBUD/S Basic Underwater Demolition School C2 Command and Control C3I Command, Control, Communications, and Intelligence C4 Command, Control,

PC CONTROL COMMAND REFERENCE FOR THE TS …€¦· PC CONTROL COMMAND REFERENCE FOR THE TS-590S TRANSCEIVER ... PC CONTROL COMMAND REFERENCE GUIDE ... when this data transfer will

Command and Control Information

Enabling Command and Control - Mission Command at Vicksburg

Command and Control - hsdl.org

ERTMS/ETCS UNIT INTERFACES BETWEEN CONTROL-COMMAND AND ...· INTERFACES BETWEEN CONTROL-COMMAND AND SIGNALLING TRACKSIDE ... INTERFACES BETWEEN CONTROL-COMMAND AND SIGNALLING

Communications Command and Control

Digital Command Control Troubleshooting -

1 Purpose The program is designed to increase soldier and mission readiness, allowing Commanders to track soldier high-risk behaviors within their command

Digitrax Command Control Starter Set Manual· Digitrax Command Control Starter Set Manual ... take full advantage of your new Digital Command Control ... your commands.For more information

Command and Control Center

Mission Command: Command and Control of Army Forces

Program Executive Office Command Control Communications ...· Program Executive Office Command Control communications ... PROGRAM EXECUTIVE OFFICE COMMAND CONTROL AND COMMUNICATIONS