CERC Technical Report Series Technical Memoranda CERC-TR-TM-95-002 MEDIAWARE : A DISTRIBUTED MULTIMEDIA ENVIRONMENT WITH INTEROPERABILITY Yahya Y. Al-Salqan April 1995 Proceedings of the Fourth IEEE Workshop on Enabling Technologies : Infrastructure for Collaborative Enterprises . Los Alamitos , CA : IEEE Computer Society Press , 1995 . Concurrent Engineering Research Center West Virginia University P.O. Box 6506 , Morgantown , WV 26506 1 MediaWare : A Distributed Multimedia Environment with Interoperability Yahya Y. Al-Salqany , Carl K. Changz yConcurrent Engineering Research Center West Virginia University Morgantown , WV 26506-6506 E-mail : alsalqan@cerc.wvu.edu zDepartment of EECS -LRB- M/C 154 -RRB- University of Illinois at Chicago Chicago , IL 60607 Abstract MediaWare is a distributed multimedia environment based on state-of-the-art distributed object computing standards as specified by CORBA . MediaWare enhances interoperability among media objects through the interoperable virtual connection protocol . MediaWare provides an infrastructure for building interactive multimedia applications that support synchronized , time-based media in a heterogeneous , distributed environment . This paper discusses MediaWare 's architecture and its object life cycle . MediaWare 's architecture includes an application layer ; a quality-of-connection layer , which is an aggregation of the quality-of-service in addition to the user 's interaction and synchronization requirements ; an interoperable virtual connection protocol layer ; an objects database including the interoperable database layer ; an object request broker layer ; an interface definition language -LRB- IDL -RRB- mapping layer ; and finally , an object implementation layer . The paper includes examples to show MediaWare 's power to generate several multimedia teleorchestrations and scenarios . 1 Introduction Distributed multimedia communication and applications is an interdisciplinary field that encompasses behavioral science , computer science , and electrical engineering . Applications of multimedia in medicine , education , travel , real estate , banking , entertainment , and advertising are emerging at a fast pace . Unfortunately , most multimedia applications were developed around the desktop paradigm -LRB- e.g. , multimedia titles -RRB- , which focus on publishing and distribution . The major challenge to put multimedia applications into effect , which will serve the growing population , is to adopt the distributed paradigm -LRB- e.g. , network access -RRB- . In the distributed paradigm , the temporal requirements are more stringent , and getting the data on-demand across networks -LRB- local-area or wide-area -RRB- is more challenging . In a distributed multimedia environment , resources and presentation materials on any system may be used remotely . In addition , users should be able to use multiple multimedia applications and resources to accomplish their tasks . According to Interactive Multimedia Association -LRB- IMA -RRB- -LSB- HIS93 -RSB- , the key elements of the multimedia environment are as follows : 1 . Access to distributed multimedia resources . The multimedia environments may consist of wide interconnections on networks -LRB- LAN , WAN , MAN -RRB- . The multimedia environment should provide abstractions that can hide the variety of network topologies and protocols . 2 . Interactive multimedia . The user is provided with real-time control and interaction of time-based media . 3 . Synchronized media . This includes two types of synchronization : ffl Intra-Stream Synchronization , which is concerned with delivering each media object on time to meet the respective playout deadline . ffl Inter-Stream Synchronization , which deals with temporal relationships which may exist between two or more objects , such as video and audio objects . 3 4 . Heterogeneous platforms and equipment . In a distributed multimedia environment , it is rare that all equipment used is identical . In order to make the multimedia environment effective , multimedia sources and destinations must be able to interoperate in spite of the heterogeneity of hardware and communication protocols . 5 . Capability of addressing a broad range of applications , such as : ffl applications that access and handle live and stored data remotely . ffl applications that handle multiple kinds of data simultaneously . ffl a single application that reaches multiple users concurrently . ffl allowing a single user to use multiple applications concurrently . In order to achieve some of the above features of distributed multimedia applications , a wide range of research methods and tools are under investigation and development -LSB- RKGB92 , AE92 , Cla92 , Leo92 , KHS92 , BHI93 , RVR92 , RR93 , RR92 , RRV92 , RVK92 , Kje91 , VRC92 , OSKQ90 , LBea90 , Ste90 , Nic90 , HLMS93 -RSB- . Very little research , however , has been done on multimedia interoperability and the required software architecture . The efforts of the Interactive Multimedia Association -LRB- IMA -RRB- are significant in establishing the framework of such an architecture . In their response , IBM , HP and SunSoft describe their architecture to Multimedia System Services -LRB- MSS -RRB- -LSB- HIS93 -RSB- . The Multimedia System Services -LRB- MSS -RRB- specification and architecture supports distributed multimedia applications without interoperability . Our MediaWare , as an enhancement to the MSS , adds the interoperability feature to the multimedia applications . This enriches the multimedia environment to support dynamic creations of distributed multimedia scenarios . In this paper , we will review the MSS in detail and introduce MediaWare 's architecture . Section 2 details the MSS architecture . Section 3 presents the MediaWare 's object life cycle . Section 4 presents MediaWare 's architecture as a multimedia environment with interoperability ; MediaWare 's scenario generation capability is discussed in Section 5 . Finally , Section 6 concludes the paper . 4 2 Multimedia System Services Architecture The Multimedia System Services -LRB- MSS -RRB- architecture can be easily described by its object life cycle . As shown in Figure 1 , the MSS object life cycle consists of the following components : 1 . client object , 2 . registration and retrieval -LRB- R&R -RRB- , 3 . factory object , and 4 . service object . Client Registration & Retreival Factory Object -LRB- 1 -RRB- -LRB- 2 -RRB- -LRB- 3 -RRB- -LRB- 4 -RRB- -LRB- 5 -RRB- -LRB- 6 -RRB- Figure 1 : The MSS 's object life cycle . When a client needs a specific multimedia service , the client makes a request to the R&R , which will return a reference to the factory that is capable of 5 satisfying the request . The R&R service uses the Common Object Service Submission -LRB- COSS -RRB- . COSS provides a name-to-object association known as name binding . -LRB- A detailed description of COSS can be found in -LSB- Gro94 -RSB- . -RRB- The client passes a class name -LRB- with certain constraints -RRB- , and R&R returns a factory object reference . The client , through the specified factory , creates an object which is capable of meeting the service requested . Later , the client can destroy that object after the service has been fulfilled . As an example , we will discuss a simple distributed multimedia action adopted from -LSB- HIS93 -RSB- . A client using the MSS wants to capture audio with a microphone on one system and play it through a speaker device on another object . First , the client , as an MSS object , specifies a location-based constraints for a microphone device -LRB- object -RRB- and creates an instance of MicrophoneDevice on the specified system . This transparently invokes the R&R and the factory capable of creating such a MicrophoneDevice object -LRB- Figure 2 -RRB- . Client R & R Factory Mic_Device MSS System A Figure 2 : The MSS client creates a MicrophoneDevice object . The client follows a similar process to create a SpeakerDevice object on the target system . The client then creates the virtual connection object to establish the point-to-point connection between the source object -LRB- MicrophoneDevice -RRB- and the target object -LRB- SpeakerDevice -RRB- -LRB- Figure 3 -RRB- . Finally , the client groups these resources and allows the data stream to flow from the source , the MicrophoneDevice object , to the destination , the SpeakerDevice object . When the service is no longer wanted , the client destroys all objects except the factory objects , since they are persistent objects . In the above description of the MSS architecture , the flow of the data stream from the source object to the destination object assumes a full-format 6 Client Speaker_Device MSS System B Mic_Device System A Virtual Connection Figure 3 : The MSS virtual connection between source and target objects . compatibility . This compatibility assumption is reflected through the constraint list specified by the user . This , of course , puts a burden on the client by assuming a full knowledge of the system components and their capabilities . In order to ease this restriction and to add the interoperability feature to the multimedia application environment , we enhanced the MSS architecture . 3 MediaWare 's Object Life Cycle MediaWare is a distributed multimedia environment based on state-of-the-art distributed object computing -LRB- DOC -RRB- specifications as specified by CORBA1 . In MediaWare , we augment the MSS architecture by adding the interoperability feature among distributed media objects . To achieve interoperability among distributed media objects , a specialized database , the interoperable database -LRB- IDB -RRB- , is needed . The IDB stores the transformation objects ' capabilities . Some -LRB- hardware or software -RRB- resources may be needed to achieve such transformation as an intermediary process between the source and the destination . For example , copying a PAL format VCR tape into a SECAM format requires special hardware . Hence , this needs to be reflected in MediaWare 's life cycle and architecture . Needless to say , this intermediate phase is totally transparent to the client . 1Common Object Request Broker Architecture . 7 The interoperable database -LRB- IDB -RRB- stores the capabilities and names , with the locations of the factory objects responsible for activating the transformation objects . Therefore , the IDB has the same interface and functionality as the MSS0s R&R database . Interoperability is manifested through the interoperable virtual connection protocol -LRB- IV CP -RRB- . According to the IV CP , if there is no type -LRB- format -RRB- mismatch between source and destination objects , regular virtual connection will take place . On the other hand , when the transformation is needed , the IV CP will determine if certain resources are necessary for in the transformation process . This can be done by accessing the IDB . If there is such a need , the IV CP returns to the client the identity -LRB- factory ID -RRB- of the factory capable of activating the needed transformation object . The factory then instantiates that object , and the IV CP groups all of these objects together . In grouping these objects , the source object 's output port is linked to the intermediate -LRB- transformation -RRB- object 's input port at one end , and the intermediate object 's output port is linked to the destination 's input port . It is important to note that the level of intermediate transformation is not restricted to a single level . Therefore , two or more stages -LRB- objects -RRB- of transformation may be needed . The IDB is flexible enough to reflect such criteria . In MediaWare , we kept the same object life cycle as specified by MSS . This makes our extension compatible with the MSS object behavior . However , for the purpose of interoperability support , we replace the virtual connection object , with the IV CP object , as shown in Figure 4 . Client R & R Factory IVC MediaWare Figure 4 : A MediaWare object creates the IVCP object . 8 When the transformation between the source and the destination is not needed , or it can be done by the virtual connection protocol without any intermediate objects , the IV CP acts as the virtual connection shown in Figure 3 . However , when such transformation is necessary , the IV CP acts as an intermediate client . The IV CP gets the name and location of the factory -LRB- or factories -RRB- capable of doing the needed transformations from the IDB . The IV CP then , as a nested client object , gets the object identity after it has been instantiated by the specified factory . Figure 5 shows the IV CP controlling the transformation object . Client Factory IVC MediaWare IDB Transformation Object Figure 5 : MediaWare 's IVCP controls the transformation object . After the instantiation of the transformation object -LRB- s -RRB- , the already created source and destination objects will be linked by the IV CP . The IV CP creates a virtual path between the source and destination objects as shown in Figure 6 . The grouping of these objects will take include all these objects , including the transformation objects . It is important to note that the intermediate transformation objects may have a degradation impact on the quality-ofservice , QoS , and need to be considered for any performance related calculations . 9 Client Source IVC MediaWare Transformation Object Destination Figure 6 : MediaWare 's complete flow graph . 4 MediaWare 's Architecture MediaWare is a layered , distributed multimedia environment . Inspired by the layered approach of the International Standard Organization Open System Interconnection -LRB- ISO/OSI -RRB- reference model of computer networks , we adopted the following principles in designing MediaWare 's layers : 1 . A layer is created where a different level of abstraction is needed . 2 . Each layer performs well-defined functions . 3 . The layer boundaries are chosen to minimize the information flow across the layers ' interfaces . 4 . Each layer is self-contained and hides as much information as possible . As shown in Figure 7 , MediaWare is a multimedia environment based on distributed object computing with an interoperability feature added to it through the IV CP . At the application layer , clients can identify any distributed multimedia applications . These applications can be orchestrated or live . In such applications , several distributed media objects -LRB- hardware or software resources -RRB- may be involved . Therefore , the client is required to identify the quality of connection he/she desires . 10 Multimedia Applications Quality of Connection -LRB- QoC -RRB- QoS Synch . UserInter . Interoperable Virtual Connection Proctocol -LRB- IVCP -RRB- Objects DataBase IDB Object Request Broker -LRB- ORB -RRB- IDL Language Mapping Object Implementation Figure 7 : MediaWare 's architecture . 11 In MediaWare , the Quality-of-Connection -LRB- QoC -RRB- is an aggregation of the following components2 : ffl the Quality-of-Service -LRB- QoS -RRB- parameters , ffl the synchronization and temporal relation requirements , and ffl the user interaction functions . These parameters are passed to the third layer , the Interoperable Virtual Connection Protocol -LRB- IVCP -RRB- , which was discussed in the previous section . MediaWare conforms with industry standards , such as CORBA and the Interactive Multimedia Association -LRB- IMA -RRB- recommendation for practice . As such , MediaWare encompasses the provision of an abstract interface of processing nodes , extensible through subclassing to support the abstraction of real processing software or hardware . The IV CP , in addition to creating the virtual path between the media resources , also supports the interoperability feature between media objects . The IV CP keeps a repository of media objects capabilities , specified by CORBA0s Interface Definition Language -LRB- IDL -RRB- , through a general object database . Furthermore , the IV CP mainains a specialized database , the Interoperable Database -LRB- IDB -RRB- , which stores the capabilities and locations of the transformation media objects . Both databases identify the source and destination object ID 's . These objects can be instantiated through their associated factories3 . If an intermediate object is required , the IV CP transparently instantiates that object and links the source , intermediate , and target objects . A client knows only the logical structure of the objects according to their specialized interfaces . The IV CP handles the interoperability feature between the service objects , source objects , and destination objects . The IV CP can detect the need for interoperation from the source and destination objects ' interfaces . The Object Request Broker -LRB- ORB -RRB- makes the low level connection between all of the involved objects and their implementations through the language mapping layer . -LRB- See CORBA -LSB- Gro92 -RSB- for more details on the ORB architecture and the IDL mapping to the implementation language . -RRB- Figure 2Refer to -LSB- AS94 -RSB- for an exhaustive discussion of these components . 3In CORBA 's terminology . 12 8 shows a request being sent by a client through MediaWare . The figure illustrates all of the required steps which take place in order to satisfy the client 's request . Client QoC IVCP dB + IDB O R B Language Mapping Object Implementation 1 2 3 4 5 6 7 Figure 8 : MediaWare steps needed to satisfy a client request . 5 MediaWare 's Scenarios Multimedia presentations involve the integration , or teleorchestration , of several media objects . In teleorchestration , relative and uncertain temporal specifications may exist among the data objects involved ; thus , fuzzy scenarios can be generated -LSB- LKG94 -RSB- . In this section , we discuss the ability to create different scenarios from existing objects . This capability distinguishes MediaWare from other environments and makes it a rich working environment in which to develop and engineer distributed object computing applications . 13 The following is an illustrative example shows how multimedia can be helpful in generating and storing medical records . This example reflects MediaWare 's ability to generate and deal with different scenarios . Example : Assume that a certain clinic keeps multimedia patients records . These records include several media objects which reflect the patients ' history . The media types may include image objects -LRB- X-ray -RRB- , audio objects -LRB- interview -RRB- , video objects -LRB- surgery -RRB- , and text objects -LRB- historical information -RRB- . Assume that patient A 's record contains all the above objects . During the patient 's visit to the clinic , the doctor needs to view the patient 's history through the scenario specified by the temporal relations as shown in Figure 9 . Media TypeImage TextVideo Audio Time I1 T1 V1 I2 A1 ts tf Figure 9 : Medical scenario -LRB- 1 -RRB- . Figure 9 shows that the doctor needs to display the textual information throughout the review process , during which he wants to listen to a previous interview with the patient -LRB- as specified by the audio object A1 . -RRB- The audio object A1 finishes the display of the X-ray image -LRB- I1 object -RRB- and starts the video object -LRB- V1 -RRB- . The video object V 1 shows previous surgery on the patient . At the end of the video object V 1 , the doctor needs to see the results of the surgery through another X-ray 14 image -LRB- I2 object . -RRB- Finally , at tf , the doctor finishes the review , and all of these objects will be destroyed . It is important to note that all of these objects need not be co-located . Assume that after a while , the same doctor wants to create presentation materials , and he would like to incorporate some of these objects in his presentation . At this time , to serve the presentation flow , he decides to use a different presentation scenario . Figure 10 shows the temporal relation he used in his presentation . Media TypeImage TextVideo Audio Time I1 T1 V1 I2 A2 ts tf Figure 10 : MediaWare scenario -LRB- 2 -RRB- . As Figure 10 shows , the doctor first displayed the patient 's textual information T 1 , followed by his X-ray , I1 and I2 . The video object started at the end of the image I2 display interval . All of these activities were accompanied by the doctor 's audio explanation , A2 . Assume that the presentation took place in a conference room in a different location , but withh all of the media devices needed for the presentation . All the doctor needs to do in this case is to generate his scenario , and MediaWare is able to achieve his request and instantiate all of the needed objects . In the above example , we illustrated how the same objects can be involved , with different sequences -LRB- different temporal specifications -RRB- , in different scenarios . A user can generate as many scenarios as he/she wishes . This 15 gives the user the flexibility of generating different \ scenes '' from the same data . This can be very helpful in creating training courses , movies , multimedia records , etc. . Furthermore , different users can use the same set of objects in different scenarios , simultaneously . In another paper -LSB- AS94 -RSB- , we fully discussed temporal relations and their modelings . These relations , -LRB- x -LRB- before -RRB- y , x -LRB- meets -RRB- y , etc. -RRB- , could be fuzzy temporal specifications . We showed how these fuzzy relations can be modeled and use in certain teleorchestration . This feature adds a new source of flexibility to MediaWare 's scenario generation capabilities . In other words , through MediaWare , users can specify fuzzy temporal relations if they do n't know the exact starting and ending points of object playouts . Refer to -LSB- AS94 -RSB- for further details on the fuzzy temporal specification , quality-of-connection , user interactions , synchronization requirements , and a full description of the IV CP . 6 Conclusion We showed in this paper that our MediaWare is an enhancement of the IMA 's Multimedia System Services -LRB- MSS -RRB- . Our extension is based on the addition of an interoperability feature to the MSS . It is important to note , however , that we adopted the same object life cycle as the MSS . This makes the MediaWare a natural extension to the MSS and compatible with it . The MSS life cycle was discussed in some detail . Then MediaWare 's architecture was presented . One of the major features of MediaWare is its ability to support the dynamic creations of distributed multimedia scenarios . This maximizes the reusability and utilization of media objects and creates a flexible working environment in which to develop media teleorchestrations . MediaWare architecture is based on state-of-the-art distributed object computing -LRB- DOC -RRB- specifications as identified by CORBA . Therefore , we can consider that MediaWare is a distributed object computing based multimedia environment . The interoperable virtual connection protocol makes MediaWare capable of supporting interoperable media objects . 16 References -LSB- AE92 -RSB- Sudhir R. Ahuja and J. R. Ensor . Coordination and control of Multimedia conferencing . IEEE Communication Magazine , pages 38 -LCB- 44 , May 1992 . -LSB- AS94 -RSB- Yahya Y. Al-Salqan . MediaWare : A Distributed Multimedia Computing Environment and Formalism Based on Interoperable Petri Net . Ph.D. . Thesis , University of Illinois at Chicago , 1994 . -LSB- BHI93 -RSB- Sara A. Bly , S. R. Harrison , and S. Irwin . Multimedia in the workplace . ACM Communications , pages 28 -LCB- 45 , January 1993 . -LSB- Cla92 -RSB- William J. Clark . Multipoint Multimedia conferencing . IEEE Communication Magazine , pages 44 -LCB- 51 , May 1992 . -LSB- Gro92 -RSB- Object Management Group . The Common Request Broker : Architecture and Specification . Object Management Group and X/Open : Document number 91.12.1 , Framingham , MA , 1992 . -LSB- Gro94 -RSB- Object Management Group . Common Object Services Specifications , volume 1 . John Wiley & Sons , Inc. , New York , N.Y. , March 1994 . -LSB- HIS93 -RSB- HP , IBM , and SunSoft . Multimedia System Services . HP , IBM , and SunSoft , 1993 . -LSB- HLMS93 -RSB- David N. Horn , T. G. Lyons , J. C. Mitchel , and D. L. Skran . A standard-based multimedia conferencing bridges . AT&T Technical Journal , 72 -LRB- 1 -RRB- :41 -LCB- 49 , January/February 1993 . -LSB- KHS92 -RSB- Jr. . Kime H. Smith . Accessing Multimedia network services . IEEE Communication Magazine , pages 72 -LCB- 83 , May 1992 . -LSB- Kje91 -RSB- Lars Kjelldahl , editor . Multimedia systems , applications and interactions , chapter 14 : Multimedia conferencing as a universal paradigm . Spring-Verlag , Berlin , Germany , 1991 . 17 -LSB- LBea90 -RSB- W.H. Leung , T. J. Baumgartner , and Y. H. Hwang et al. . A software architecture for workstations supporting multimedia conferencing in packet switching networks . IEEE Journal on selected areas in communications , 8 -LRB- 3 -RRB- :380 -LCB- 390 , April 1990 . -LSB- Leo92 -RSB- Shoshana Leob . Delivering interactive Multimedia documents over networks . IEEE Communication Magazine , pages 52 -LCB- 59 , May 1992 . -LSB- LKG94 -RSB- L. Li , A. Karmouch , and N.D. Georganas . Multimedia Teleorchestra with Independent sources : Part 1 - Temporal Modeling of Collaborative Multimedia Scenarios . Multimeda Systems , pages 143 -LCB- 153 , February 1994 . -LSB- Nic90 -RSB- Cosmos Nicolaou . An architecture of real-time multimedia communication systems . IEEE Journal on selected areas in communications , 8 -LRB- 3 -RRB- :391 -LCB- 400 , April 1990 . -LSB- OSKQ90 -RSB- F. Oguet , C. Schwartz , F. Kretz , and M. Quere . RAVI : a proposed standard for interchange of audio/visual interactive applications . IEEE Journal on selected areas in communications , 8 -LRB- 3 -RRB- :428 -LCB- 436 , April 1990 . -LSB- RKGB92 -RSB- Jonathan Rosenberg , R. E. Kraut , L. Gomez , and C. A. Buzzard . Multimedia communications for users . IEEE Communication Magazine , pages 20 -LCB- 38 , May 1992 . -LSB- RR92 -RSB- S. Ramanathan and P. Venkat Rangan . Adaptive feedback techniques for synchronized multimedia retrieval over integrated networks . Technical report CS92-271 , November 1992 . -LSB- RR93 -RSB- S. Ramanathan and P. Venkat Rangan . Feedback techniques for intra-media continuity and inter-media synchronization in distributed multimedia systems . The Computer Journal , 36 -LRB- 1 -RRB- :19 -LCB- 31 , 1993 . -LSB- RRV92 -RSB- S. Ramanathan , P. Venkat Rangan , and H. M. Vin . Designing communication architecture for inter-organization multimedia collaboration . Technical report CS92-226 , January 1992 . 18 -LSB- RVK92 -RSB- S. Ramanathan , P. Venkat Rangan H. M. Vin , and T. Kaeppner . Optimal communication architecture for multimedia conferencing in distributed systems . Proceedings of the International conference on distributed computing systems , pages 46 -LCB- 53 , June 1992 . -LSB- RVR92 -RSB- P. Venkat Rangan , H. M. Vin , and S. Ramanathan . Designing on-demand Multimedia service . IEEE Communication Magazine , pages 56 -LCB- 65 , July 1992 . -LSB- Ste90 -RSB- Ralf Steinmetz . Synchronization properties in multimedia systems . IEEE Journal on selected areas in communications , 8 -LRB- 3 -RRB- :401 -LCB- 412 , April 1990 . -LSB- VRC92 -RSB- Harrick M. Vin , P. Venkat Rangan , and M. S. Chen . System support for computer mediated multimedia collaborations . Proceedings of Computer Supported Cooperative Work CSCW ' 92 , pages 203 -LCB- 209 , November 1992 . 19

