Workflow Management for Paramedical EmergencyOperations within a Mobile-Static Distributed Environment

Adina Riposan∗

Military Technical Academy81-83, George Cosbuc blvd

Bucharest, Romaniaadina@p2pgridbook.com

Victor V. PatriciuMilitary Technical Academy81-83, George Cosbuc blvd

Bucharest, Romaniavip@mta.ro

ABSTRACTIn this paper we present the OMU Workflow platform andunderlaying toolkit we developed based on the Triana Work-flows environment, for implementing the Workflow Manage-ment of Paramedical Emergency Operations scenario withinan intelligent context-aware mobile distributed Peer-to-Grid(P2G) infrastructure. The underlying OMU toolkit is astand-alone system and the core components are indepen-dent of any workflow environment. We discuss the novelhybrid P2G architectural model we designed consolidatingPeer-to-Peer and Grid computing research, providing newsolutions to a dynamic distributed data-driven scenario thatcould radically increase the volume and timeliness of avail-able information for decision support during the rescue op-erations. We also discuss the application of our workflowplatform to other domain problems in our future work andthe next steps in the path of testing and validation.

KeywordsWorkflows, Triana Workflows, Paramedical Emergency Op-erations, P2P, Grid, P2G, SOA, Web Services, DistributedComputing, Mobile Computing, Information Exchange

1. INTRODUCTIONThe healthcare domain represents a critical field where spe-cific situations and day-to-day operations permanently raisethe need for novel and more effective solutions. The diffi-culties are usually brought by the distributed topology ofthe institutions involved in the specific infrastructures, thelimited capacity of the communication networks, as well asthe strict security requirements, privacy and confidentialityconstraints regarding the patients data and restricted con-trolled access to specific information based on specific rolesgranted within the community.

This paper describes the solution we provided to address

∗Corresponding author

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.WORKS 09, November 15, 2009, Portland Oregon, USA.Copyright 2009 ACM 978-1-60558-717-2/09/11...$10.00

the specific requirements we have identified (and previouslydiscussed in our papers [31] [28]) of a complex Paramedi-cal Emergency Operation Scenario - a dynamic distributeddata-driven scenario requiring a novel distributed context-aware architecture that could radically increase the volumeand timeliness of available information for decision support.The complex infrastructure for high-risk rescue operationsrequires the presence of more than one ambulance, poten-tially a large fleet of ambulances, for managing and coordi-nating the rescue operation on vast geographic areas, cross-ing different countries and administrative domains, high-risklocations with low accessibility; it also typically requires in-teroperability and communication with other governmentalentities (fire brigade, police fleet, public defence) [28] [33]that can potentially be involved in the operation.

The Paramedical Emergency Operation Scenario includesthe medical infrastructure (consisting of static and mobileentities), the interactions and real-time communication be-tween the participating entities, as well as the managementand coordination of the fleet of ambulances. This scenarioalso addresses the data discovery and integration from bothstatic and mobile data sources, within a virtual environmentcreated ’on-the-fly’ during the emergency operation [7], sothat the ad-hoc patient evaluation data can be combinedwith the patient historical data (patient health records) -enabling effective supervision of the rescue procedures anddecision support during the transportation of the patient tothe specialized emergency medical unit.

We used Workflow technology [37] [19] [16] [20] [38] [27] tomodel this particular healthcare scenario - the ParamedicalEmergency Operation. We describe in this paper the OMU 1

toolkit we implemented in order to provide a workflow-typesimulation of the communication networks, information anddata flows, connecting all the components involved in thereal-life scenario, and following all the required steps fromthe initial emergency call to the discharge of the patient(s)to the specialized emergency medical unit selected.

We used Triana Workfows [38] for implementing this sce-nario; however, the underlying OMU toolkit is a stand-alonesystem and the core components are independent of anyworkflow environment and allow portability to other work-flow systems. Triana Workflow System [38] utilises WSPeer

1OMU stands for ’Operatiune Medicala de Urgenta’ which isthe Romanian term for ’Paramedical Emergency Operation’

[24], which can host Web services in a containerless environ-ment and has bindings to both Web Services and WS-RF[26]. Triana [38] has full direct support (including GUIs) forWS-RF (unlike other workflow systems like Taverna [27] orKepler [16] or Trident [14]). Lastly, Triana has a far morecomprehensive and flexible GUI for editing workflows thanother systems - it enables interactive graphical programmingof the distributed tasks and complex editing - and it hasthe capability to mix and match services, e.g. it can inte-grate core Java components, P2P, WS-RF, and Web servicesand Grid constructs (using GAT) within the same workflow.This flexibility is essential and is unique to Triana.

In order to provide a more efficient and stable solution to therequirements of a complex distributed intelligent infrastruc-ture for the Paramedical Emergency Operations Scenario,we designed a hybrid novel architectural model - the mobiledistributed Peer-to-Grid (P2G) infrastructure - that we in-troduced in our previous papers [31]. We describe furtherin this paper the P2G (Peer-to-Grid) framework we haveresearched on (together with the team of computer scien-tists at Cardiff University) in the view to consolidate Peer-to-Peer and Grid computing research. By the new archi-tectural paradigm, we addressed the mobility of transientlyconnected devices and the need to support interactive config-urability of components for dynamic data-driven distributedscenarios. The P2G model allows data aggregation frommultiple, distributed, and heterogeneous (mobile and static)data sources, data fusion of various media and data types.Such architectural model has the capacity to advance thestate-of-the-art and to provide increased stability and effi-ciency as compared to the classic architectures.

This paper is structured as follows: Section 2 provides thedesign of the mobile distributed P2G architecture applied tothe Paramedical Emergency Operations Scenario; Section 3further discusses the Triana workflow implementation andthe OMU toolkit; and Section 4 presents our future workregarding the application of the architecture and toolkit toother domain problems and the next steps in the path oftesting and validation.

