s. masoud yideng floridainternational university, 8th

Automatic Generation of User-Centric Multimedia Communication Services

Raju Rangaswami, S. Masoud Sadjadi, Nagarajan Prabakar, Yi DengFlorida International University, 11200 SW 8th Street, Miami FL, USA 33199

traju, sadjadi, prabakar, deng}(,csfiu. edu

Abstract

Multimedia communication services today areconceived, designed, and developed in isolation,following a stovepipe approach. This has resulted ina fragmented and incompatible set of technologiesand products. Building new communication servicesrequires a lengthy and costly development cycle,which severely limits the pace of innovation. In thispaper, we address the fundamental problem ofautomating the development of multimediacommunication services. We propose a newparadigm for creating such services throughdeclarative specification and generation, rather thanthrough traditional design and development. Further,the proposedparadigm pays special attention to howthe end-user specifies hislher communication needs,an important requirement largely ignored in existingapproaches.

1. Introduction

In recent years, we have witnessed a great increasein the number and variety of multimediacommunication services that have been developedand deployed. Examples range from IP telephony,instant messaging, video conferencing, multimediacollaboration, to specialized communicationapplications for telemedicine, disaster management,and scientific collaboration. Given the ease ofcreation of multimedia data, the continuousimprovements in network capacity and reliability, andthe varying and changing communication needs ofend-users, it is likely that the pace of innovation inmultimedia communication services will acceleratefurther.

Although this trend presents a tremendousopportunity for technological growth and forimproved end-user experience, current approaches fordeveloping multimedia communication services areseverely lacking in several respects. Multimediacommunication services today are conceived,

designed and developed following a stovepipe(vertical) approach that has resulted in a fragmentedset of incompatible tools, technologies, and products.In addition, there is limited separation betweenapplication logic, the communication requirements,underlying platform specifics, and the networkingprotocols and infrastructure. The fragmenteddevelopment approach also poses a great challenge inproviding integrated multimedia communicationservices. Users are forced to hop between tools tosatisfy their communication needs since the currentsuite of multimedia communication tools aretechnology-centric and largely ignore user-specificcommunication needs.We argue that the root causes for holding back

rapid innovation in multimedia communicationservices are the lack of user-centric developmentalapproaches, combined with stovepipeimplementations. In this paper, we investigate a newparadigm for developing and deploying multimediacommunication services through specification andautomatic generation, rather than through traditionaldesign and development. This paradigm advocates amodel-driven process for conceiving and deliveringmultimedia communication that is tailor-made to fituser or application needs. Both general-purpose anddomain-specific communication needs are specifiedin a model, called communication schema, which isindependent of device types and underlying networkconfiguration. This model is instantiated, negotiated,synthesized, and executed, by a fully automatedprocess, to satisfy user communication needs. Usingthis approach, multimedia communication servicescan be built within hours or days, rather than monthsor years as required by current development cycles.

The focus of this paper is the automatic generationof user-centric multimedia communication servicesfrom communication schema descriptions, whichallows changing the communication schema (orrequirements) as required by the user or application atrun-time. We refer to our automatic service generatoras the synthesis engine. In contrast to general-

1-4244-1338-61071$25.00OI2007 IEEE 324

Authorized licensed use limited to: FLORIDA INTERNATIONAL UNIVERSITY. Downloaded on September 1, 2009 at 17:19 from IEEE Xplore. Restrictions apply.

purpose, model-driven application development [12],here we focus on automatic synthesis for multimediacommunication. Our preliminary study suggests thatautomated synthesis is largely feasible at least for thefunctional aspects of the communication such ascoordination of communication features andcapabilities and media delivery.

The contributions of this paper are as follows:1. We propose a new paradigm for developing

multimedia communication services through amodel-driven, specification and automaticgeneration process.

2. We explore the scope of the automatic synthesis,given a declarative specification ofcommunication needs, and show synthesis isfeasible for the domain of user-centriccommunication services.

3. We present the automatic synthesis process,including algorithms for communication schemapopulation, schema negotiation, and codegeneration.

4. We evaluate our proposed approach using aconcrete case study of multimediacommunication used in telemedicine.

The rest of this paper is organized as follows.Section 2 provides an overview of theCommunication Virtual Machine (CVM), acomprehensive architecture that enables the proposedparadigm Section 3 presents context for theautomated generation process. Section 4 details theactual synthesis process as carried out by thesynthesis engine. In Section 5, we present anevaluation of the proposed approach using aprototype that we have developed. Section 6 presentsrelated research and we make concluding remarks inSection 7.

2. Communication Virtual Machine

To better understand the role of Synthesis, wepresent it in the context of the Communication VirtualMachine (CVM [6]), a comprehensive architecturefor realizing communication services using theparadigm of specification and automatic generation.

The design of CVM draws from the concepts ofmodel-driven engineering [12] and middleware-basedarchitecture [8, 11]. However, by focusing on thecommunication domain only, CVM avoids the pitfallsof many general-purpose methods and techniques formodel-driven engineering that are overreaching andconsequently less effective.

The model-driven communication mentionedabove is supported by the CVM layered architecture(Figure 1). These layers are common to and shared by

different communication applications. Thisarchitecture separates and encapsulates majorconcerns of communication modeling, synthesis,coordination, and the actual delivery of thecommunication by the underlying network anddevices, into self-contained compartments with clearinterface and responsibility.

User/ Application (Initiator) User/ Application (Initiator)

Communication Network Communication Network

Figure. 1. Layered CVM architecture

The CVM architecture divides the majorcommunication tasks into four major levels ofabstraction, which correspond to the four keycomponents of CVM:1. User Communication Interface (UCI), which

provides a language environment for users tospecify their communication requirements in theform of a user communication schema or schemainstance

2. Synthesis Engine (SE), which is a suite ofalgorithms to automatically synthesize a usercommunication schema instance to an executableform called communication control script;

3. User-centric Communication Middleware(UCM), which executes the communicationcontrol script to coordinate the delivery ofcommunication services to users, independent ofthe underlying network configuration; and

4. Network Communication Broker (NCB), whichprovides a network-independent API to UCMand works with the underlying network protocolsto deliver the communication services.The four layers collectively fulfill the promise of

CVM - that of generating communicationapplications that are reconfigurable, adaptive, andflexible based only on a high-level description ofcommunication requirements. In this paper we onlyfocus on the automated schema synthesis process thattransforms a declarative user communication schemainstance (provided by the UCI) to an imperativecontrol script (to be executed by the UCM).

325


3. The Context for SynthesisIn this section, we elaborate on two key concepts

that help realize the CVM architecture when used incombination with the synthesis engine:communication modeling language and user-centriccommunication middleware. Note that these conceptsare discussed elsewhere in detail [4,6]; we outlinethem here only for completeness.

3.1. Communication modeling language

The user-centric communication configuration andattributes (communication schema instance) arespecified by the end user using a declarativecommunication modeling language (CML), in agraphical user environment [4]. This schema instanceis represented as a modified ER diagram [3]. TheUCI layer validates the user communication schemainstance for syntax and semantics correctness andgenerates an XML specification of thecommunication schema instance that is processed bythe synthesis engine. The UCI layer also processescall backs from the synthesis engine and notifies theuser via the graphical user environment.

To illustrate the basic features of CML and therealization of the layered approach of the CVM, wepresent the following telemedicine communicationscenario that takes place in an operating room.During a surgery of a patient Davis, Dr. Adams(surgeon) initiates a communication session with Dr.Brown (referring physician of Davis) and shares theechocardiogram and MRI images of the patient byinteractively creating a communication schemainstance with a voice activated browser. During thissession, Dr. Brown wants to consult a cardiologistand includes Dr. Conway in the schema. Dr. Adamsfeeds a live video of the surgery to the

communication session and sends a structured vitalsign chart (text data). This facilitates the discussionamong all three and Dr. Adams performs successfulsurgery with the agreement of Dr. Brown and theconsultation of Dr. Conway. Figure 2 presents a moreeasily interpretable graphical view of the same. Bothviews and corresponding interfaces for creation andmodification are currently implemented in ourprototype.

3.2. User-centric communication middleware

The UCM layer is responsible for executing thecommunication control script generated by theSynthesis Engine, for maintaining the states of userlevel communication (as opposed to network level),and for performing a safe state transition from acurrent running script to an updated one. The currentstate of a running script encapsulates its "programcounter", communication logs, data alreadyexchanged, data in transition, and so on. In otherwords, UCM manages user communication sessions.

For the telemedicine communication scenariointroduced above, the script generated by thesynthesizer in response to the scenario initiated by Dr.Adams is as follows:

createSession("ID");addParty("ID", "Dr. Brown");addMedia("ID", "image", <URL>);addMedia("ID", "audio", <URL>);

where the <URL>'s are replaced by their resolvedvalues for the actual locations of the MRI imageryand echocardiogram of the patient. The above scriptis delivered to the UCM for execution and the actualdelivery of communication will eventually beperformed by the NCB layer.

Vital signs(text data)

Figure 2. Graphical view of the schema instance (local view of Dr. Adams)

326


Finally, the UCM also provides feedback synthesisengine. For instance, it reports the change of sessionstatus to the SE so that necessary modifications canbe made to the schema.

4. Synthesis EngineThe synthesis engine (SE) automatically

transforms a declarative user communication schema(specified using the CML) to an imperativecommunication control script for deployment on theUCM. The SE is defined by its algorithms, processes,and techniques, which are used to generate thecommunication control scripts. These control scriptsrepresent the network-independent control logic foruser-level communication sessions.

The key challenge for the SE is completeautomation, free of human intervention. With fullyautomatic synthesis, communication services can begenerated from declarative user communicationschema instance. The key question then is whethersuch an automated transformationlsynthesis ispossible when automated program generation fromdeclarative models for general-purpose systems isstill beyond our reach? We argue that for a limitedsubset of communication applications, suchautomation is feasible. Our preliminary studysuggests that automated synthesis is largely feasiblefor the domain of user-centric multimediacommunication services at least for the functionalaspects of the communication such as coordination ofcommunication requirements and capabilities as wellas media delivery.

Given the role of the SE, we identify the followingtasks it must perform:1. Probe the local environment to align needs with

communication capabilities and constraints andalso determine the need for negotiation.

2. Ensure the consistency of user communicationschema across participating end-points in acommunication session.

3. Perform schema synthesis to obtain thecommunication control script to be deployed onthe user-centric communication middleware.Of the above tasks, #1 and #2 may involve

handling exceptions and/or error conditions, whichmay require user-feedback for resolution. Therationale for designing the SE is to automate thehandling of such exceptions and to employ userfeedback only when unavoidable. We elaborate onthis aspect in Sections 4.2 and 4.3.

The design of the SE follows a three-stageprocess: (1) schema population, during which the SEprobes the environment to determine and account forlocal device communication capabilities and to

handle communication constraints, (2) schemanegotiation among participants of communication, todetermine the feasibility of the desiredcommunication and to ensure that all parties agree toa consistent communication schema, and (3) schemasynthesis, during which the SE determines the needsof communication and automatically transforms theschema to a communication control script deployableon a user-centric communication middleware.

Figure 3 depicts the architecture of the SE. Thearrows depict control flow. We use the genericlayered architecture proposed by Hill et al. [9] for theTinyOS platform, for interfacing with the CML(above) and UCM (below) layers. The acceptsinterface allows invocation of the SE with acommunication schema instance. The SE interpretsthe schema, determining if there is a need for schemanegotiation. If yes, the schema negotiation process isstarted; else, the SE proceeds to synthesize theschema instance, invoking the SE uses interface withthe synthesized communication control script. Ifnegotiation was invoked, the schema instance is firstnegotiated with all communication end-points (asspecified in the schema instance) prior to synthesis.Finally, the SE contains an event handler for externalnegotiation requests, media progress/deliverynotifications, and exceptions. Such handling mayinvolve re-negotiation or user notification/feedback.

Figure 3. Synthesis Engine architecture.Arrows depict control flow.

4.1. Schema population

The communication schema instance is adescription of user communication needs in terms ofthe desired mode(s) of communication, remoteparticipants, as well as the specific information thatmust be communicated. The first step in synthesizingthe desired communication is schema population,

327


which probes the local environment to aligncommunication needs with local device capabilitiesand constraints. Schema population also the need tonegotiate communication parameters with remoteparticipants involved in the communication.

Schema population augments the communicationschema instance with the communication capabilitiesof the local device such as the media types supported,including specific format (or sub-type) information(e.g., real-media format of type video). The capabilityinformation is further enriched with type-specificinformation such as resolution and frame-rate ofvideo or the bit-rate of audio supported. Thepopulated schema instance is then aligned with thecommunication needs declared in the schemainstance, employing user-feedback to resolveinconsistencies, if any. The populated schemainformation is also used in the schema negotiationstage (described next) to align the capabilities of allparticipants involved in the communication.

The need for schema negotiation arises the firsttime a communication is initiated and whenever thereis a modification to the current communicationschema instance. Specifically, it is required in thefollowing scenarios: (a) the initiator of a newcommunication instantiates the corresponding schemawith remote participant information for the first time,(b) a participant in an ongoing communication addsor deletes a participant, and (c) a participant in anongoing communication adds/deletes a medium typeto the current schema.

Addition or deletion of a participant requires re-negotiation to inform other participants of the changeas well as to accommodate the communicationcapabilities of the new set of participants. Addition ordeletion of a medium type requires renegotiation toconform to the capabilities and preferences of thecommunicating participants. Note that the addition ofa new instance of a medium-type (e.g. sending audio-file myfile.mp3) does not require renegotiation as thisaddition will occur only after the "audio" medium-type has been negotiated. No new capabilities arerequired of the end participants.

4.2. Schema negotiation

Schema negotiation is required to determine thefeasibility of the desired communication and toensure the consistency of the communication schemainstance across the participating end-points in a user-communication session. A communication schemainstance defined by user A may require a videoconnection to user B. However, if B's device is notcapable of video communication, this communicationis not possible. Second, even if B's device were

capable of video communication, B herself may notwish to engage in video communication with A at thattime. In a multi-party communication scenariobetween A, B, and C, as initiated by A, C may notwish to communicate with B. Negotiation of theschema instance is required to understand theoperating environment for the communication as wellas to account for user preferences in communication.Apart from negotiating the initial schema instancebefore actual communication starts, schema re-negotiation may also be required when acommunication session is in progress.We now describe our approach for schema

negotiation used for negotiating the initialcommunication schema instance as well asperforming renegotiation. Each participant in acommunication session has a local copy of theschema instance, which they may change at runtime.Any change to the schema made locally may requirean update to the local schema instances at allparticipating end-points. If two users in a session aresimultaneously altering their schemas, concurrencyproblems arise. The synthesis engine uses a modifiednon-blocking three-phase commit protocol [15] forschema synchronization.'

Each schema instance change initiates anegotiation process, which proceeds in three distinctphases. The final phase is the commit phase.

Phase 1: The initiator reports the requestedchange to the schema instance to all remoteparticipants, including any new participants beingadded, by sending the desired schema instance.

Phase II: The remote parties receive the changesand append their own un-committed changes, if any,to the schema instance. If this is the first time aschema instance is being negotiated or in case newparticipants are being added, the new participantsalso declare their device capabilities in the schemainstance. Each remote participant sends this modifiedschema instance to the initiator.

Phase III: After the initiator receives the responsesfrom all participants, all modifications from remoteparticipants are merged. If the new schema instancediffers from the original intent of the initiator, userfeedback is employed to authorize thecommunication. The initiator then sends a finalconfirmation, either in the form of a consistentschema instance to be used for communication or tocancel the session.

This option was favored over synchronization using a distributedlock, which disallows parallel schema instance modification.Further, distributed locking protocols are not robust to unstablenetwork connections.

328


Since multiple parties may initiate schemanegotiation simultaneously, negotiation requests fromremote parties are queued together with the locallygenerated negotiation requests in a synchronizednegotiation request queue. These requests arehandled in order to ensure the consistency of theappend operations described above.

4.3. Schema synthesis

As shown in Figure 3, the schema synthesisprocess is invoked either directly after schemapopulation or after negotiation. Irrespective of thepath taken, the schema synthesis process is the same.Its purpose is to transform the declarativecommunication schema instance into an imperativecommunication control script, executable on the user-centric communication middleware (see Section 3.2).An XML schema for a communication session

defines all device types and device instances that arepart of the session, followed by the attributes of allparticipants, and the association between participantsand device instances in the session. The synthesisalgorithm is as follows:1. Obtain the difference between the current XML

schema instance and the previous (alreadysynthesized) schema instance. If no previousschema instance exists, the entire new schemainstance is used as the difference.

2. Augment the difference XML with contextinformation including session ID and connectionID for each new entity (e.g., new participant ornew medium instance), if absent. Now thedifference XML is composed of one or moreconnection blocks.

3. Create an empty communication control script.For each connection block in the difference XML,(i) for each connection, if this connection did notexist in the previous version of the schema, add tothe script a command to create a new session thatimplements this connection, (ii) for eachparticipant, add to the script a command foradding a participant to the corresponding session,and (iii) for each medium instance, add to thescript a command for adding the medium instanceto the corresponding session.

4. Dispatch the communication control script to theUCM layer.The XML schema of any communication session

defines all devices, persons, and associations of thesession, in sequence as a tree. As the synthesisalgorithm processes the XML document as describedabove, it is evident that code for all features of thecommunication session will be generated.

4.4. Event handler

The synthesis engine architecture consists of anevent handler (Figure 3) for handling eventnotifications from lower layers. These events caneither be system notifications, exceptions, or errorconditions. The event handler, dispatches the event tothe appropriate handler. Remote negotiation requestsare dispatched to the negotiation handler by addingthem to the synchronized negotiation request queue(described in Section 4.2). Exception conditions suchas loss of communication with a specific participantor temporary loss in network connectivity aredispatched to the exception handler, which may eitherinitiate a re-negotiation request to handle theexception or intimate the user via the UCI layer if theexception cannot be handled internally due to schemainstance-specific constraints. Finally, communicationstatus updates such as the amount of progress inmedia delivery are directly notified to the UCI layer.

The synthesis engine delivers four types ofnotifications to the UCI layer. The notifyMediaStatusand notifyParticipantStatus signals notify the UCIabout media delivery and participant connectivity.The notifySIStatus signal notifies the UCI aboutchanges to the schema instance as a result of externalchanges due to other participants such as addition ofnew participant to an existing session or a change incapabilities of an existing participant, etc. Finally, thenotifyException signals the UCI about exceptionssuch as lost network connection, when it cannot behandled internally.

5. Evaluation

To evaluate the effectiveness of the synthesisengine, we incorporated a prototype of synthesisengine into the CVM implementation [6]. The CVMuses the Opera 8.5, a voice-enabled browser, thatenables creation, modification, and use ofcommunication schema instance using voicecommands. The synthesis engine prototype and thelower layers are implemented in Java, deployed oneach node. JAIN SIP and Java Media Framework(JMF) are used for control and data communications,respectively. The current prototype propagatescommunication errors to the user. A future extensionwould be to add internal handling (obliviously to theuser) of a subset of exceptions.

5.1. Reduced development time

We now obtain an estimate of the reduction indevelopment time (and consequently, developmentcost) using the automatic synthesis approach. To doso, we used the open source Jabber chat application,

329


and also ourselves developed two Java-basedapplications that provided person-to-person voicecall, and person-to-person video communicationservice respectively. These implementations usedJMF and JAIN-SIP technologies. Table 2 summarizesthese applications, their code sizes in lines of code(loc), their estimated development time using thetraditional approach, and also shows the approximatespecification and synthesis time for generating theseapplications using the CVM prototype. To estimatethe development time by a trained programmer, weused the study of Ferguson et al. [7], whose findingsreveal approximately 2500 lines of code per monthper programmer. These numbers demonstrate thesignificance of our approach. Service creation time isreduced by several orders of magnitude. Even if weassume that only 25% of the code contributes to thefunctional aspects of the software, improvements indevelopment time are still over two orders ofmagnitude. Further, the automated process introducesfewer bugs into the code-base, improving softwarereliability. This underlines the importance of usingautomated processes for synthesizing communicationapplications rather than follow traditional design anddevelopment.

5.2. Synthesis engine

To evaluate the time required for the actualsynthesis process, we deployed CVM to 7 machines(desktops and laptops) in a combination of wired andwireless local area network. Ten demo users werecreated and used to represent 7 users communicatingwith each other

To verify the correctness of the synchronizationprotocol within the negotiation process, we initiatedsimultaneous modifications to the schema instance atdifferent sites and verified the absence of anyinconsistencies in the schema instances at the variousend-points automatically over numerous iterations.

In addition, we instrumented the synthesis engineto obtain the time required to perform schemasynthesis The plot in Figure 5 shows the average timein seconds required for synthesis including the

negotiation/renegotiation stages when there are 2 to 7participants present in a communication session. Theresults of these experiments show that the synthesisprocess scales linearly with the number ofparticipants, and the process itself is dominated bythe schema negotiation time. Higher numbers are notdepicted due to lack of experimental infrastructure;however, we do not envision any issues limiting thelinear scaling for larger participant-sets. Theexperiment demonstrates the practicality of schemasynthesis process with a distributed negotiationalgorithm; the negotiation time, which dominates theoverall synthesis time incurs an acceptable delay.

6

e)'a