O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O B O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O B O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O

distributed object computing
doc
interoperability

multimedia teleorchestration and scenarios


H.

Bowman

and

J.

Derrick

-LRB-

eds

-RRB-

Proc

IFIP

Int

Conf

on

Formal

Methods

for

Open

Object-Based

Distributed

Systems

A

proof-theoretic

approach

to

the

design

of

object-based

mobility

Carlos

H.

C.

Duarte

Department

of

Computing

Imperial

College

Queen

's

Gate

London

United

Kingdom

e-mail

tel

+44 171 594 8341

fax

+44 171 581 8024

Abstract

With

the

advent

of

technologies

to

realise

parallel

computing

in

mobile

sometimes

portable

platforms

it

is

now

possible

to

fulfil

requirements

related

to

the

very

dynamic

and

mutable

user

location

Designing

the

required

applications

calls

for

improved

formal

methods

to

treat

mobility

while

assuring

correctness

In

this

paper

we

argue

that

mobile

systems

can

be

specified

and

verified

in

an

effective

modular

manner

using

a

logic

which

allows

us

to

deal

with

object

creation

and

reconfiguration

Capitalising

on

our

previous

work

on

the

specification

and

verification

of

actor

systems

using

a

temporal

logic

of

objects

here

we

show

that

our

approach