2. ARCHITECTURE AND DESIGNThe recent developments of the Grid [22], Mobile Grid [7],and Peer-to-Peer (P2P) [1][39] technologies allow the re-search communities to explore new possibilities to advancesuch systems and adapt them to specific situations so thatthe current modes of operations and state-of-the-art proce-dures could be made more efficient and new solutions be pro-vided to existing complex problems. We describe here thePeer-to-Grid (P2G) novel architecture we have designed byintegrating P2P and Grid technologies, and previously intro-duced in our papers [31]. This hybrid architectural modelcould represent a shift in paradigm from two perspectives:it addresses the seamless integration of mobile and staticdistributed resources, incorporating solutions to enable truemobility and transient connectivity of such devices in thecontext of WSRF [26]; and it supports the run-time integra-tion of components and data through web service orientation(SOA) and dynamic discovery of services and resources.

The implementation of the P2G architecture to the Paramed-ical Emergency Operation scenario allows the use of dis-

tributed computing techniques to connect and integrate staticand mobile medical entities, bringing the tools, expertiseand databases together to aggregate patient data ’on-the-fly’ from static and mobile data sources. The distributedinfrastructure allows for medical data discovery and inte-gration from both the static entities (medical centers) andmobile entities (ambulance medical devices). We further cre-ated a patient-centered, case-specific, context-aware virtualenvironment - which we called the Virtual Emergency Envi-ronment (VEE) - hosted by the Medical Emergency ControlCentre (ECC), enabling the integration of all necessary de-cision support data for the rescue operation [31].

The mobile distributed P2G infrastructure is designed as athree-layered architecture consisting of: the mobile P2P layerintegrating the mobile nodes (potentially designed as a com-plex peer groups topology with super-peers); the static Gridlayer integrating the static Grid nodes within the heavy-weight Grid infrastructure; and the Bridge layer acting as aGateway between the first two layers (potentially formed of aset of bridge nodes providing cumulated functionality). Themobile and static connectivity requirements suggested thatthe mobile nodes should be loosely coupled with the staticnodes, allowing true mobility and transient connectivity formobile entities. Within the bridge-node architecture, certainstatic nodes are pre-configured to act as gateway/bridge tothe transient mobile devices. The bridge nodes store thestate of the mobile device during its interaction while themobile node acts as a remote control to the work being co-ordinated by the bridge node.

Within the specific Paramedical Emergency Operation in-frastructure, the three-layered architecture is translated asfollows (as shown in Figure 1):

• The static entities forming the static Grid layer are theMedical Data and Knowledge Resource Centres (med-ical units that keep patient data and health recordsdatabases and dispose of specific medical expertise)and the Medical Emergency Units (hospitals with emer-gency units where the patients can be transported).

• The mobile entities forming the mobile P2P layer arethe fleet of Ambulances, hosting the Controller Nodes(CN) that play the role of super-peers in the P2P layer,the Medical Devices and Personnel Devices (medicaldevices and tools used in ambulances, and intelligentcommunication mobile devices used by the paramedi-cal personnel, both representing peers in the P2P layer).

• The Gateway or the Bridge layer between the twolayers (static and mobile) is ensured by the MedicalEmergency Control Centre (ECC) (the paramedicalmanagement and monitoring authority for the rescueoperation).

A portal hosted by the Emergency Control Centre (ECC) in-terfaces the infrastructure for the end-user (based on accesspolicies and roles), allowing the emergency coordinating andmedical staff to have permanent access to information, dis-playing the new data and knowledge dynamically integratedduring the rescue operation.

Figure 1: Distributed P2G Infrastructure forParamedical Emergency Operations

The ambulance environment consists of a set of mobile de-vices that communicate and exchange data locally duringthe rescue operation - medical tools and sensors and person-nel devices (e.g., the personnel intelligent mobile devices re-ceive notices and automatic messages from the medical toolsand sensor devices). The Controller Node (CN) situated inthe ambulance acts as a local Gateway to the ambulance en-vironment, and handles data transfer to other ambulancesparticipating in the rescue operation and to the EmergencyControl Center (ECC). The Controller Node can be inte-grated into the ambulance-vehicle itself, or can be added tothe vehicle as a separate device.

The medical devices and tools used in the ambulances recordreal-time data from patients, and perform ad hoc vital med-ical data acquisition and quantification. By the wearablesensor data acquisition, patient’s medical and physiologicalparameters, biometric and environmental data are perma-nently collected. The sensors are further integrated via basestations and pre-processed locally. This allows the unobtru-sive monitoring of the patient body function and parame-ters, such as electrocardiogram (ECG), heart and respira-tory rates, blood pressure, blood glucose level, oxygen sat-uration, skin temperature etc. After local integration andprocessing, the filtered signals and data are instantly trans-mitted to the Emergency Control Centre (ECC) and inte-grated within the Virtual Emergency Environment (VEE).All medical and physiological measurements integrated bythe ambulance environment become available, via the Gate-way (hosted by the Emergency Control Centre), to the staticGrid of medical centers as well as to the other mobile enti-ties (e.g., other ambulances) involved in the infrastructure.Similarly, the medical data discovered from the static Gridmedical infrastructure (e.g., patient health records and spe-cific knowledge provided by specialized medical units) areintegrated by the ECC within the Virtual Emergency En-vironment (VEE) and are further provided, via the Gate-way, to the participants involved in the mobile infrastructure(ambulances and medical devices).

The common messaging framework used by this model is

SOAP supported by OGSA-compliant services [21] integratedusing WS-RF [26]. The prototype design was based aroundthe WSPeer package [24] [13], that allows hosting and inter-action with Web services and WS-RF services within bothGrid and ad-hoc P2P environments, and the integration ofthe bridge within the mobile-to-static architecture throughthe rendezvous peers.

In order to ensure the appropriate level of security in bothenvironments, we integrate the Grid and P2P Security sys-tems bridging the two security contexts. The P2PS [39][5] technology (based on Jxta [25] technology) enables peernodes and peer groups to be authenticated using X-509 cer-tificates. A proxy can act as a delegate of a P2PS group tosend and receive the group messages; if any of these messagesis required by the static Grid, then the proxy certificate canbe used for authentication within the Grid Security Infras-tructure (GSI) for allowing message exchange with the staticGrid layer.