._

0

0a)

E

._4

a)

cn

5

4

3

2

00 1 2 3 4 5 6 7 8 9 10 11

Number of Participants

Figure 5: Average time required fornegotiation.

6. Related Work

The CVM approach shares some common traitswith the concept of model-driven engineering [2, 8,12]. In contrast to general-purpose model-drivendevelopment, automatic generation of communicationservices is feasible in CVM for two reasons. First,CVM is restricted to the scope of communicationservices and does not bear the complexity of

Table 2. Reduced development time compared to traditional design and development.

Application Type Application loc Est. development time Spec/ Synthesis Time

Multi-user Text chat Jabber-1.4.2 5528 2 months <5 minutes

Person-to-person voice call Custom 9478 4 months < 5 minutes

Person-to-person video comm. Custom 16784 7 months < 5 minutes

330

1


generating general-purpose applications. Thecomplexity of communication logic can be carefullyregulated through the design of the schema modelinglanguage. Second, CVM utilizes communicationmiddleware components (e.g., those of ACE [14])and server-side architectures (e.g., [1]) as buildingblocks to generate communication applications. Suchexisting components encapsulate procedures,patterns, and algorithms governing basiccommunication services (e.g., session establishmentof person-to-person voice call, transmission of animage file, and real-time video streaming), which arewell understood. The role of CVM is limited to theidentification and composition of such components[10].