can

be

used

to

formally

design

location

dependent

applications

INTRODUCTION

We

are

currently

facing

a

radical

change

in

the

way

users

interact

with

software

systems

and

in

the

underlying

distributed

software

architectures

Thanks

to

the

advent

of

technologies

like

cellular

phones

personal

digital

assistants

and

active

badges

users

are

no

longer

required

to

go

to

specific

access

points

to

take

advantage

of

some

locally

provided

functionality

Such

devices

have

become

increasingly

more

personal

and

can

be

carried

by

their

owners

In

turn

software

systems

may

now

be

used

at

any

time

and

place

and

can

provide

location

dependent

functionality

such

as

ubiquitous

message

delivery

transportable

user

sessions

and

others

-LSB-

-RSB-

What

is

essentially

novel

in

this

new

operational

environment

is

the

very

presence

of

mobility

The

way

to

support

the

new

requirements

mobility

poses

is

the

management

of

location

information

The

need

to

manage

both

location

information

and

mobility

brings

with

it

new

problems

to

be

addressed

in

the

design

of

parallel/distributed

systems

For

example

it

is

now

important

to

develop

quantitative

models

to

predict

network

performance

according

to

user

mobility

-LSB-

-RSB-

We

are

particularly

concerned

here

with

the

more

fundamental

question

on

how

to

develop

such

systems

so

as

to

correctly

provide

the

required

functionality

As

complexity

substantially

grows

with

the

autonomy

and

heterogeneity

presented

by

mobile

devices

and

mobile

applications

become

more

and

more

open

characteristics

that

must

be

accounted

for

in

some

design

step

introducing

errors

during

the

development

process

turns

out

to

be

easier

and

costly

The

only

way

to

assure

software

correctness

is

the

development

of

a

formal

qualitative

model

of

the

system

to

be

refined

in

a

step-by-step

process

until

an

implementation

is

produced

As

a

result

it

is

possible

to

clarify

any

matter

of

concern

through

proof

or

refutation

Unfortunately

most

of

the

existing

formal

methods

are

not

so

good

in

designing

mobile

applications

Well

established

methods

like

VDM

-LSB-

-RSB-

and

Z

-LSB-

-RSB-

do

not

address

at

all

the

inherent

concurrency

of

mobile

systems

In

some

other

cases

concurrency

is

actually

treated

but

the

design

process

is

organized

in

terms

of

notions

like

processes

-LSB-

-RSB-

or

programs

-LSB-

-RSB-

which

certainly

provide

important

insights

on

how

an

implementation

should

work

but

poorly

support

understanding

and

representing

the

problem

domain

in

an

organised

manner

On

the

other

hand

the

use

of

object-based

notions

like

attributes

actions

and

encapsulation

as

in

-LSB-

-RSB-

seems

to

bridge

this

gap

Even

then

expressibility

concerns

arise

since

the

basic

notion

of

mobility

has

to

be

captured

We

have

developed

a

logic

to

support

the

design

of

actor

systems

-LSB-

-RSB-

Actors

are

computational

objects

with

encapsulated

state

which

openly

interact

through

asynchronous

point-to-point

message

passing

-LSB-

-RSB-

As

a

result

of

processing

messages

new

concurrent

actors

can

be

created

and

actor

names

can

be

communicated

supporting

in

this

way

dynamic

reconfiguration

of

actor

communities

Our

logic

uses

temporal

theories

as

object

descriptions

and

theory

morphisms

as

specification

connectors

particularising

-LSB-

-RSB-

although

it

presents

an

additional

mode

of

interaction

between

objects

to

capture

reliable

asynchrony

These

characteristics

make

it

possible

to

produce

specifications

in

isolation

to

be

subsequently

combined

as

well

as

to

decompose

proofs

of

global

properties

in

lemmas

about

single

objects

to

be

verified

in

a

localised

manner

We

claim

here

that

these

characteristics

are

sufficient

to

guarantee

an

effective

and

modular

formal

design

of

object-based

mobile

systems

We

are

not

aware

of

any

similar

work

in

the

literature

In

order

to

support

our

claim

we

have

chosen

to

study

here

the

design

of

a

location

management

architecture

for

networks

of

mobile

users

and

devices

For

simplicity

we

ignore

the

important

issues

of

dependability

authenticity

and

security

-LSB-

-RSB-

and

concentrate

just

in

the

management

of

location

information

In

the

next

section

we

introduce

our

actor-based

design

approach

Subsequently

we

informally

describe

the

requirements

of

location

management

applications

and

devote

two

sections

to

their

design

namely

to

their

specification

and

verification

We

conclude

the

paper

providing

a

brief

evaluation

of

our

achievements

and

suggesting

further

research

A

PROOF-THEORETIC

APPROACH

TO

ACTOR

DESIGN

We

adopt

full

many-sorted

first-order

branching

time

logic

with

equality

as

the

underlying

foundation

of

our

work

A

good

survey

on

the

subject

appears

in

-LSB-

-RSB-

Theory

signatures

and

presentations

are

used

to

define

respectively

the

language

and

description

of

object

behaviours

and

to

produce

modularised

designs

We

identify

therein

the

basic

object-based

notions

of

attribute

action

and

encapsulation

and

connect

these

entities

using

signature

and

theory

morphisms

as

proposed

in

-LSB-

-RSB-

The

actor-based

formalism

is

obtained

as

a

particularization

of

this

generic

framework

In

-LSB-

-RSB-

we

provide

the

rationale

leading

us

to

propose

the

formalism

as

such

and

the

description

of

its

proof-theory

Here

we

only

present

the

relevant

notions

to

mobile

systems

design

Before

introducing

technical

definitions

let

us

present

in

Figure

the

specification

of

region

tree

nodes

instances

of

the

spatial

hierarchical

data

structures

described

in

-LSB-

-RSB-

Actor

RegionTreeNode

data

types

addr

direc

int

bool

-LRB-

T

F

bool

int

int

int

int

-RRB-

attributes

me

to

addr

reg

-LSB-

direc

-RSB-

addr

void

bool

ans

int

actions

cnt

-LRB-

addr

addr

-RRB-

local

birth

node

-LRB-

addr

addr

-RRB-

local

extrn

birth

inc

updt

-LRB-

addr

addr

addr

addr

-RRB-

local

computation

ack

-LRB-

addr

addr

addr

addr

-RRB-

extrn

message

split

-LRB-

addr

-RRB-

in

-LRB-

addr

addr

-RRB-

rep

-LRB-

addr

addr

bool

-RRB-

local

extrn

message

axioms

k

n

p

q

r

s

t

u

x

y

z

addr

d

direc

v

int

b

bool

node

-LRB-

n

p

-RRB-

cnt

-LRB-

n

p

-RRB-

me

n

to

p

void

T

reg

-LSB-

d

-RSB-

n

ans

-LRB-

-RRB-

updt

-LRB-

n

-RRB-

me

p

to

q

ans

v

X

-LRB-

me

p

to

q

ans

v

void

F

r

eg

n

-RRB-

-LRB-

-RRB-

inc

me

n

to

p

r

eg

q

ans

v

X

-LRB-

me

n

to

p

r

eg

q

ans

v

-RRB-

-LRB-

-RRB-

split

-LRB-

n

-RRB-

me

p

X

-LRB-

q

new

-LRB-

node

qi

qi

p

-RRB-

updt

-LRB-

q

-RRB-

send

-LRB-

ack

n

q

-RRB-

-RRB-

-LRB-

-RRB-

-LRB-

in

-LRB-

n

p

-RRB-

r

n

rep

-LRB-

r

s

T

-RRB-

to

p

-RRB-

me

n

X

-LRB-

send

-LRB-

rep

p

r

n

T

-RRB-

-RRB-

-LRB-

-RRB-

in

-LRB-

n

p

-RRB-

me

q

q

n

void

F

r

eg

r

X

-LRB-

s

new

-LRB-

cnt

s

q

p

-RRB-

send

-LRB-

in

ri

n

s

-RRB-

-RRB-

-LRB-

-RRB-

in

-LRB-

n

p

-RRB-

me

q

q

n

void

T

X

-LRB-

send

-LRB-

rep

p

n

q

F

-RRB-

-RRB-

-LRB-

-RRB-

rep

-LRB-

n

p

F

-RRB-

to

r

me

q

X

-LRB-

ans

send

-LRB-

rep

r

n

q

F

-RRB-

inc

-RRB-

-LRB-

-RRB-

n

p

new

-LRB-

node

ni

pi

q

-RRB-

updt

-LRB-

n

-RRB-

send

-LRB-

ack

r

n

-RRB-

split

-LRB-

r

-RRB-

me

q

-LRB-

-RRB-

inc

p

rep

-LRB-

n

p

F

-RRB-

ans

-LRB-

-RRB-

send

-LRB-

rep

n

p

q

T

-RRB-

-LRB-

in

-LRB-

q

n

-RRB-

p

q

rep

-LRB-

p

s

T

-RRB-

to

n

-RRB-

me

q

-LRB-

-RRB-

send

-LRB-

rep

n

p

q

F

-RRB-

-LRB-

in

-LRB-

p

n

-RRB-

p

q

void

T

rep

-LRB-

p

s

F

-RRB-

to

n

ans

-RRB-

me

q

-LRB-

-RRB-

new

-LRB-

cnt

n

q

r

-RRB-

send

-LRB-

in

pi

s

n

-RRB-

in

-LRB-

s

r

-RRB-

me

q

q

s

void

F

r

eg

p

-LRB-

-RRB-

node

-LRB-

k

n

-RRB-

cnt

-LRB-

k

n

-RRB-

G

-LRB-

E

-LRB-

deliv

-LRB-

split

-LRB-

p