We further investigate the development of the necessary ex-tensions to the Jxta [25] reference implementation for pro-viding advanced security functionalities [40] [17], and thecustomizations of the specific services for peer group orga-nizing, membership and security according to the require-ments of the practical application scenario: the extension ofthe MembershipService; the implementation of a Policy Ser-vice capable to establish peer group policies, both regardinggroup membership and security, as well as regarding groupservices such as rendezvous and data transfer outside thegroup, between peer groups within the mobile infrastruc-ture and between the peer groups and the static Grid viathe Gateway; and the development of advanced Authenti-cation methods. We investigate the implementation of aMembershipService with capabilities for complete manage-ment of issuing and validating the authentication credentialsfor the group peers, the implementation of more advancedauthentication credentials based on the simple credentialsoffered by the Jxta [25] reference implementation, as well asa mechanism of the MembershipService for using and vali-dating authentication credentials when they are provided byother (external) peers requiring services.

3. IMPLEMENTATIONWe describe here the Triana Workfows [38] implementationfor this scenario. The OMU workflow connects all the com-ponents involved in the Paramedical Emergency Operationtogether and follows the specific steps in the scenario, fromthe initial emergency call to the discharge of the patient(s)to the specialized emergency medical unit selected, simulat-ing the communication networks and the information anddata flows within a mobile distributed Peer-to-Grid (P2G)infrastructure. In this section we describe the OMU toolkit,the Web services discovery and hosting mechanisms we im-plemented, and the Triana workflow environment.

3.1 The OMU ToolkitFigure 2 describes the OMU Platform. The middle levelsshow the workflow management engine and the main mod-ules in the OMU toolkit, which adapt their behaviour ac-cording to the OMU node they are working on. For BridgeNodes, both the static and mobile toolkits are used in con-junction. The devices and players in the network (both

Figure 2: The OMU Platform

Figure 3: The OMU Triana toolbox and units

static and mobile) are implemented on top of these services.

The OMU toolkit is essentially a set of Java componentsand Web Services, each having its own user interface panel(i.e. JPanel) if appropriate. After having defined the com-ponents and interfaces for simulating the OMU Scenario,the translation was a simple case of importing the compo-nents as Triana units and displaying the appropriate panelsin the Triana GUI containers. Triana [38], through its multi-threaded distributed design, reduced the integration effortand provided greater flexibility for the connectivity of thecomponents across networks. The resulting Triana OMU in-tegration provided a flexible set of configurable componentsthat can be used to search, discover, interrogate, select, andintegrate data from distributed medical datasets.

The OMU workflow components are shown in the toolboxarea to the left of the Triana screenshot in Figure 3, display-ing the OMU toolbox and the OMU units dropped onto thework-surface. The ScenariuOMU group unit is a groupedworkflow that allows workflows to be saved and retrieved forlater reuse. The OMU workflow is launched by un-grouppingthe ScenariuOMU group unit.

Each Triana unit (and OMU component) has a user interface

(GUI) that enables parameters specific to that component tobe edited (in Triana, double-clicking the unit shows the in-terface for that component). This allows the configurationof the Scenario components, and the possibility to imple-ment and select from several scenarios. We implementedtwo scenarios for the Paramedical Emergency Operations,each involving a different set of data and parameters aboutthe patient, medical and environmental variables. The com-munication flow and data transfer between the componentsare graphically signaled and can be followed from one com-ponent to another during the workflow process. Each mile-stone finalizing a particular step in the workflow displays- within automatic pop-up graphic interfaces - the specificinformation dynamically integrated by the workflow compo-nents. Further on, all information is displayed within theVirtual Emergency Environment (VEE) generated by theEmergency Control Center (ECC).

The ECC hosts the Gateway component facilitating the com-munication and data transfer between the medical staticGrid and the mobile P2P infrastructure, and negotiatingbetween the two security contexts. The ECC also hosts theOMU Portal for interfacing the information to the user andgenerates the Virtual Emergency Environment (VEE) thatis displayed to the user within the OMU Portal.

The OMU Portal contains three portlets displaying real-timeinformation during the emergency operation (patient identi-fication data, medical data and environmental information):

• the Gateway portlet, showing all information integratedinto the Virtual Emergency Environment (VEE) byboth static and mobile participants (static and mobiledata sources), at every stage of the process;

• the static Grid layer monitoring portlet (including allthe medical units involved in the static Grid);

• the mobile P2P layer monitoring portlet (including allambulances called for the rescue operation).

The SLP protocol [6] using the multicast mechanism in itsdynamic mode is implemented for discovering mobile ser-vices (see Section 3.2.1), using the grouping and scopingmethods for discovering mobile services with specific roles inthe infrastructure, and retrying schemes for enabling faulttolerance and increasing network stability.

The ambulances (peer nodes in the mobile P2P layer) thatare discovered by the Gateway in the proximity of the sig-naled location of the accident are displayed in the specificmonitoring portlet within the OMU Portal. One or moreambulances can be selected and directed towards the ac-cident site. Figure 4 shows the discovery process and thedisplay of the ambulances within the portal.

The ambulance internal environment (forming a peer groupin the mobile P2P layer) is further displayed as a group-unit (AmbulantaExemplu group unit), showing the mobileentities (peers) discovered - medical devices (MD) and per-sonnel devices (PD) (see Figure 5). The ambulances are rep-resented within the infrastructure by the vehicles ControllerNodes (CN), which play the role of super-peers coordinating

Figure 4: Ambulances discovery and selection, dis-played within the ECC Portal

Figure 5: Ambulance environment: Discovery ofMedical and Personnel Mobile Devices

the respective peer groups, and the role of rendezvous peersin the mobile P2P network.

CN discovers entities and information within the mobile net-work, both from the internal ambulance environment (thepeer group) and from the other ambulances and other mobileentities involved in the operation, and transmits them to theECC Gateway to be integrated into the Virtual EmergencyEnvironment (VEE). It also ensures the communication anddata transmission from the static Grid layer and the Gate-way towards the ambulance environment, disseminating theinformation to the appropriate mobile entities. CN is there-fore a local gateway between the ambulances devices and therest of the mobile P2P network, as well as between the am-bulances devices and the ECC Gateway (bridge layer). Inorder to ensure fault tolerance, in case CN becomes discon-nected from the network, the PD (personnel mobile device)has the capacity to temporary take the coordination andrendezvous roles from the CN (PD temporary becomes thesuper-peer) and continues the critical data transmission be-tween the ambulances devices and the ECC Gateway. OnceCN becomes active again (connected), it automatically re-