Heckel and Voigt [8] describe how models inUML are transformed into BPEL4WS using theconcept of pair grammars. We use a similar approachin the UCI but our modeling language G-CML is farmore restrictive than UML and hence far moremanageable and its synthesis can be automated.

The work in [2] generates code from models usingtool suites for specific application domains that weredeveloped using a generic modeling environment.Examples of other approaches to code generationfrom higher-level specifications and languagesinclude domain-specific languages, generativeprogramming, generic programming, constraintlanguages, feature-oriented development, and aspect-oriented programming [5]. In our work, a generic SEgenerates control scripts from a CML description ofcommunication logic, with restricted utility to thecommunication domain.

7. Conclusions

We have presented a new paradigm for providinguser-centric multimedia communication servicesthrough declarative specification and automaticgeneration, rather than through design anddevelopment. Specification is simplified byidentifying the key features of multimediacommunication from a user's perspective, which arethen captured in an XML-based communicationmodeling language (CML) definition. Our prototypefurther simplifies specification by providing a simplegraphical interface. Automatic generation is madepossible by a systematic three-step process of schemapopulation, schema negotiation, and schemasynthesis, combined with an event handler that allowsthe automatic handling of system events, exceptions,

and error conditions. The proposed paradigm enablesthe rapid creation of multimedia communicationservices, a core necessity in sustaining and improvingthe pace of innovation in this domain.