-RRB-

-RRB-

-RRB-

E

-LRB-

deliv

-LRB-

in

-LRB-

q

r

-RRB-

-RRB-

-RRB-

E

-LRB-

deliv

-LRB-

rep

-LRB-

s

t

b

-RRB-

-RRB-

-RRB-

-RRB-

-LRB-

-RRB-

node

-LRB-

k

n

-RRB-

cnt

-LRB-

k

n

-RRB-

XG

-LRB-

inc

updt

-LRB-

p

q

r

s

-RRB-

E

-LRB-

split

-LRB-

t

-RRB-

-RRB-

E

-LRB-

in

-LRB-

u

x

-RRB-

-RRB-

E

-LRB-

rep

-LRB-

y

z

b

-RRB-

-RRB-

-RRB-

-LRB-

-RRB-

End

Figure

Specification

of

region

trees

These

will

be

used

in

designing

location

management

later

on

At

the

top

of

each

theory

presentation

we

can

see

sequences

of

sorts

plus

the

associated

constants

and

operations

-LRB-

data

types

-RRB-

attribute

and

action

symbols

denoting

respectively

fixed

meaning

data

objects

the

local

state

and

the

messages

and

computations

dealt

with

by

these

actors

For

instance

a

region

can

receive

a

request

to

divide

itself

-LRB-

split

-RRB-

in

sub-regions

-LRB-

reg

-RRB-

organised

according

to

the

four

directions

of

the

compass

points

-LRB-

direc

-RRB-

Eventually

continuations

-LRB-

cnt

-RRB-

are

created

in

order

to

answer

inclusion

queries

-LRB-

in

-RRB-

These

symbols

belong

the

language

of

region

tree

nodes

and

are

generically

formalised

as

follows

Definition

-LRB-

Actor

Signature

-RRB-

An

actor

signature

is

a

triple

of

disjoint

and

finite

families

-LRB-

A

-RRB-

where

ffl

-LRB-

S

-RRB-

is

an

universe

signature

i.e.

S

is

a

set

of

sort

symbols

and

is

an

S

S

indexed

family

of

operation

symbols

We

require

that

the

sort

of

mail

addresses

addr

S

ffl

A

is

an

S

S-indexed

family

of

attribute

symbols

ffl

-LRB-

e

l

c

-RRB-

S

indexed

sets

of

action

symbols

with

-LRB-

e

-LSB-

l

-RRB-

c

empty

c

is

a

set

of

local

computation

symbols

e

and

l

represent

respectively

sets

of

events

to

be

requested

from

the

environment

and

provided

locally

These

two

sets

consist

in

collections

of

message

and

birth

computation

symbols

e.g.

l

lb

and

lb

respectively

For

ffl

as

the

empty

sequence

we

write

an

ffl

s-indexed

family

of

symbols

as

if

s

were

its

index

Given

a

set

X

we

denote

the

sub-set

of

X

symbols

of

sort

sni

s

as

sni

s

We

shall

also

operate

with

subscripts

-LRB-

eb

lb

-RRB-

to

denote

operations

on

sub-sets

of

-LRB-

eb

lb

-RRB-

Axioms

defined

out

of

terms

and

formulae

are

also

present

in

the

previous

specification

An

example

is

that

asserting

both

the

invariance

of

the

attributes

holding

the

mail

addresses

of

the

node

and

its

parent

-LRB-

terms

in

-RRB-

and

the

creation

of

sub-regions

in

the

instant

following

an

update

-LRB-

updt

-RRB-

Likewise

we

use

a

formula

to

say

that

after

the

birth

of

a

node

requests

for

split

in

or

rep

may

always

be

delivered

-LRB-

-RRB-

although

they

may

only

be

consumed

if

the

node

is

not

busy

sequentially

performing

local

computations

-LRB-

-RRB-

To

define

these

notions

we

assume

that

an

infinite

family

of

rigid

variables

and

its

classification

according

to

the

sorts

of

a

signature

are

given

Definition

-LRB-

Terms

-RRB-

The

S-indexed

set

of

terms

T

-LRB-

-RRB-

is

defined

as

follows

provided

that

q

s

-LSB-

s

-LSB-

As

p

sni

s

f

sni

s

and

ti

T

-LRB-

-RRB-

si

t

q

j

p

-LRB-

tn

-RRB-

j

f

-LRB-

tn

-RRB-

Definition

-LRB-

Formulae

-RRB-

The

set

F

-LRB-

-RRB-

of

formulae

is

defined

by

the

mutual

recursion

below

provided

that

c

sni

ti

T

-LRB-

-RRB-

si

y

s

and

gi

F

-LRB-

-RRB-

g

beg

j

c

-LRB-

tn

-RRB-

j

s

j

j

j

j

g

j

j

j

j

j

Terms

consist

in

variables

nulary

function

and

attribute

symbols

or

function

and

attribute

symbols

applied

to

terms

We

usually

write

a

sequence

of

similar

terms

tn

as

t.

Formulae

stand

for

the

initial

instant

-LRB-

beg

-RRB-

action

occurrences

term

equality

the

occurrence

of

a

property

in

some

possible

behaviour

-LRB-

E

-RRB-

in

the

next

instant

-LRB-

X

-RRB-

or

until

another

property

holds

-LRB-

U

-RRB-

or

formulae

aggregation

using

first-order

logic

connectives

These

are

the

original

CTL

constructs

-LSB-

-RSB-

enriched

to

express

object-based

notions

The

reader

may

wonder

why

new

deliv

and

send

do

not

appear

in

our

definitions

above

Actually

they

stand

for

the

abbreviation

of

logical

actions

as

defined

in

-LSB-

-RSB-

Much

in

the

way

that

ASCCS

is

a

subset

of

SCCS

-LSB-

-RSB-

our

calculus

which

captures

synchronous

object

creation

and

reliable

asynchronous

message

passing

can

be

seen

as

a

particularization

of

the

synchronous

object

calculus

of

-LSB-

-RSB-

The

aforementioned

connectives

are

definable

therein

and

have

the

following

informal

meaning

For

of

type

formula

reads

c

n

vc

eb

-LSB-

lb

addr

T

-LRB-

-RRB-

new

-LRB-

c

n

vc

-RRB-

creation

of

an

actor

with

a

given

name

c

n

vc

-LRB-

e?eb

-RRB-

-LSB-

-LRB-

l?lb

-RRB-

addr

T

-LRB-

-RRB-

send

-LRB-

c

n

vc

-RRB-

dispatch

of

a

message

to

a

specific

actor

c

vc

l?lb

T

-LRB-

-RRB-

deliv

-LRB-

c

vc

-RRB-

delivery

of

a

message

As

for

the

actor

primitive

become

which

allows

actors

to

have

mutable

state

space

there

is

no

treatment

here

If

it

does

not

receive

a

higher-order

interpretation

this

primitive

is

definable

within

the

core

actor

theory

as

noticed

in

-LSB-

-RSB-

In

designing

mobile

systems

such

a

higher-orderness

is

not

required

Specifications

characterise

communities

of

actors

with

similar

behaviour

What

make

these

actors

different

from

each

other

are

their

distinct

names

-LRB-

of

sort

addr

prefixed

to

terms

when

talking

about

global

properties

-RRB-

and

their

potentially

distinct

interactions

with

the

environment

Specifications

are

defined

as

theory

presentations

comprising

a

signature

and

a

set

of

axioms

explicitly

provided

by

the

specifier

Definition

-LRB-

Actor

Specification

-RRB-

An

actor

specification

is

a

pair

-LRB-

-RRB-

where

is

an

actor

signature

and

is

a

finite

set

of

formulae

over

-LRB-

the

specification

axioms

-RRB-

To

each

specification

is

assigned

a

set

of

additional

logical

axioms

called

Ax

These

axioms

are

provided

in

schematic

form

in

the

Appendix

and

constrain

the

behaviour

of

the

environment

relative

to

the

specified

actors

Such

axioms

become

necessary

together

with

the

deductive

system

of

the

branching

time

temporal

logic

of

objects

and

the

additional

inference

rules

of

the

Appendix

in

the

verification

of

actor

properties

For

notational

convenience

formulae

containing

derived

first-order

logic

connectives

and

inequalities

stand

for

the

usual

translations

Moreover

free

variables

in

axioms

are

considered

to

be

universally

quantified

Other

admissible

connectives

are

defined

as

For

of

type

formula

reads

represents

g

F

-LRB-

-RRB-

Ag

in

any

behaviour

E

g

g

F

-LRB-

-RRB-

Fg

eventually

in

the

future

-LRB-

g

g

-RRB-

Ug

g

F

-LRB-

-RRB-

Gg

always

in

the

future

F

g

F

-LRB-

-RRB-

unless

G

-LRB-

-RRB-

p

F

-LRB-

-RRB-

i

initially

precedes

p

-LRB-

-RRB-

W

-LRB-

-RRB-

p

F

-LRB-

-RRB-

p

precedes

i

X

-LRB-

i

-LRB-

p!p

-RRB-

-RRB-

The

unary

connectives

above

are

non-strict

-LRB-

they

include

the

present

-RRB-

and

usually

appear

in

branching-time

logics

Conversely

the

precedence

connectives

are

strict

and

forbid

the

simultaneous

occurrence

of

some

properties

In

specifications

where

p

usually

stands

for

the

occurrence

of

some

birth

action

-LRB-

which

we

write

as

init

-RRB-

their

index

is

omitted

All

these

temporal

connectives

are

used

e.g.

to

state

and

reason

about

causality

relations

that

a

query

in

for

the

inclusion

of

a

node

n

in

a

region

when

consumed

by

any

nonempty

node

distinct

from

n

in

the

next

instant

results

not

only

in

the

dispatch

of

many

similar

queries

to

the

respective

sub-regions

but

also

in

the

creation

of

a

continuation

actor

to

process

their

answers

-LRB-

-RRB-

something

that

can

not

happen

otherwise

-LRB-

-RRB-

Given

some

independently

specified

actor

communities

we

may

want

to

interconnect

them

to

define

communities

of

heterogeneous

cooperating

actors

This

can

be

done

by

providing

language

translations

between

their

theory

presentations

obeying

what

follows

Definition

-LRB-

Signature

Morphisms

-RRB-

Given

two

actor

signatures

-LRB-

-RRB-

and

-LRB-

-RRB-

a

signature

morphism

o

consists

of

ffl

a

morphism

of

algebraic

structures

oAE

such

that

oAE

-LRB-

-RRB-

ffl

for

each

f

sni

s

an

attribute

symbol

off

-LRB-

f

-RRB-

oAE

-LRB-

-RRB-

oAE

-LRB-

sn

-RRB-

oAE

-LRB-

s

-RRB-

in

ffl

for

each

c

sni

an

action

symbol

o

-LRB-

c

-RRB-

oAE

-LRB-

-RRB-

oAE

-LRB-

sn

-RRB-

in

such

that

o

-LRB-

-RRB-

o

-LRB-

-RRB-

o

-LRB-

-RRB-

where

o

-LRB-

-RRB-

-LSB-

and

o

-LRB-

-RRB-

-LRB-

-RRB-

-LSB-

-LRB-

-RRB-

o

-LRB-

-RRB-

and

o

-LRB-

-RRB-

so

that

o

-LRB-

-RRB-

It

is

straightforward

to

define

inductively

the

translation

of

symbols

classifications

terms

formulae

and

sets

thereof

under

o

From

the

first

item

we

can

see

that

interconnected

actor

communities

are

named

using

the

same

sort

namely

addr

In

addition

the

third

item

says

that

event

symbols

representing

requests

of

a

community

to

its

environment

can

be

associated

with

events

internally

provided

by

a

distinct

community

-LRB-

eg

o

-LRB-

-RRB-