covers its super-peer role and continues the communicationwith the other entities within the infrastructure.

The ECC Gateway further interrogates the static Grid in-frastructure in order to discover the Web services represent-ing the medical units involved in the infrastructure. TheWeb services hosting and invocation environment is imple-mented using the WSPeer [24] (see Section 3.2.2), and thedynamic mechanism allows the flexible integration of newmedical units and new fields of expertise (data and knowl-edge resources) within the infrastructure.

The discovery of the required medical units within the staticGrid infrastructure (based on the patient identification dataand the initial diagnosis provided by the ambulance devices)allows the integration within the ECC Portal of informationregarding the medical centers that store the patient healthrecords (data resources) and/or specific expertise for pro-viding consulting to the particular emergency case (knowl-edge resources), as well as emergency medical units thathave available bed space. The information provided by theseunits is further integrated (via the Gateway) into the Vir-tual Emergency Environment (VEE) and displayed in theECC Portal, becoming available to the ambulances.

Finally, based on the decisional process supported by the in-formation integrated into the VEE (initial on-site diagnosis,patient health records discovered, existing/required medicalexpertise, available bed space, as well as the location andtraffic information), the patient is transfered to the medicalemergency unit selected. The Virtual Emergency Environ-ment (VEE) is transfered to the emergency unit representingthe complete file of the emergency operation, the Paramed-ical Emergency Operation is finalized, and the OMU Work-flow is closed. The complete virtual file of the operation -the VEE - can be visualized at the last step of the workflowon the ECC Portal, integrating all the information acquiredduring the entire process.

3.2 Service Discovery and Hosting MechanismsThe OMU package makes use of two underlying toolkits forservice discovery and Web Services hosting:

• SLP (Service Location Protocol) [6]: lightweight stan-dardised discovery protocol for intranet and internets.

• WSPeer [24]: as mentioned, a lightweight Web Servicesframework. WSPeer is used in Triana for invocationof Web services but here we describe how it is used tohost Web Services.

3.2.1 Service DiscoveryService discovery is a process of clients discovering serviceswithin a network. Since the real-world scenario has to becapable of interfacing between fixed and wireless networkedservices that range from being highly dynamic to being morestable, discovery across all of these entities is not straightforward. Further, broker services are required that operateon the edges of these networks in order to provide a hub fora common communication bridge. This scenario thereforeneeds to employ the use of a combination of fixed and ad hocnetwork elements and topologies can be also time varying innature (i.e. ambulances permanently change their location).

Whereas in fixed networks, it is conceivable for a centralisedlookup scheme to work, for the wireless nodes, a fixed schemeis not suitable due to the dynamic nature of the nodesthrough their mobility (i.e. ambulances, traffic officers, andso forth). Therefore, more decentralised Peer-to-Peer rela-tionship need to be formed in order to communicate usinglocalised information (i.e. multi-hop).

Further, discovery has to be scoped or grouped so that whensending out a discovery query is sent out to the network onlythe nodes that are interested in listening to these querieshear them. Such grouping is essential in such P2P networksto not only limit the bandwidth across the network but alsofor security and purposes. In this particular example, we useone level of grouping to group the mobile devices within anambulance (MD, PD), forming a secondary network and al-lowing them to be discovered by the ambulance’s ControllerNode (CN), and the second level of grouping to allow themobile entities within the main network (the ambulances)to discover the main control point, the ECC Gateway (seeSection 3.1, and Figures 4 and 5).

For the discovery of services, there are a number of solu-tions, which are often ingrained into different middlewaresystems. Typically, such approaches employ the use of twocore mechanisms that are used with most systems: multi-cast for dynamic discovery (often limited to sub-networks);and unicast for connection to specific service directories thatcontain look-up tables for the services available on the net-work. In general, service directories are for centralized orfederated lookup tables. Such look-up tables are typicallydiscovered first and then contacted directly to search for thedesired service or services.

The combination of such techniques appear in some formin most of the distributed applications and middleware thatexist today. For example, a service directory: in Jini [3] itis the LUS (lookup server); in a super-peer network it is asuper-peer; in Napster [4], it is the central Napster server;in Jxta [25], it is a rendezvous; in Web services, UDDI [15]may be used as the directory service; and in service discoveryprotocols, such as the Service Location Protocol (SLP) [6],it is called a directory agent (DA).

Often a combination of multicast and unicast are used e.g.in Intranets, an entity could use multicast to auto-detectthe location of a service directory address on the network. Anumber of systems use this approach (e.g., Jxta [25], Jini [3],SLP [6] and so on). An application may also even choose toopt out of using a service directory and simply use multicastto auto-configure connections between clients and servers di-rectly to form direct Peer-to-Peer connections. Further, mul-ticast can be used in either a multicast passive mode (whereservices multicast their service advertisements periodicallyand clients listen for them) or multicast active mode (whereclients multicast their service search requests using queriesand servers listen for them). However, most middleware issimplistic in its approach to multicast discovery and oftenassume an infrastructure environment.

The Service Location Protocol (SLP) [6] allows services tobe deployed and discovered with minimal configuration. It isa predecessor to more widely deployed protocols (e.g., Apple

Rendezvous, ZeroConf, etc) and is one of the few standard-ised protocols for service discovery. SLP provides algorithmsfor network interactions and retrying schemes for enablingfault-tolerant schemes for establishing connections betweenthese entities. It employs the combined use of unicast, multi-cast and directory techniques, as discussed, that can achievedynamic deployment and discovery, while at the same timeminimizing network traffic and increasing reliability.

SLP breaks the deployment and discovery process into threeroles: User Agent (UA) - a service consumer; Service Agent(SA) - a service provider; and Directory Agent (DA) - acache for service advertisements.