References[1] G. W. Bond, E. Cheung, K. H. Purdy, P. Zave, and J.

C. Ramming, "An Open Architecture for Next-generation Telecommunication Services", ACMTransactions on Internet Technology IV(1) pp:83-123,February 2004.

[2] K. Balasubramanian, A. Gokhale, G. Karsai, J.Sztipanovits, and S. Neema "Developing ApplicationsUsing Model-Driven Design Environments", IEEEComputer, pages 33 - 40, February 2006.

[3] P. P. Chen. "The Entity-Relationship Model: Toward aUnified View of Data", ACM Trans. Database Syst. 1,1, 9-36, 1976.

[4] P. J. Clarke, V. Hristidis, Y. Wang, N. Prabakar and Y.Deng. "A Declarative Approach for Specifying User-Centric Communication", Symposium onCollaborative Technologies and Systems (CTS), 2006.

[5] K. Czarnecki and U. Eisenecker. "GenerativeProgramming", Addison Wesley, 2000.

[6] Y. Deng, M. Sadjadi, P. Clarke, C. Zhang, V. Hristidis,R. Rangaswami, and N. Prabakar. "A CommunicationVirtual Machine", IEEE COMPSAC, September 2006

[7] P. Ferguson, W. S. Humphrey, S. Khajenoori, S.Macke, and A, "Matvya. Results of Applying thePersonal Software Process ", IEEE Computer 30(5) pp24-3 1, May 1997.