-RRB-

meaning

that

messages

can

be

dispatched

to

and

actors

created

within

one

community

from

another

Technically

the

translation

of

connected

theory

presentations

induced

by

signature

morphisms

does

not

capture

the

expected

interconnection

of

actor

behavior

in

a

precise

way

This

is

due

to

the

existing

logical

axioms

of

the

original

theories

which

are

not

translated

by

such

morphisms

We

are

obliged

to

use

an

alternative

notion

Definition

-LRB-

Theory

or

Specification

Morphisms

-RRB-

Given

two

actor

specifications

-LRB-

-RRB-

and

-LRB-

-RRB-

a

specification

morphism

o

is

a

signature

morphism

such

that

o

-LRB-

g

-RRB-

for

every

g

-LSB-

Ax

We

should

stress

that

connecting

specifications

using

theory

morphisms

is

analogous

to

providing

links

between

identifiers

in

distinct

actor

programs

-LSB-

-RSB-

As

we

shall

see

later

to

verify

actor

properties

we

also

need

to

identify

which

actors

are

assumed

to

exist

in

the

environment

and

which

are

able

to

receive

messages

from

the

outside

as

in

-LSB-

-RSB-

INFORMAL

REQUIREMENTS

OF

LOCATION

MANAGEMENT

A

central

problem

in

designing

and

implementing

software

systems

for

networks

of

mobile

users

and

devices

is

how

to

manage

object

location

An

extensive

description

of

the

problem

can

be

found

in

the

literature

-LRB-

cf.

-LSB-

-RSB-

-RRB-

In

this

section

we

provide

an

informal

list

of

requirements

strictly

imposed

by

mobility

In

the

next

section

we

enumerate

some

design

decisions

based

on

this

list

and

propose

a

formal

specification

for

the

corresponding

mobile

architecture

We

can

classify

the

requirements

of

location

management

in

three

families

the

first

concerning

the

nature

of

location

information

and

located

objects

the

second

about

the

process

of

acquiring

location

information

and

the

third

on

how

to

deal

with

it

In

what

follows

we

ignore

real

time

issues

and

provide

a

partial

list

of

functional

requirements

A

location

information

must

be

dynamic

in

the

sense

that

at

each

time

it

may

be

a

distinct

instance

of

a

class

of

objects

A

location

information

must

be

mutable

in

the

sense

that

at

each

time

it

may

be

an

instance

of

a

distinct

class

of

objects

Located

objects

may

be

users

or

devices

at

least

Location

information

acquisition

must

be

unintrusive

which

means

that

the

acquisition

process

can

not

intrude

user

behaviour

nor

require

user

intervention

Location

information

acquisition

must

offer

support

to

multiple

location

observations

which

means

that

simultaneous

observations

producing

distinct

location

information

for

the

same

object

may

occur

Location

information

management

must

support

indeterminacy

which

means

that

location

information

for

some

objects

may

not

be

available

at

some

instant

Location

information

management

must

offer

support

to

object

naming

which

is

the

assignment

of

meaningless

unique

names

to

located

objects

The

first

two

items

should

not

be

confused

While

it

is

obvious

that

mobile

object

locations

may

change

as

time

passes

meaning

that

they

are

dynamic

it

is

not

so

obvious

that

they

should

also

be

mutable

The

reason

for

this

is

that

a

location

service

may

provide

information

with

distinct

accuracies

or

that

multiple

services

may

be

used

-LSB-

-RSB-

Actor

Sensor

data

types

addr

int

-LRB-

MAX

int

int

int

int

-RRB-

attributes

srv

obj

loc

id

addr

tick

int

actions

sens

-LRB-

addr

addr

addr

addr

-RRB-

local

extrn

birth

reloc

-LRB-

addr

-RRB-

set

-LRB-

int

-RRB-

obs

local

computation

detect

-LRB-

addr

addr

-RRB-

unreach

-LRB-

addr

addr

-RRB-

extrn

message

axioms

n

p

q

r

addr

v

int

sens

-LRB-

n

p

q

r

-RRB-

srv

n

obj

p

loc

q

id

r

tick

-LRB-

-RRB-

reloc

-LRB-

n

-RRB-

srv

p

obj

q

id

r

tick

v

X

-LRB-

srv

p

obj

q

id

r

tick

v

-RRB-

-LRB-

-RRB-

reloc

-LRB-

n

-RRB-

X

-LRB-

loc

n

-RRB-

-LRB-

-RRB-

set

-LRB-

v

-RRB-

srv

n

obj

p

loc

q

id

r

X

-LRB-

srv

n

obj

p

loc

q

id

r

-RRB-

-LRB-

-RRB-

set

-LRB-

v

-RRB-

X

-LRB-

tick

v

-RRB-

-LRB-

-RRB-

obs

srv

n

loc

p

-LRB-

obj

q

id

q

-RRB-

X

-LRB-

set

-LRB-

-RRB-

send

-LRB-

detect

n

q

p

-RRB-

-RRB-

-LRB-

-RRB-

sens

-LRB-

n

p

q

r

-RRB-

G

-LRB-

obs

tick

MAX

send

-LRB-

unreach

srv

obj

loc

-RRB-

-RRB-

-LRB-

-RRB-

sens

-LRB-

n

p

q

r

-RRB-

G

-LRB-

obs

tick

MAX

set

-LRB-

-RRB-

-RRB-

-LRB-

-RRB-

sens

-LRB-

n

p

q

r

-RRB-

G

-LRB-

set

-LRB-

-RRB-

obs

set

-LRB-

tick

-RRB-

send

-LRB-

detect

srv

id

loc

-RRB-

-RRB-

-LRB-

-RRB-

send

-LRB-

detect

n

p

q

-RRB-

src

n

loc

q

-LRB-

id

p

set

-LRB-

v

-RRB-

obj

p

set

-LRB-

-RRB-

-RRB-

-LRB-

-RRB-

set

-LRB-

-RRB-

obs

tick

MAX

-LRB-

-RRB-

End

Figure

Specification

of

sensors

LOCATION

MANAGEMENT

DESIGN

IN

A

FORMAL

SETTING

Based

on

the

previous

requirements

list

we

make

our

first

design

decision

following

-LSB-

-RSB-

by

using

references

to

objects

denoting

spatial

regions

instead

of

dealing

with

location

information

directly

In

this

way

each

located

object

acquires

a

new

attribute

-LRB-

loc

-RRB-

which

is

annotated

with

the

mail

address

of

an

object

representing

a

location

space

region

If

we

use

region

trees

as

described

in

Section

for

this

purpose

we

treat

both

the

dynamic

and

mutable

character

of

location

information

with

this

decision

as

an

attribute

location

information

can

always

be

changed

as

a

reference

it

does

not

constrain

the

shape

and

size

of

location

observations

We

make

however

the

simplifying

assumption

that

spatial

regions

are

disjoint

squares

due

to

the

structure

of

such

trees

In

order

to

treat

the

requirements

concerning

location

information

acquisition

and

management

we

adopt

the

specification

of

sensors

in

Figure

Each

sensor

is

created

with

knowledge

of

a

location

service

mail

address

-LRB-

srv

-RRB-

and

is

responsible

for

producing

sequential

observations

-LRB-

obs

-RRB-

of

a

named

user

-LRB-

obj

-RRB-

in

the

specific

region

Sensors

are

mobile

as

well

and

detect

themselves

in

the

monitored

region

-LRB-

and

-RRB-

We

omit

their

straightforward

generalisation

to

deal

with

the

observation

of

several

distinct

objects

Each

sensor

keeps

an

internal

clock

which

is

reset

set

-LRB-

-RRB-

after

MAX

cycles

or

when

the

user

is

observed

Axiom

guarantees

that

resets

do

not

happen

unless

this

condition

is

fulfilled

Indeterminacy

is

treated

by

this

clocking

mechanism

which

signs

to

the

location

service

that

the

user

is

unreachable

-LRB-

unreach

-RRB-

whenever

an

observation

does

not

happen

before

the

deadline

MAX

-LRB-

-RRB-

A

detect

message

with

the

user

location

is

sent

to

the

service

otherwise

-LRB-

-RRB-

Multiple

observations

are

obtained

by

having

many

sensors

dealing

with

the

same

located

object

Unintrusivity

is

also

treated

as

there

is

no

causal

connection

between

the

production

of

observations

and

user

behaviour

Actor

MobileAgent

data

types

addr

bool

-LRB-

T

F

bool

-RRB-

attributes

me

id

loc

to

addr

fwdg

bool

actions

ag

-LRB-

addr

addr

addr

-RRB-

local

extrn

birth

redir

-LRB-

addr

-RRB-

local

computation

sub

-LRB-

addr

addr

-RRB-

extrn

message

fwd

-LRB-

addr

-RRB-

mv

-LRB-

addr

addr

-RRB-

cp

-LRB-

addr

addr

addr

-RRB-

local

extrn

message

axioms

n

p

q

r

s

t

u

x

y

z

addr

ag

-LRB-

n

p

q

-RRB-

me

n

id

p

loc

q

fwdg

F

to

n

-LRB-

-RRB-

redir

-LRB-

n

-RRB-

me

p

id

q

loc

r

X

-LRB-

me

p

id

q

loc

r

fwdg

T

to

n

-RRB-

-LRB-

-RRB-

fwd

-LRB-

n

-RRB-

X

-LRB-

redir

-LRB-

n

-RRB-

-RRB-

-LRB-

-RRB-

mv

-LRB-

n

p

-RRB-

fwdg

F

me

q

id

r

X

-LRB-

redir

-LRB-

q

-RRB-

send

-LRB-

cp

n

p

q

r

-RRB-

-RRB-

-LRB-

-RRB-

mv

-LRB-

n

p

-RRB-

fwdg

T

to

q

X

-LRB-

send

-LRB-

mv

q

n

p

-RRB-

-RRB-

-LRB-

-RRB-

cp

-LRB-

n

p

q

-RRB-

loc

r

X

-LRB-

s

new

-LRB-

ag

s

s

q

r

-RRB-

send

-LRB-

fwd

p

s

-RRB-

send

-LRB-

sub

n

s

r

-RRB-

-RRB-

-LRB-

-RRB-

redir

-LRB-

n

-RRB-

fwd

-LRB-

n

-RRB-

q

-LRB-

mv

-LRB-

p

q

-RRB-

me

n

fwdg

F

-RRB-

-LRB-

-RRB-

p

new

-LRB-

ag

n

p

q

r

-RRB-

send

-LRB-

fwd

s

n

-RRB-

send

-LRB-

sub

t

n

-RRB-

cp

-LRB-

t

s

q

-RRB-

loc

r

-LRB-

-RRB-

send

-LRB-

mv

n

p

q

-RRB-

mv

-LRB-

p

q

-RRB-

to

n

fwdg

T

-LRB-

-RRB-

send

-LRB-

cp

n

p

q

r

-RRB-

mv

-LRB-

n

p

-RRB-

me

q

id

r

fwdg

F

-LRB-

-RRB-

ag

-LRB-

n

p

q

-RRB-

G

-LRB-

E

-LRB-

deliv

-LRB-

fwd

s

-RRB-

-RRB-

E

-LRB-

deliv

-LRB-

mv

t

u

-RRB-

-RRB-

E

-LRB-

deliv

-LRB-

cp

x

y

z

-RRB-

-RRB-

-RRB-

-LRB-

-RRB-

ag

-LRB-

n

p

q

-RRB-

XG

-LRB-

redir

-LRB-

r

-RRB-

E

-LRB-

fwd

-LRB-

s

-RRB-

-RRB-

E

-LRB-

mv

-LRB-

t

u

-RRB-

-RRB-

E

-LRB-

cp

-LRB-

x

y

z

-RRB-

-RRB-