Each SLP agent produces and consumes certain types ofmessages, which can also be scoped (like grouping in Jxta[25]) so that messages can be filtered and spontaneous peergroups can be formed. Services can also have attributeswhich are key/value pairs. These can be queried by a UAusing a filter expression. This combination of scopes, at-tributes and service types provides a simple, yet flexiblemeans of describing and querying for services. For our par-ticular scenario, we formed groups using this scoping mecha-nism for in-ambulance dynamic discovery of the components(MD, PD) in the secondary network and for ECC Gatewaydynamic discovery of the components in the main network(ambulances) (see Section 3.1, and Figures 4 and 5). For thisscenario, we used SLP in its dynamic mode using multicastbecause all components were on the local intranet. How-ever, we can easily change this configuration to use directoryservers for wider scale deployments of the OMU toolkit (atthe scale of the real infrastructure).

For the implementation of our scenario we used the SLPprotocol; other systems, such as Jxta [25] and Jini [3], werealso considered but first and foremost, their discovery mech-anisms are simply not robust enough to be applied in a mo-bile setting. For local discovery, they use multicast on a oneoff basis. If services are not discovered for this query thenthey remain not discovered for the session. SLP on the otherhand, employs the use of retrying schemes - a sophisticatedconvergence algorithm that involves a series of exponentiallydecreasing timeouts that retry the discovery process for anadvert by comparing the XID (global identifier) of the re-sponse with previous queries they have sent out. Withoutsuch mechanisms, the P2P discovery process would simplynot work as nodes move around, because nodes will be fre-quently going out of range and loosing their connections, justas we do with our mobile phones. Second, both Jini [3] andJxta [25] enforce proprietary service models for use withineach system. Although there are pluggins for Jxta (JxtaSOAP) [25], that attempt to avoid this, all Jxta protocolstie into this model and it is difficult to use in conjunctionwith certain Web Services stacks. Jini [3] also has no definedmodel for interfacing directly with Web Services in varioushosting environments. SLP provides the ad-hoc discoverythat is essential for P2P dynamic networks but does notenforce any model on the services themselves. Therefore,to discover a Web service, SLP just advertised its endpoint(e.g. http://myservice.com/endpoint) and our externalWeb services toolkit interacts with the discovered servicedirectly. This decoupling of service discovery with connec-tivity is extremely attractive about the SLP model because

you do not have to buy into any one piece of middlewareand its service discovery mechanism.

3.2.2 WSPeer HostingWSPeer [24] [13] provides an environment for hosting andinvoking Web Services. For this implementation, we use itshosting aspect in order to dynamically deploy the MedicalUnits. We envisage that Medical Units and related expertisewill be joining the network on an on-going basis as newexpertise becomes available to the hospitals, shifts change,ambulances move from one center’s range to another, etc.Therefore, to emulate this behaviour we built a dynamicdeployment mechanism for our scenario to illustrate the easeat which further units could be exposed onto the network.

WSPeer allows Web services to be hosted in a container-less environment. This means that to host OMU toolkit wedo not have to have users install heavyweight environmentslike Tomcat, JBoss or so forth. WSPeer runs over HTTPbut it doesnOt enforce a container model on the services itexposes within this environment. This enables Web servicesto be deployed onto a WSPeer container (running locally orremotely) at run-time as no further configuration (settingclaspaths, etc, generating WSDD files, as per Axis/Tomcat)is needed in order to host. An application simply creates aclass that exposes the ports (or methods) for a Web Service,and then deploys this class using the WSPeer deployer ser-vice. Behind the scenes, WSPeer takes the Java class, usesintrospection to extract the methods, convert these methods(through Java to XML serialisation) into XML interfaces,creates a WSDL interface file for these methods and the ser-vice as a whole, including inserting the endpoints, and thenpasses the classfile to the endpoint for deployment. There-after, any invocation of this service would involve the reverseof the process; that is, a SOAP message arrives at the end-point, it would be deserialised to Java objects, and passedas arguments to the back-end Web services implementation,which is simply a Java method that has the same signature.

This model is far more flexibly for such a dynamic envi-ronment that the traditional container Java Servlet stylemodel. It enables new services to be exposed quickly andeasily and without administrative interference. Moreover,WSPeer offers a good combination of dynamic flexibility andsecurity: WSPeer uses SSL on-the-wire security and can in-terface with X.509 certificates for authentication (when de-ploying a service dynamically, a OMU private virtual ad-ministrative X.509 certificate can be used to authorise thedeployment of each new service).

3.3 Triana Workflows EnvironmentThe methodology of workflow is ingrained in many distribu-ted information and communication technologies such asP2P and Grid computing [37] [19], and more recently forCloud computing. There are a number of workflow systemssuch as Triana [38] [12], Kepler [16] [10], Taverna [27] [11],Trident [14], Pegasus [20], ASKALON and so forth.

Workflows define work- or data-dependencies between ser-vices and manage the execution in coordinated steps. Ex-isting workflow systems efficiently link distributed data re-sources, analytical tools and computing processes togetherthrough domain-specific graphs representing work depen-

dencies or information/data flows. Workflow-based applica-tions are therefore increasingly used in domains where inno-vative solutions are needed. Workflows effectively representthe means for sharing the knowledge, processing, communi-cation, storage and content of various tasks across differentdomains. In this context, we assert that workflows, coupledwith the use of service-oriented architecture (SOA) compo-nents, which represent a suitable level of granularity for con-structing flexible and orchestrated distributed data flows inclinical information-processing applications. Such workflowsmust be capable of permitting near real-time operation andemploy the use of a range of computational services.

Triana [12] is an open source problem solving environmentdeveloped at Cardiff University that combines an intuitivevisual interface with powerful data analysis tools. Alreadyused by scientists for a range of tasks, such as signal, textand image processing, Triana includes a large library ofpre-written analysis tools and the ability for users to eas-ily integrate their own tools. Triana has been in this ca-pacity for: radio astronomy, astrophysical simulations, datamining, biodiversity problems, grid-enabled medical simula-tions, environmental science.

Initially funded through the GEO 600 project [23], Trianawas initially created as an intuitive tool for enabling quick-look data analysis of gravitational wave data, an area whereit is still used. Under the GridOneD project [9], Triana wasextended into the distributed computing by creating graph-ically intuitive interfaces and corresponding mechanisms fordistributing its components across Peer-to-Peer (P2P) andGrid computing environments. It is now considered one ofthe pre-eminent workflow tools in scientific distributed com-puting worldwide. The existing Triana Web Services frame-work has been used in a number of international projects forWeb Services composition, such as GridLab [18], DataMin-ingGrid [8], GEMSS [2].

Triana system has the capability to dynamically wrap appli-cations remotely behind Web Services interfaces so that ex-isting software can be easily integrated. WSPeer [24] [13] hasbeen Triana’s Web Services toolkit for the past four yearsand many projects have used this combination to specifytheir distributed course-grained service workflows. WSPeerhas a binding to P2PS enabling Web Services to be hostedwithin decentralised environments. P2PS [39] [5] has beenused as the underlying P2P environment during this timeand it has been successfully used in many domains, suchas gravitational wave analysis, audio processing and dis-tributed music information retrieval (MIR), distributed P2Psimulations and e-health.

Triana workflow environment can integrate within a numberof different distributed environments, bridging the gap for al-lowing true heterogeneous computing across different Gridsand distributed paradigms. Such an approach has led to anumber of different bindings to underlying middleware andtherefore a number of possible modes of operation: it hasfull binding to Java GAT interface, capable of invoking toolsand services such as Condor, GridFTP, GRAM, etc.; it has abinding to the GAP interface, integrating with service-basedmiddleware such as Web Services, WS-RF, Jxta, P2PS.

4. FUTURE WORKAs part of our long-term development strategy of developingportable ’workflow-type’ applications, and in order to extendthe usability of our platform and implementation toolkit, weinvestigate the potential implementation and customizationof our toolkit respond to a series of other practical scenariosthat require mobile distributed infrastructures in the fieldsof healthcare and public defense. Our aim is to provide moreefficient and stable solutions to specific domain problems ascompared to the classic existing infrastructures and to thestate-of-the-art in the fields. This section describes threescenarios we have identified as highly benefiting from thenovel hybrid P2G architecture, that make the candidates forour next implementations. Lastly, our testing and validationplans are presented as our longer-term research goals.

4.1 Application to other domain problems

4.1.1 The Mobile P2G Scenario for Appliance Ag-gregation in Healthcare

We investigated the implementation of our workflow toolkitto support Ambient Assisted Living (AAL) in healthcare,providing novel solutions and an intelligent distributed ar-chitecture for ICT-enabled independent living for elderlyand for disabled people, as well as Personal Health Systems(PHS) to enable self management of diseases and health-care at home by individuals and their families and remotemonitoring of high-risk patients [29] [30].

Such scenarios require a distributed architecture that allowsthe mobile and static integration of devices for enabling re-mote health monitoring and diagnosis. We apply the P2Garchitecture for the integration between the mobile wear-able sensors or portable medical devices (forming the mobilelayer) and the home automation systems (forming the staticlayer). The utilization of a PDA as intelligent point-of-care(POC) supports the integration and the translation from thewearable sensors to personal health assistants (PHA devices)- the PDA enabling for the implementation of lightweightgateway (bridging) technology. Context awareness and am-bient intelligence are considered in order to include environ-mental factors when analyzing data generated by differentsensors, to combine physiological, contextual and environ-mental parameters in a multi-parameter monitoring process.

For this scenario we implement devices/sensors to exposeWeb Services for remote monitoring. Within the P2G ar-chitecture, the P2P (Peer-to-Peer) approach for the designof the mobile layer allows the hosting and interaction withWeb services and WS-RF [26] services within ah-doc P2Penvironments, enabling decentralized (Peer-to-Peer) discov-ery [29]. This approach ensures Web services interactionbetween light-weight devices (with limited functionality andpotentially unreliable), and static high-end machines, so-phisticated computing environments. Moreover, organiz-ing the P2P mobile layer on a peer groups topology withsuper-peers ensures superior QoS and stability by aggregat-ing capabilities such as connectivity or processing power,and supports enforcing security by the implementation ofGroup Membership, Group Identity, Group Services andGroup Policies to build trust relationships between nodesand enforce common policies and services.

We further investigated Workflow solutions for intelligentdata management, integrated data analysis and algorithmsfor multi-parameter correlation and interpretation [30]. Suchintelligent, autonomous systems have the capability to en-sure multi-parameter monitoring, multi-parameter signal pro-cessing, correlation and interpretation of data, in the viewof providing patient self management and support for (per-sonal) decision making. The Triana [38] system for workflowmanagement has implemented the design of lightweight in-terfaces for mobile workflow control and processing. Such aninterface could interact with a Triana engine running else-where, through a secure WS-RF service for authentication,in order to execute the given workflow. To enable work-flow management from mobile devices (designed to run in adisconnected mode) we implement the user interface to beprovided by a mobile device, with the capability of interact-ing with a number of different workflow systems, while theenactment engine can run elsewhere, on high-end machines,independently of the user interface. This allows the execu-tion of the aggregated workflow selected through the userinterface implemented of the mobile device.

4.1.2 The Mobile P2G Scenario for Distributed Man-agement of Medical Images

We also investigated the implementation of the P2G dis-tributed architecture in in the field of medical and biomed-ical imaging, integrating mobile technologies and P2P tech-nologies with distributed Grid infrastructures in the view toprovide mobility to the distributed management of medicalimages. The utility of this scenario is enhanced by the pos-sibility to use mobile radiology equipment in the paramedicsvehicle (for emergency on-site radiology examinations) andin the mobile screening centers (to perform screening ex-aminations in remote locations lacking permanent medicalservices). An important aspect of this scenario consists ofthe discovery, transmission and integration of the medicalimage data sources (both static and mobile) within the dis-tributed P2G infrastructure.

We previously discussed the multy-level Grid infrastructurefor biomedical image management in our papers (see GRIMI- Grid-Enabled Research Infrastructure for Medical Imag-ing [32]), adding a specific layer on top of the generic Gridservices layer for managing image registration, storing andsearch, to answer the common requirements of various appli-cations that make use of medical images and reduce the dis-tance between the generic Grid middleware and the imagingapplications. Further on, we discussed the possible MobileGrid scenarios for medical imaging we had identified (see[34]) and the implementation Workflow technologies to pro-vide mobile distributed management of scientific workflowsfor image registration, manipulation, search, analysis and in-teractive visualization [34]. Finally, we researched into thespecific connectivity requirements between the static Gridnodes and the mobile Grid nodes within the distributed in-frastructure, as well as the specific benefits brought by theintegration with the P2P environments - making it optimalto implement the Peer-to-Grid (P2G) architecture with amulti-level structure (peer groups topology) connecting tothe static Grid infrastructure.

For the mobile workflow management and the implementa-tion of a P2P decentralized search infrastructure for med-

ical images, we analyzed the possibility to integrate the’Alchemist’ multimodal workflow infrastructure we had in-troduced in previous papers [36] [35] with the P2G infras-tructure, in order to provide complex mechanisms for bio-medical images and spectral data search and discovery in dis-tributed databases, based on multimodal search algorithms.The Alchemist framework is a Project at Cardiff Universityfor developing Domain-independent workflows and searchmechanism, built on a generic P2P (Peer-to-Peer) architec-ture with an unstructured super-peers topology. The Al-chemist is based on technologies previously developed atCardiff University (Triana Workflows environment [38], P2PS[39] and WSPeer [24]). It supports: distributed databasequeries and complex search algorithms based on workflowscomposed as a collection of Peer-to-Peer overlays, Grid-basedservices and distributed workflows. It uses industry stan-dards such as Web services and SOAP for messaging. Ituses standardised Web Services interfaces, developed withinthe business and Grid computing communities, and hostedon a Peer-to-Peer (P2P) infrastructure. The system al-ready interfaces with existing Grid middleware (e.g. Globus)through Web Services interfaces. It allows sophisticatedGrid-style security, sign-on, and delegation, in combinationwith specific P2P security aspects like Group services andMembership services. Alchemist framework is extensibleand interoperable, it can be applied to various fields and im-plemented in various distributed scenarios. Scientific work-flow management for image registration, data managementand analysis can be achieved by workflow systems such asTriana [38] that allow integration with mobile devices.

4.1.3 The Mobile P2G Scenario for Military-super-vised Operations in case of catastrophic events

The motivation for the implementation of this scenario camefor the necessity to design a complex intelligent distributedinfrastructure that could respond to crisis situations in caseof catastrophic events in a timely manner, requiring military-supervised intervention teams to operate based on pre-planedintervention procedures (e.g.evacuation strategies from catas-trophic ares) as well as ad-hoc support measures that couldbe implemented on the spot, while maintaining strictly se-cure communication and controlled access to confidential/classified information. The mobile distributed Peer-to-Grid(P2G) architecture, integrating Grid technologies with Mo-bile Agent technology and Peer-to-Peer technologies, ap-pears to be an advanced candidate for such scenario, en-hancing the capacity for timely effective response. The spe-cific requirements of this scenario involve a wide variety ofactors generating real-time data (sensors from distributed lo-cations, multiple integrated maps and localization systems,etc.), multiple operators processing the data, and the ef-fective collaboration of multiple intervention teams such aspublic defence, police force, fire brigade, transportation au-thorities monitoring safety and environmental issues on trans-port through sensitive areas, as well as paramedical teamsand emergency hospitals.

One major component of this scenario addresses the ad-vanced fleet-management services required to cope with suchcrisis situations. We have discussed in our previous pa-pers our architecture and design for an open-source fleet-management system for the monitoring and guidance of ve-hicles based on mobile Grid and P2P technology (see MGFM

- Mobile Grid for Fleet Management [28] [33]) that addressedaspects of innovation vs. state-of-the-art in the areas of: in-teroperability with other systems, availability on a widergeographical area, and integration with onboard equipment.Such system allow the vehicular mobile nodes to monitortheir environment, record changes and react intelligently ina dynamically changing environment (including variationson the availability and Quality of Service (QoS) of accessi-ble mobile data carriers), while the complex distributed in-frastructure could ensure interoperability, dynamic use anddiscovery of resources, ubiquity, composability of services,security, notification, collaborative working, data handling,and remote visualisation.

4.2 Testing and ValidationAs future work and the next step in the validation pathof the proposed architecture, we envisage the developmentof a an advanced Java simulation environment in which themobile distributed Peer-to-Grid architecture could be testedin the context of real existing infrastructures, using real dataand integrating real entities, with the scope of:

• comparing and ranking the stability and efficiency ben-efits of the proposed Peer-to-Grid architecture (and itssecurity infrastructure) vs. the classic architecturescurrently used by those infrastructures;

• testing the interoperability of the proposed architec-ture with the existing software components and appli-cations, and the capacity to integrate with complexnational and international infrastructures.

5. CONCLUSIONSIn this paper we presented the Triana Workflow managementplatform for Paramedical Emergency Operations within anintelligent context-aware mobile distributed Peer-to-Grid in-frastructure. Although we used Triana system for the im-plementation, the underlying OMU toolkit is a stand-alonesystem and the core components are independent of anyworkflow environment. We presented the main functionali-ties of the toolkit for service discovery and hosting, and wediscussed the benefits of the novel hybrid P2G architecturalmodel. Lastly, we discussed our future work and the pathtowards testing and validation.

6. ACKNOWLEDGMENTSThe authors would like to thank to the team at Cardiff Uni-versity, School of Computer Science - Ian J. Taylor, AndrewHarrison, and Ian Kelley - for the consultations regardingthe Triana, WSPeer, and P2PS technologies, as well as fortheir valuable inputs during the common research efforts onthe design of the P2G architectural paradigm.

7. REFERENCES[1] Dynamic Data Driven Application Simulations. See

web site at: http://www.dddas.org/.

[2] The GEMSS Project. See web site at:http://www.ccrl-nece.de/gemss/index.html.

[3] Jini. See web site at: http://www.jini.org/.

[4] Napster. See web site at: http://www.napster.com.

[5] P2PS - Peer-to-Peer Simplified. See P2PS website at:http://www.trianacode.org/p2ps/.

[6] SLP, Service Location Protocol, Version 2. See website at: http://www.ietf.org/rfc/rfc2608.txt.

[7] The AKOGRIMO Integrated Project. Seehttp://www.akogrimo.org.

[8] The DataMiningGrid Project, Data Mining Tools andServices for Grid Computing Environments. See website at: http://www.datamininggrid.org/.

[9] The GridOneD Project. See web site at:http://www.gridoned.org.

[10] The Kepler Project. See web site at:https://kepler-project.org/.

[11] The Taverna Project. See web site at:http://taverna.sourceforge.net/.

[12] The Triana Project. See web site at:http://www.trianacode.org/.

[13] The WSPeer Project. See web site at:http://www.wspeer.org/.

[14] Trident. See web site at:http://www.microsoft.com/mscorp/tc/trident.mspx.

[15] UDDI Spec TC, UDDI Version 3.0.2, September 2004.See web site at: http://uddi.org/pubs/uddiv3.htm.

[16] I. Altintas, C. Berkley, E. Jaeger, M. Jones,B. Ludascher, and S. Mock. Kepler: An extensiblesystem for design and execution of scientificworkSSows. In 16th Inter-national Conference onScientific and Statistical Database Management(SSDBM), IEEE Computer Society, New York, 2004. .

[17] D. Brookshier, D. Govoni, N. Krishnan, and J. C.Soto. JXTA: Java P2P Programming. Sams, March2002.

[18] GridLab: A Grid application toolkit and testbedproject home page: http://www.gridlab.org.

[19] E. Deelman, D. Gannon, M. Shields, and I. J. Taylor.Workflows for e-Science: An overview of workflowsystem features and capabilities. Journal of FutureGeneration Computer System, July 2008.

[20] E. Deelman, G. Singh, M.-H. Su, J. Blythe, Y. Gil,C. Kesselman, G. Mehta, K. Vahi, G. B. Berriman,J. Good, A. Laity, J. C. Jacob, and D. Katz. Pegasus:a Framework for Mapping Complex ScientificWorkSSows onto Distributed Systems. ScientificProgramming Journal, (13 (3)):219–237, 2005.

[21] I. Foster, C. Kesselman, J. Nick, and S. Tuecke. Thephysiology of the grid: An open grid servicesarchitecture for distributed systems integration. OpenGrid Service Infrastructure WG, Global Grid Forum,June, 2002.

[22] G. Fox, D. Gannon, and M. Thomas. A Summary ofGrid Computing Environments. Concurrency andComputation: Practice and Experience (Special Issue),14(13-15):1035–1044, Jan 2003.

[23] GEO 600, July 2005. The GEO 600 project.

[24] A. Harrison and I. Taylor. The Web Services ResourceFramework In A Peer-To-Peer Context. Journal ofGrid Computing, 4(4):425–445, December 2006.

[25] Project JXTA, July 2005. http://www.jxta.org.

[26] Karl Czajkowski et al. The WS-Resource framework,March 2004.

[27] T. Oinn, M. Greenwood, M. Addis, M. N. Alpdemir,J. Ferris, K. Glover, C. Goble, A. Goderis, D. Hull,D. Marvin, P. Li, P. Lord, M. R. Pocock, M. Senger,

R. Stevens, A. Wipat, and C. Wroe. Taverna: Lessonsin creating a workflow environment for the lifesciences. Concurrency and Computation: Practice andExperience, special issue on Grid Workflow,(18):1067–1100, 2006.

[28] V. Patriciu, A. Riposan, E. Mieilica, I. Taylor,A. Harrison, and I. Kelley. Mgfm - mobile grid forfleet management. In Communications 2006,Bucharest, Romania, June 9, 2006.

[29] A. Riposan. Appliance aggregation scenarios forhealthcare, ambient assisted living and patient riskmanagement. In GW-GGF18, APPAGG Workshop,Washington DC, USA, September 14, 2006.

[30] A. Riposan, A. Harrison, and I. Taylor. Comments atconsultation workshop on personal health systems: thepath from fp6 to fp7, February 2006.

[31] A. Riposan, A. Harrison, I. Taylor, I. Kelley, andE. Mieilica. Mobile peer-to-grid architecture forparamedical emergency operations. In Challenges andOpportunities of HealthGrids, Proceedings ofHealthGrid 2006, IOS Press, Valencia, Spain, June6-9, 2006.

[32] A. Riposan and V. Patriciu. Grimi, grid-enabledresearch infrastructure for medical imaging. In ModernTechnologies in the XXI Century, Bucharest,Romania, November 2005.

[33] A. Riposan and V. Patriciu. Mobile gridinfrastructure, a proposal for a MTA integratedproject. In Modern Technologies in the XXI Century,Bucharest, Romania, November 2005.

[34] A. Riposan, I. Taylor, and Y. Legre. Identifyingmobile grid scenarios for medical imaging applications.In MIE 2006, Poster Session - Decision Support,Knowledge Representation and Management,Maastricht, The Hague, August 28-30, 2006.

[35] A. Riposan, I. Taylor, D. R. Owens, and E. C. Conley.A new paradigm in biomedical data discovery andmultimodal workflows. In IJCCC journal, Proceedingsof EMMIT 2007 (Euro-Mediterranean MedicalInformatics and Telemedicine), Mangalia, Romania,May 3-5, 2007. www.emmit2007.net.

[36] A. Riposan, I. Taylor, D. R. Owens, O. Rana, andE. C. Conley. Alchemist multimodal workflows fordiabetic retinopathy research, disease prevention andinvestigational drug discovery. In Stud Health TechnolInform. 2007, Proceedings of HealthGrid 2007, IOSPress, Geneva, Switzerland, April 24-27, 2007.http://geneva2007.healthgrid.org.

[37] I. J. Taylor, E. Deelman, D. Gannon, and M. Shields.Workflows for e-Science. Scientific Workflows forGrids. Springer, 2007.

[38] I. J. Taylor, M. Shields, I. Wang, and A. Harrison.Visual Grid Workflow in Triana. Journal of GridComputing, (3(3-4)):153–169, September 2005.

[39] I. Wang. P2PS (Peer-to-Peer Simplified). InProceedings of 13th Annual Mardi Gras Conference -Frontiers of Grid Applications and Technologies, pages54–59. Louisiana State University, February 2005.

[40] B. J. Wilson. JXTA. New Riders Publishing, June2002.