[8] R. Heckel and H. Voigt. ,,Model-based Developmentof Executable Business Processes for Web Services",LNCS vol. 3098, pages 559-584. Springer, Jun. 2004.

[9] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, K.Pister. "System Architecture Directions for NetworkedSensors", In ASPLOS, pp. 93-74, 2000.

[10] P. K. McKinley, M. Sadjadi, E. P. Kasten, and B. H. C.Cheng. "Composing Adaptive Software", IEEEComputer, pages 56-64, July 2004.

[11] D. C. Schmidt. "Middleware for Real-time andEmbedded Systems", Comm. of the ACM, 45(6), June2002.

[12] D. C. Schmidt, "Model-Driven Enginering", IEEEComputer, February 2006, 25-31.

[13] D. C. Schmidt. "Applying Patterns and Frameworks toDevelop Object-Oriented Communication Software",volume 1 of Handbook of Programming Languages.MacMillan Computer Publishing, 1997.

[14] D. C. Schmidt and S. D. Huston, "C++ NetworkProgramming: Mastering Complexity Using ACE andPatterns", Addison-Wesley Longman, 2002.

[15] D. Skeen, "Nonblocking Commit Protocols", pages133-142, SIGMOD 1981.

331


s. masoud yideng floridainternational university, 8th

Documents