-RRB-

-LRB-

-RRB-

End

Figure

Simplified

specification

of

mobile

agents

If

we

realise

the

sensors

of

Figure

as

optical

devices

connected

to

the

architecture

through

radio

frequency

links

for

instance

software

mobility

arises

only

when

located

object

agents

are

considered

Such

agents

are

meant

to

follow

located

objects

through

the

architecture

providing

location

dependent

functionality

such

as

ubiquitous

message

delivery

and

transportable

user

sessions

-LSB-

-RSB-

Although

we

leave

this

additional

functionality

unspecified

here

we

present

a

specification

of

mobile

agents

in

Figure

We

choose

to

capture

mobility

as

localised

agent

replication

A

mobile

agent

may

receive

a

request

to

move

to

the

location

of

another

agent

-LRB-

mv

-RRB-

presumably

located

closer

to

the

object

the

former

represents

If

an

agent

is

currently

moving

to

a

new

location

such

requests

will

be

delayed

by

self-forwarding

until

the

agent

finishes

to

move

-LRB-

-RRB-

In

order

to

move

the

original

agent

issues

a

request

for

the

correctly

located

agent

to

create

a

local

copy

-LRB-

cp

-RRB-

of

its

own

-LRB-

-RRB-

supplying

in

the

message

any

required

information

for

the

copy

-LRB-

here

in

particular

its

name

-RRB-

After

consuming

this

kind

of

message

an

agent

creates

the

desired

replica

and

notifies

both

the

original

agent

and

the

requesting

service

that

the

located

object

representative

can

be

substituted

-LRB-

-RRB-

In

order

to

ensure

coordination

between

sensors

and

agents

a

location

service

must

guarantee

that

the

asynchronous

messages

they

exchange

are

correctly

addressed

and

ordered

The

situation

is

better

explained

by

the

diagram

in

Figure

Once

a

located

object

is

detected

in

a

new

region

-LRB-

at

-RRB-

the

location

service

has

to

find

a

mobile

agent

in

that

region

to

request

the

creation

of

a

replica

of

the

moving

agent

there

The

location

space

is

recurrently

queried

-LRB-

in

-RRB-

until

such

an

agent

is

found

Then

the

service

requests

the

agent

of

the

relocated

object

to

move

the

place

of

the

correctly

located

agent

-LRB-

move

-RRB-

At

the

end

the

service

is

notified

-LRB-

sub

-RRB-

so

that

the

old

agent

can

be

discarded

while

h

ffifl

fflfi

ss

HHHHHj

H

H

H

H

HY

H

H

H

H

HY

ss

HHHHHj

ss

HHHHHj

Sensor

User

Continuation

Service

Old

Mobile

Agent

Correctly

Located

Mobile

Agent

New

Mobile

Agent

rep/rep

new

cnt

in/in

res/rep

in/in

res/rep

detect

at

unreach

out

mv/move

sub/done

cp

cp

Location

Space

Location

Subspace

new

ag

fwd/fwd

Figure

Internal

event

flow

of

the

Location

Manamegent

Architecture

forwarding

all

possibly

dispatched

additional

move

requests

to

the

new

agent

-LRB-

fwd

-RRB-

Since

the

location

service

has

to

associate

located

object

names

-LRB-

id

-RRB-

with

mobile

agents

has

to

keep

track

of

their

location

-LRB-

loc

-RRB-

and

has

to

put

agents

in

contact

to

support

mobility

we

consider

that

servers

providing

compartmentalised

bits

of

this

functionality

for

each

object

are

organised

in

circular

lists

adopting

the

specification

in

Figure

Each

server

also

records

if

there

is

no

location

information

available

for

the

object

-LRB-

nl

-RRB-

This

knowledge

is

used

to

postpone

answering

location

queries

-LRB-

-RRB-

until

the

object

location

becomes

known

-LRB-

and

-RRB-

Every

request

to

the

location

service

circulates

around

the

linked

list

until

the

correct

recipient

is

found

In

case

an

observation

from

a

sensor

arrives

carrying

a

new

object

location

-LRB-

at

-RRB-

a

request

for

the

rest

of

the

list

to

find

some

agent

placed

therein

is

issued

aiming

to

support

moving

to

that

location

-LRB-

-RRB-

For

each

located

object

registered

in

the

service

the

location

space

will

be

queried

in

a

two

step

process

a

continuation

actor

to

process

the

answer

of

the

query

will

be

created

-LRB-

-RRB-

and

this

new

actor

will

either

request

the

original

agent

to

move

-LRB-

-RRB-

if

the

current

agent

is

located

accordingly

or

forward

the

query

to

the

next

list

element

-LRB-

-RRB-

Although

illustrative

the

informal

description

of

the

relationship

between

each

pair

of

specifications

should

not

substitute

their

formal

composition

which

is

still

missing

here

The

diagram

in

Figure

gives

a

good

clue

on

what

remains

to

be

defined

the

physical

communication

channels

which

are

formally

defined

using

specification

morphisms

For

every

pair

of

specifications

each

of

them

represented

by

a

distinguished

geometric

figure

that

diagram

shows

how

to

relate

their

message

symbols

For

instance

the

messages

mv

and

sub

of

agents

should

be

respectively

associated

with

move

and

done

of

servers

Notice

that

relating

external

to

local

symbols

yields

the

only

possible

direction

of

the

message

flow

Also

notice

in

our

example

that

we

can

not

produce

a

direct

translation

either

from

the

theory

of

agents

into

that

of

servers

or

in

the

opposite

direction

Therefore

to

interconnect

these

entities

we

need

to

define

mediating

theory

presentations

to

serve

as

Actor

Server

data

types

addr

bool

-LRB-

T

F

bool

-RRB-

attributes

me

nxt

loc

id

ag

addr

nl

bool

actions

srv

-LRB-

addr

addr

addr

addr

addr

-RRB-

local

extrn

birth

ch

-LRB-

addr

addr

addr

bool

-RRB-

local

computation

in

-LRB-

addr

addr

-RRB-

move

-LRB-

addr

-RRB-

-LRB-

addr

addr

-RRB-

ack

-LRB-

addr

-RRB-

extrn

message

ins

-LRB-

addr

addr

addr

addr

-RRB-

done

-LRB-

addr

addr

-RRB-

res

-LRB-

addr

addr

bool

-RRB-

local

extrn

message

at

-LRB-

addr

addr

-RRB-

out

-LRB-

addr

addr

-RRB-

local

extrn

message

mvrq

-LRB-

addr

addr

addr

-RRB-

-LRB-

addr

addr

-RRB-

local

extrn

message

axioms

n

p

q

r

s

t

u

x

addr

b

bool

srv

-LRB-

n

p

q

r

s

-RRB-

me

n

nxt

p

id

q

loc

r

ag

s

nl

F

-LRB-

-RRB-

ch

-LRB-

n

p

q

b

-RRB-

me

r

id

s

nl

b

X

-LRB-

me

r

id

s

nl

b

-RRB-

-LRB-

-RRB-

ch

-LRB-

n

p

q

b

-RRB-

X

-LRB-

nxt

n

loc

p

ag

qnl

b

-RRB-

-LRB-

-RRB-

ins

-LRB-

n

p

q

r

-RRB-

nxt

s

loc

t

ag

u

nl

b!X

-LRB-

new

-LRB-

srv

x

x

s

n

p

q

-RRB-

ch

-LRB-

x

t

u

b

-RRB-

-RRB-

-LRB-

-RRB-

ins

-LRB-

n

p

q

r

-RRB-

nxt

s

X

-LRB-

new

-LRB-

srv

t

t

s

n

p

q

-RRB-

send

-LRB-

ack

r

t

-RRB-

-RRB-

-LRB-

-RRB-

done

-LRB-

n

p

-RRB-

nxt

q

X

-LRB-

ch

-LRB-

q

p

n

F

-RRB-

-RRB-

-LRB-

-RRB-

-LRB-

n

p

-RRB-

id

n

me

q

loc

r

X

-LRB-

nl

F

send

-LRB-

p

n

r

-RRB-

send

-LRB-

q

n

p

-RRB-

-RRB-

-LRB-

-RRB-

-LRB-

n

p

-RRB-

id

n

nxt

q

X

-LRB-

send

-LRB-

q

n

p

-RRB-

-RRB-

-LRB-

-RRB-

at

-LRB-

n

p

-RRB-

id

n

me

q

nxt

r

ag

s

-LRB-

loc

p

nl

T

-RRB-

X

-LRB-

send

-LRB-

mvrq

r

s

p

q

-RRB-

-RRB-

-LRB-

-RRB-

at

-LRB-

n

p

-RRB-

id

n

nxt

q

X

-LRB-

send

-LRB-

at

q

n

p

-RRB-

-RRB-

-LRB-

-RRB-

out

-LRB-

n

p

-RRB-

id

n

nxt

q

loc

r

ag

s

X

-LRB-

ch

-LRB-

q

r

s

T

-RRB-

-RRB-

-LRB-

-RRB-

out

-LRB-

n

p

-RRB-

id

n

nxt

q

X

-LRB-

send

-LRB-

out

q

n

p

-RRB-

-RRB-

-LRB-

-RRB-

mvrq

-LRB-

n

p

q

-RRB-

nxt

r

loc

s

ag

t

X

-LRB-

u

new

-LRB-

srv

u

q

r

p

n

t

-RRB-

send

-LRB-

in

s

p

u

-RRB-

-RRB-

-LRB-

-RRB-

res

-LRB-

n

p

T

-RRB-

me

q

id

r

ag

s

X

-LRB-

send

-LRB-

move

r

s

q

-RRB-

-RRB-

-LRB-

-RRB-

res

-LRB-

n

p

F

-RRB-

me

r

nxt

s

loc

t

id

u

X

-LRB-

send

-LRB-

mvrq

s

u

t

r

-RRB-

-RRB-

-LRB-

-RRB-

and

the

usual

axioms

to

guarantee

absence

of

unsolicited

responses

and

enableness

End

Figure

Specification

of

location

service

nodes

connectors

Their

nature

is

illustrated

by

the

diagram

in

Figure

To

define

the

mobile

architecture

in

a

formal

manner

we

call

each

mediating

specification

in

Figure

-LRB-

a

-RRB-

a

Connector

Each

of

them

contains

two

external

message

symbols

only

-LRB-

without

axioms

as

well

-RRB-

and

hence

translations

including

their

contents

after

necessary

renamings

into

the

connected

theories

trivially

exist

Taking

connectors

connected

theories

and

the

morphisms

betweem

them

the

composite

theory

presentations

are

defined

up

to

isomorphism

by

categorical

constructions

called

pushouts

-LRB-

amalgamed

sums

-RRB-

which

always

exist

and

are

finite

for

any

finite

number

of

actor

specifications

-LSB-

-RSB-

Defined

in

this

way

each

Component

in

the

figure

contains

all

the

renamed

symbols

and

axioms

of

the

connected

theories

but

the

symbols

identified

by

the

connectors

are

equalised

That

is

why

e.g.

a

message

move

from

servers

can

be

understood

as

mv

when

it

is

dispatched

to

an

agent

no

matter

its

name

in

the

composite

component

The

detailed

definition

of

connectors

and

their

morphisms

appears

in

Figure

-LRB-

b

-RRB-

-LRB-

b

-RRB-

Sensor

Server

detect

b

at

unreach

a

out

oe

oe

MAg

Server

mv

d

move

sub

c

done

oe

oe

Server

RTN

in

f

in

res

e

rep

oe

oe

-LRB-

a

-RRB-

AAAAK

@I

@I

@I

@I

AAAAK

@I

MobileAgent

-LRB-

MAg

-RRB-

RegionTreeNode

-LRB-

RTN

-RRB-

Server

Sensor

MobileArchitecture

-LRB-

MAr

-RRB-

Figure

Composition

of

the

architecture

Shared

actors

-LRB-

a

-RRB-

and

action

symbols

-LRB-

b

-RRB-

VERIFYING

LOCATION

MANAGEMENT

PROPERTIES

As

we

have

already

mentioned

the

existence

of

morphisms

to

connect

separated

actor

specifications

does

not

guarantee

that

interaction

between

actors

in

the

respective

communities

can

occur

Here

an

analogy

with

telecommunication

systems

is

useful

to

illustrate

the

situation

even

if

the

physical

cables

to

connect

the

private

equipment

of

a

customer

to

the

network

exist

it

can

not

receive

phone

calls

unless

assigned

to

an

appropriate

number

Therefore

logical

channels

are

also

needed

in

dealing

with

any

kind

of

global

property

These

logical

channels

are

captured

here

as

an

assumption

on

the

configuration

of

the

heterogeneous

actor

community

Since

the

location

space

is

a

relatively

separated

component

of

our

architecture

let

us

use

it

to

exemplify

how

a

property

can

be

verified

Assume

that

the

environment

always

creates

region

tree

nodes

configured

correctly

providing

the

right

name

for

the

node

and

its

parent

-LRB-

which

is

the

node

itself

in

the

case

of

the

root

-RRB-

in

the

creation

r

new

-LRB-

reg

s

t

u

-RRB-

s

t

-LRB-

u

r

u

s

-RRB-

-LRB-

-RRB-

The

main

functionality

provided

by

the

location

space

is

the

support

to

queries

Hence

every

node

s

should

eventually

answer

queries

addressed

to

it

r

send

-LRB-

in

s

t

u

-RRB-

F

-LRB-

v

x

send

-LRB-

rep

r

s

t

v

-RRB-

-RRB-

-LRB-

-RRB-

The

usual

procedure

for

proving

interaction

properties

of

actor

communities

is

-LRB-

a

-RRB-

find

a

local

invariant

of

the

recipient

-LRB-

b

-RRB-

show

that

the

invariant

guarantees

that

this

actor

will

eventually

become

enabled

for

delivery/consumption

of

the

message

-LRB-

c

-RRB-

prove

that

the

dispatch

eventually

leads

to

the

message

delivery

and

this

guarantees

the

consumption

which

in

turn

produces

the

outcome

of

the

interaction

The

reader

should

notice

that

these

steps

correspond

to

the

application

of

the

rules

COM

followed

by

RESP

both

described

in

the

Appendix

which

capture

the

fairness

requirements

of

reliable

message

passing

and

finite

consumption

delay

present

in

the

Actors

model

-LSB-

-RSB-

Returning

to

the

location

space

example

it

is

not

difficult

to

see

that

the

invariant

of

each

region

tree

node

is

Inv

-LRB-

reg

-LSB-

d

-RSB-

me

void

F

-RRB-

-LRB-

ans

-RRB-

-LRB-

-RRB-

To

prove

this

first

observe

that

Inv

is

a

precondition

for

the

occurrence

of

birth

actions

of

RTN

node

and

cnt

in

Axiom

Moreover

each

local

computation

preserves

this

property

meaning

that

occurrences

of

updt

do

not

change

the

logical

value

of

the

first

conjunct

while

keeping

ans

unmodified

according

to

and

inc

is

only

allowed

to

happen

if

the

value

of

ans

remains

in

the

interval

-LSB-

-RSB-

from

Axioms

and

An

application

of

rule

SAFE

also

described

in

the

Appendix

shows

that

Inv

always

holds

Now

suppose

that

s

the

recipient

is

an

empty

node

Let

p

as

in

rule

RESP

be

Inv

init

Since

Inv

is

invariant

its

disjunction

with

init

is

preserved

by

every

local

computation

of

the

actor

and

therefore

the

first

premise

of

that

rule

holds

In

passing

notice

that

updt

and

inc

can

not

continuously

happen

since

they

are

causally

connected

to

the

occurrence

of

split

or

rep

and

the

axiom

scheme

in

the

Appendix

says

that

such

actions

can

only

happen

one

at

a

time

From

Axiom

it

is

clear

that

p

guarantees

the

eventual

enableness

for

query

consumption

thus

the

third

premise

in

the

aforementioned

rule

also

holds

Making

q

in

the

same

rule

be

the

reply

we

can

see

from

Axioms

and

that

it

will

eventually

happen

A

similar

but

simpler

rationale

can

be

used

to

show

through

the

application

of

COM

that

once

the

query

is

dispatched

it

will

eventually

be

delivered

Chaining

these

results

we

conclude

a

step

in

the

verification

of

-LRB-

-RRB-

To

complete

the

verification

of

-LRB-

-RRB-

consider

now

those

cases

where

the

cell

has

already

been

split

and

so

answering

a

query

may

require

creating

auxiliary

continuation

actors

Verifying

such

cases

of

chained

interaction

requires

the

following

derived

rule

-LSB-

-RSB-

-LSB-

WELL

-RSB-

P

-LRB-

x

-RRB-

F

-LRB-

Q

-LRB-

y

OE

x

P

-LRB-

y

-RRB-

-RRB-

-RRB-

-LRB-

P

-LRB-

x

-RRB-

-RRB-

FQ

where

OE

is

a

well-founded

relation

We

usually

take

P

-LRB-

x

-RRB-

as

a

message

dispatch

by

an

actor

with

mail

address

x

and

Q

as

the

outcome

of

its

consumption

To

prove

the

non-trivial

case

of

-LRB-

-RRB-

we

need

to

apply

such

rule

twice

one

to

show

that

the

query

eventually

reaches

the

correct

region

or

that

all

the

location

space

terminal

nodes

are

queried

without

matching

the

parameter

of

the

message

and

the

other

to

show

that

the

reply

will

proceed

through

the

created

continuations

until

it

reaches

the

original

actor

For

the

second

case

e.g.

the

required

well-founded

relation

can

ben

taken

as

Rp

-LRB-

x

y

-RRB-

def

-LRB-

y

to

x

-RRB-

-LRB-

y

p

-RRB-

The

antireflexivity

of

Rp

derives

from

the

use

of

Axiom

in

rule

EXIT

which

shows

that

a

node

is

prevented

from

being

a

continuation

of

itself

and

since

to

is

invariant

Rp

indeed

defines

a

well-founded

relation

Therefore

we

can

apply

WELL

and

complete

the

proof

Although

we

have

omitted

this

detail

in

the

informal

proof

above

the

assumption

-LRB-

-RRB-

is

fundamental

to

ensure

that

the

answer

to

the

query

will

be

addressed

to

the

correct

actor

be

it

dispatched

by

the

recipient

itself

or

by

a

continuation

actor

It

is

also

important

to

mention

that

formally

queries

are

not

expected

to

come

from

within

the

community

of

region

tree

nodes

but

from

that

of

sensors

Due

to

the

morphisms

connecting

these

communities

to

each

other

the

complex

properties

of

the

system

can

be

decomposed

and

translated

into

lemmas

to

be

proved

in

a

localised

manner

using

the

axioms

of

just

one

theory

presentation

In

a

more

realistic

context

a

reasonable

assumption

for

our

architecture

would

consider

for

instance

that

for

every

region

there

is

a

named

server

associated

to

an

agent

and

dissociated

from

any

sensor

which

could

be

regarded

as

the

meta-level

actors

required

to

exist

in

order

to

support

resource

management

activities

-LSB-

-RSB-

in

our

case

the

access

to

some

location

The

formal

verification

of

properties

of

our

architecture

considering

these

assumptions

appears

elsewhere

Of

course

-LRB-

-RRB-

could

be

-LRB-

re

-RRB-

used

there

and

other

properties

would

be

verified

almost

in

the

same

manner

FINAL

REMARKS

In

this

paper

we

have

presented

an

approach

to

the

design

of

object-based

mobile

systems

using

a

temporal

logic

specially

tailored

to

the

Actors

model

-LSB-

-RSB-

In

-LSB-

-RSB-

we

investigated

the

requirements

the

model

poses

to

the

definition

a

logic

and

proposed

a

proof-theory

which

constrains

the

synchronous

value-passing

calculus

of

-LSB-

-RSB-

to

deal

only

with

synchronous

object

creation

and

asynchronous

message

passing

for

named

reconfigurable

objects

It

turns

out

that

this

logic

can

be

used

without

any

modification

to

capture

mobility

Basically

our

approach

consists

in

annotating

located

objects

with

an

additional

attribute

containing

a

reference

to

location

objects

as

in

-LSB-

-RSB-

The

advantage

of

approaching

mobility

in

this

extra-logical

manner

is

that

specifications

can

be

defined

in

isolation

to

be

subsequently

combined

and

global

proofs

can

be

decomposed

in

lemmas

to

be

locally

verified

much

in

the

way

we

design

any

system

using

the

same

logic

A

few

related

work

can

be

gathered

in

the

literature

In

-LSB-

-RSB-

additional

notation

is

suggested

to

treat

mobility

using

the

programming

logic

of

UNITY

-LSB-

-RSB-

During

the

refinement

process

specifications

are

augmented

with

logical

variables

to

handle

time

and

action

which

are

built

in

here

and

with

concrete

locations

As

shown

in

the

literature

there

are

many

benefits

in

using

referential

location

information

instead

-LSB-

-RSB-

In

addition

if

mobility

arises

in

a

set

of

requirements

that

approach

would

not

be

so

effective

initial

specifications

are

required

before

any

mobility

aspect

can

be

considered

In

the

process

calculi

literature

mobility

has

received

a

lot

of

attention

motivating

the

evolution

of

the

static

process

configurations

of

SCCS

-LSB-

-RSB-

to

the

dynamic

ones

of

the

ss-calculus

-LSB-

-RSB-

We

have

shown

here

that

many

applications

of

the

ss-calculus

can

be

treated

using

our

logic

For

instance

we

can

simulate

recursion

creating

continuation

actors

and

exchanging

asynchronous

messages

dynamic

data

structures

can

be

represented

as

objects

and

so

on

More

importantly

mobility

receives

a

rather

different

treatment

as

process

in

the

ss-calculus

are

modelled

as

terms

and

here

objects

are

represented

by

theory

presentations

This

is

due

to

different

design

decisions

while

it

is

relatively

easier

to

define

notions

of

simulation

and

reduction

for

processes

it

is

possible

to

specify

and

reason

about

objects

as

first-class

entities

using

the

same

more

expressive

language

which

we

feel

more

appropriate

to

represent

the

real

world

The

same

may

only

be

achieved

by

adjoining

a

modal

or

temporal

logic

to

process

calculi

It

would

be

interesting

to

compare

our

logic

to

those

presented

in

-LSB-

-RSB-

in

terms

of

expressive

power

As

a

case

study

we

presented

here

the

design

of

a

location

management

architecture

for

networks

of

mobile

users

and

devices

We

are

currently

investigating

the

occurrence

of

failures

in

this

framework

in

order

to

access

if

our

logic

is

still

convenient

for

specifying

fault-tolerant

behaviour

An

alternative

direction

for

further

work

is

to

refine

the

proposed

specifications

to

obtain

a

concrete

implementation

Refinement

theories

for

logics

of

actions

and

objects

already

exist

-LSB-

-RSB-

and

could

be

adapted

to

our

case

A

challenge

in

such

an

effort

would

be

to

achieve

a

compositional

development

process

where

the

refinement

of

components

and

interconnections

in

isolation

always

yield

an

implementation

for

the

whole

system

Acknowledgements

The

author

would

like

to

thank

two

anonymous

referees

for

their

valuable

suggestions

to

improve

an

earlier

version

of

this

paper

This

work

has

been

financially

supported

by

CNPq

the

Brazilian

National

Research

Council

REFERENCES

-LSB-

-RSB-

G.

Agha

Actors

A

Model

of

Concurrent

Computation

in

Distributed

Systems

MIT

Press

-LSB-

-RSB-

G.

Agha

I.

A.

Mason

S.

Smith

and

C.

Talcott

A

foundation

for

actor

computation

Journal

of

Functional

Programming

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

K.

M.

Chandy

and

J.

Misra

Parallel

Program

Design

A

Foundation

Addison-Wesley

-LSB-

-RSB-

C.

H.

C.

Duarte

Towards

a

proof-theoretic

foundation

for

actor

specification

and

verification

In

P.-Y

Schobbens

and

A.

Cesta

editors

Formal

Models

of

Agents

Proc

Esprit

WG

Workshop

ModelAge

pages

-LCB-

-LSB-

-RSB-

E.

A.

Emerson

Temporal

and

modal

logic

In

J.

van

Leeuwen

editor

Handbook

of

Theoretical

Computer

Science

volume

B

Formal

Models

and

Semantics

pages

-LCB-

Elsevier

-LSB-

-RSB-

J.

Fiadeiro

and

T.

Maibaum

Sometimes

tomorrow

is

sometime

Action

refinement

in

a

temporal

logic

of

objects

In

D.

Gabbay

and

H.

Ohlbach

editors

Temporal

Logic

volume

of

Lecture

Notes

in

Artificial

Inteligence

Springer

Verlag

-LSB-

-RSB-

J.

Fiadeiro

C.

Sernadas

T.

Maibaum

and

G.

Saake

Proof-theoretic

semantics

of

object-oriented

specification

constructs

In

R.

A.

Meersman

W.

Kent

and

S.

Khosla

editors

Proc

IFIP

WG

Working

Conference

on

Object-Oriented

Databases

Analysis

Design

and

Construction

pages

-LCB-

North

Holland

-LSB-

-RSB-

A.

Harter

and

A.

Hopper

A

distributed

location

system

for

the

active

office

IEEE

Network

-LRB-

-RRB-

-LCB-

January

-LSB-

-RSB-

C.

B.

Jones

Systematic

Software

Development

Using

VDM

Prentice

Hall

edition

-LSB-

-RSB-

D.

Lam

J.

Jannink

D.

C.

Cox

and

J.

Widom

Modeling

location

management

in

personal

communication

systems

In

Proc

of

Internatinal

Conference

on

Universal

Personal

Communications

-LRB-

ICUPC

-RRB-

-LSB-

-RSB-

L.

Lamport

The

temporal

logic

of

actions

ACM

Transactions

on

Programming

Languages

and

Systems

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

U.

Leonhardt

and

J.

Magee

Towards

a

general

location

service

for

mobile

environments

In

Proc

International

Workshop

on

Service

in

Distributed

and

Networked

Environments

-LRB-

SDNE

-RRB-

June

-LSB-

-RSB-

R.

Milner

Calculi

for

synchrony

and

asynchrony

Theoretical

Computer

Science

-LCB-

-LSB-

-RSB-

R.

Milner

J.

Parrow

and

D.

Walker

A

calculus

of

mobile

processes

I

and

II

Information

and

Computation

-LRB-

-RRB-

-LCB-

and

-LCB-

September

-LSB-

-RSB-

R.

Milner

J.

Parrow

and

D.

Walker

Modal

logics

for

mobile

processes

Theoretical

Computer

Science

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

H.

Samet

The

quadtree

and

related

hierarchical

data

structures

ACM

Computing

Surveys

-LRB-

-RRB-

-LCB-

June

-LSB-

-RSB-

J.

M.

Spivey

The

Z

Notation

A

Reference

Manual

International

Series

in

Computer

Science

Prentice-Hall

-LSB-

-RSB-

M.

Spreitzer

and

M.

Theimer

Architectural

considerations

for

scalable

secure

mobile

computing

with

location

information

In

Proc

International

Conference

on

Distributed

Computing

Systems

pages

-LCB-

IEEE

Computer

Society

Press

June

-LSB-

-RSB-

N.

Venkatasubramanian

and

C.

Talcott

A

meta

architecture

for

distributed

resource

management

In

Proc

Hawaii

International

Conference

on

System

Sciences

pages

-LCB-

IEEE

Computer

Society

Press

January

-LSB-

-RSB-

C.

D.

Wilcox

and

G.-C

Roman

Reasoning

about

places

times

and

actions

in

the

presence

of

mobility

IEEE

Transactions

on

Software

Engineering

-LRB-

-RRB-

-LCB-

April

APPENDIX

We

provide

here

the

set

of

axiom

schemes

and

inference

rules

which

make

our

logic

suitable

for

specifying

and

reasoning

about

actor

communities

These

are

meant

to

particularize

the

axiomatisation

of

the

underlying

many

sorted

first

order

branching

time

temporal

logic

with

equality

adopted

As

in

-LSB-

-RSB-

we

also

require

that

variables

are

rigid

attributes

have

a

functional

time-dependent

interpretation

and

actions

denote

atomic

events

The

reader

is

referred

to

-LSB-

-RSB-

for

further

details

Definition

-LRB-

Axiom

Schemes

-RRB-

Given

an

actor

specification

-LRB-

-LRB-

A

-RRB-

-RRB-

the

following

are

logical

axiom

schemes

for

actors

W

vc

n

c

-LRB-

vc

-RRB-

V

vf

k

n

f

-LRB-

vf

-RRB-

k

X

-LRB-

n

f

-LRB-

vf

k

-RRB-

-RRB-

V

-LRB-

e?eb

-RRB-

-LSB-

-LRB-

l?lb

-RRB-

vc

beg

G

-LRB-

init

-RRB-

V

vcaddr

-LSB-

W

ait

-LRB-

n

send

-LRB-

c

vc

-RRB-

-RRB-

V

vc

beg

-LRB-

n

deliv

-LRB-

c

vc

-RRB-

-RRB-

W

-LRB-

n

init

-RRB-

V

-LRB-

l?lb

-RRB-

-LSB-

c

vc

beg

-LRB-

n

c

-LRB-

vc

-RRB-

-RRB-

W

-LRB-

n

init

-RRB-

V

-LSB-

lb

vc

beg

G

-LRB-

init

-RRB-

V

vcaddr

-LSB-

W

ait

-LRB-

n

new

-LRB-

c

vc

-RRB-

-RRB-

V

beg

G

-LRB-

vc

E

-LRB-

new

-LRB-

c

vc

-RRB-

-RRB-

-RRB-

V

vc

-LRB-

new

-LRB-

c

vc

-RRB-

X

-LRB-

c

-LRB-

vc

-RRB-

-RRB-

-RRB-

-LRB-

c

-LRB-

vc

-RRB-

i

new

-LRB-

c

vc

-RRB-

-RRB-

V

c

c

vc

new

-LRB-

c

vc

-RRB-

vd

-LRB-

-LRB-

vc

-RRB-

new

-LRB-

c

-RRB-

-RRB-

new

-LRB-

d

vd

-RRB-

V

c

c

vc

n

deliv

-LRB-

c

vc

-RRB-

vd

-LRB-

vc

n

deliv

-LRB-

c

-RRB-

-RRB-

n

deliv

-LRB-

d

vd

-RRB-

V

c

-LRB-

l?lb

-RRB-

-LSB-

c

=d

vc

n

c

-LRB-

vc

-RRB-

vd

-LRB-

vc

n

c

-LRB-

-RRB-

-RRB-

n

:d

-LRB-

vd

-RRB-

where

W

ait

-LRB-

n

g

-RRB-

-LRB-

g

-RRB-

W

-LRB-

init

-RRB-

-LRB-

g

-RRB-

W

-LRB-

Acq

-LRB-

n

-RRB-

-RRB-

Acq

-LRB-

n

-RRB-

W

vd

-LRB-

deliv

-LRB-

d

vd

-RRB-

n

vd

-RRB-

W

vd

-LRB-

d

-LRB-

vd

-RRB-

n

vd

-RRB-

W

-LSB-

lb

vd

new

-LRB-

d

n

vd

-RRB-

The

first

scheme

says

that

each

actor

has

encapsulated

state

only

its

local

computations

can

change

attribute

values

The

next

four

schemes

say

that

either

an

actor

is

not

created

within

a

community

or

dispatch

delivery

and

consumption

of

messages

plus

local

computations

and

requests

for

creation

do

happen

before

its

birth

Notice

that

the

second

and

fifth

schemes

are

more

liberal

if

the

actor

is

never

created

but

are

more

restrictive

otherwise

requiring

actor

names

to

become

known

first

due

to

delivery

of

a

message

the

birth

of

the

source

or

the

creation

of

the

target

before

they

could

be

used

in

the

task

The

sixth

scheme

says

that

it

is

always

possible

to

create

some

new

actors

and

the

seventh

states

that

requests

for

creation

and

actual

births

are

causally

connected

The

last

three

schemes

constrain

concurrency

i.e.

that

actors

can

not

be

simultaneously

created

with

the

same

name

that

messages

can

not

be

delivered

in

parallel

to

the

same

actor

and

that

messages

and

local

computations

can

not

be

processed

at

the

same

time

the

last

axiom

being

supplied

only

to

simplify

specification

and

reasoning

Definition

-LRB-

Rules

of

Inference

-RRB-

Given

an

actor

specification

-LRB-

-LRB-

A

-RRB-

-RRB-

the

following

are

inference

rules

for

deriving

properties

of

existing

actors

where

each

p

and

q

is

an

arbitrary

formula

over

a

single

actor

and

n

and

m

are

terms

of

sort

addr

-LSB-

EXIST

-RSB-

new

-LRB-

d

m

vd

-RRB-

p

q

W

vc

n

new

-LRB-

c

m

vc

-RRB-

d

lb

XG

-LRB-

p

q

-RRB-

-LSB-

SAFE

-RSB-

V

vc

n

c

-LRB-

vc

-RRB-

q

V

vc

n

c

-LRB-

vc

-RRB-

q

Xq

Gq

-LSB-

INV

-RSB-

V

vc

n

c

-LRB-

vc

-RRB-

q

Xq

q

Gq

-LSB-

RESP

-RSB-

V

vc

n

c

-LRB-

vc

-RRB-

p

X

-LRB-

p

n

:d

-LRB-

vd

-RRB-

-RRB-

n

:d

-LRB-

vd

-RRB-

Fq

p

FE

-LRB-

n

:d

-LRB-

vd

-RRB-

-RRB-

d

l?lb

n

deliv

-LRB-

d

vd

-RRB-

X

-LRB-

Fp

Fq

-RRB-

-LSB-

COM

-RSB-

V

vc

n

c

-LRB-

vc

-RRB-

p

X

-LRB-

p

n

deliv

-LRB-

d

vd

-RRB-

-RRB-

n

deliv

-LRB-

d

vd

-RRB-

Fq

p

FE

-LRB-

n

deliv

-LRB-

d

vd

-RRB-

-RRB-

d

l?lb

send

-LRB-

d

n

vd

-RRB-

X

-LRB-

Fp

Fq

-RRB-

The

rule

EXIST

based

on

the

fact

that

an

actor

name

can

not

be

reused

once

it

is

given

to

some

actor

guarantees

a

local

safety

property

from

the

configuration

of

the

actors

in

the

environment

SAFE

and

INV

are

the

usual

rules

for

verifying

local

safety

and

invariance

properties

Rules

COM

and

RESP

capture

the

fairness

requirements

for

actors

and

are

to

verify

that

a

delivery

or

a

message

consumption

eventually

happen

due

to

an

interaction

if

the

actor

ever

becomes

enabled

for

a

similar

task

in

the

future

actors
location management
mobile systems
specification
verification