Software Platforms for Mobile Distributed Systems

Transcription

1 Sftware Platfrms fr Mbile Distributed Systems Rakesh Plepeddi #1, Kushik Vanama *2 Department f CSE, K.L.E.F (K.L.U), Green Fields, Vaddeswaram. Abstract: As a result f the cmputing technlgy that becmes ever smaller and cheaper it is nw pssible t integrate it int everyday material bjects. This advanced integratin f technlgy allws the underlying cmputer t disappear int the fabric f life s that by manipulating material bjects we are transparently interacting with the underlying integrated technlgy. The inventin f wireless cmmunicatin technlgy enables these disappearing integrated cmputers t cperate with ne anther s that they can derive cntext abut its envirnment. The advantage is that users can be supprted mre naturally and transparently t achieve their gals. This visin is ften referred t as Ambient Intelligence (AmI). The research presented in this dissertatin deals with the prblem f sftware develpment fr these invisible cmputers frm the perspective f distributed systems. Keywrds: distributed systems, cncurrency distributin, library apprach, integrated apprach. I.INTRODUCTION Much f the emerging behavir in ubiquitus cmputing scenaris results frm the cperatin between devices. These devices can cperate because they are surrunded by what is smetimes referred t as a mbile netwrk. A mbile netwrk emerges frm a set f devices that cmmunicate ver wireless cmmunicatin media. The systems that result frm such a hardware cnstellatin are called mbile distributed systems. A mbile distributed system explicitly supprts mbile cmputing. Mbile cmputing cncerns the cmputatin that is carried ut in mbile devices. Mbile cmputing shuld nt be cnfused with mbile cmputatin, which cncerns the mbility f cde between devices. In this dissertatin we fcus n mbile cmputing. The evaluatin f distributed prgramming platfrms in the cntext f mbile distributed systems. One f the evaluatin criteria is hw they integrate with the bject-riented paradigm. II.TYPES OF MOBILE DISTRIBUTED SYSTEMS In this sectin we examine the cmmnalities and the differences f fixed and mbile distributed systems by means f a cnceptual framewrk. Definitin (Distributed System) A distributed system cnsists f hardware and sftware cmpnents lcated at netwrked cmputers that cmmunicate and crdinate their actins nly by message passing. Frm this definitin we can zm in n three facets f distributed systems: Type f Device: In the definitin abve the term netwrked cmputer can refer t a fixed device r a mbile device. Fixed devices range frm desktp cmputers and server racks t electrnics embedded in statinary bjects such as a washing machine. On the ther hand, mbile devices can vary between laptps, PDAs, mbile phnes and ther electrnics embedded int mbile items, such as a wrist watch. Type f Netwrk Cnnectin: The wrd cmmunicatin refers t the netwrk infrastructure and this is the basis fr anther difference between fixed and mbile f distributed systems. On the ne hand, in fixed distributed systems cmputers are ften cnnected via permanent links. These links are ften high bandwidth and supprted by redundant infrastructure such that cnnectins are relatively stable. Hence, discnnectins are either caused by scheduled maintenance r unfreseen failures. On the ther hand, mbile distributed systems are usually cnnected via a wireless cmmunicatin link ver wireless technlgies such as Bluetth, Wireless Fidelity and GPRS. These wireless technlgies are prne t discnnectins due t the limited cmmunicatin range f these technlgies. When users mve abut with their mbile devices they leave and enter the cmmunicatin range f ther devices in the envirnment, but even when tw wirelessly cmmunicating devices are statinary the link can be brken due t a radi cclusin caused by the envirnment, such as a car that passes in between the tw cmmunicating devices. The cmmunicatin ISSN: Page393

2 range is ften further reduced by the limitatins f the pwer surce. The general rule is: the less pwer is available fr the wireless link the smaller the cmmunicatin range f the wireless link. Of curse there are ther issues that can greatly influence the quality f the wireless link such as the type f antenna that is used. An example f this is the quality f cnversatins ver a mbile phne which are at times prblematic even thugh there are a great number f antennas psted thrughut many cities nwadays. Anther surce fr discnnectins are caused by the use f a finite pwer surce in a mbile device. When a battery f a mbile device is discharged then the device stps functining and active cnnectins are lst r wireless links may be manually r autmatically turned ff t cnserve battery pwer. Frm this we can cnclude that mbile distributed systems are intermittently cnnected as ppsed t fixed distributed systems that usually have permanent links. Type f Executin Cntext: Anther facet that is maybe less explicit in the definitin abve is the executin cntext f a distributed system. With the term executin cntext we refer t the cntext infrmatin that can influence the behavir f an applicatin. Typically in fixed distributed systems the executin cntext is mre static than with the mbile variants. Fr example, the quality f a cnnectin can depend n the envirnment in which mbile devices cmmunicate while the quality f a cnnectin in a fixed distributed system is ften cntinuusly stable. Anther imprtant type f executin cntext that is influenced by the lcatin f mbile devices is the availability f services. In mbile distributed systems the availability f services ften cincides with the lcatin f the mbile device, whereas in a fixed distributed system services are ften cntinuusly available fr an applicatin. Ubiquitus cmputing scenaris entail that cmputing technlgy is embedded in all types f devices, ranging frm washing machines and refrigeratrs t cars, clthes and wrist watches. It is clear hwever, that mst f the cperatin between these devices will ccur ver wireless cmmunicatin media. Namely, wireless cmmunicatin media makes the users blivius t the cmputing technlgy in the face f mbility. Based n this cnceptual framewrk f distributed systems we can further distinguish between tw types f different mbile distributed systems: Nmadic distributed systems have a mix f fixed and mbile characteristics. A nmadic distributed system is built ut f fixed and mbile devices that interact and cperate via infrastructure. This infrastructure can be cmpsed f wireless access pints that are themselves cnnected via a fixed netwrk. An example f such a distributed system is a mbile phne netwrk, where each phne cnnects t an antenna and the different antennas are cnnected via cables. As users mve abut with their mbile phne the cnnectin is transparently carried ver frm ne antenna t anther. Ad-hc mbile distributed systems cnsist f a set f mstly mbile devices that are cnnected via extremely variable quality links and execute in dynamic envirnments. Fr example, mbile devices can be cmpletely islated frm ther devices and grups f cmmunicating mbile devices may spntaneusly emerge in the envirnment. Ad-hc mbile distributed systems further distinguish themselves frm their nmadic variants in that there is n infrastructure that supprts the cmmunicatin between devices. Such a netwrk that emerges due t the mbility f the mbile hsts is ften called a mbile ad-hc netwrk. Bth types f mbile distributed systems, discussed abve, can be used t realize ubiquitus cmputing scenaris. Fr example, nmadic distributed systems can be useful t realize ubiquitus cmputing scenaris in the cntext f a restricted envirnment such as an ffice space r at hme. Nevertheless, the visin f ubiquitus cmputing is nt a delimited cncept that starts in a restricted envirnment and stps when yu leave it. Fr this reasn ad-hc mbile distributed systems are needed t further supprt the scenaris that cntinue utside f restricted envirnments such that n assumptins n the available infrastructure can be made. III.CONCURENCY AND DISTRIBUTION Althugh cncurrency and distributin are theretically nt the same, the implementatin f a distributed system is almst always cncurrent. As a cnsequence a gd cncurrency mdel is the fundatin f a mdel fr distributin. In this sectin we review these aspects in the light f mbile distributed systems and the subsequent hardware phenmena. This insight is imprtant because it influences design decisins f the distributed languages and middleware that are discussed in the subsequent sectins. A. Denting Parallel Units in Prgramming Languages A first imprtant cncept that we find in sftware is the ability t spawn parallel activities. A parallel activity is expressed as a parallel unit. Such a unit can ISSN: Page394

3 range frm a prcess t the level f expressins. 1) Prcesses and Threads: Prcesses are perhaps the mst frequently used unit f parallel activity. Many perating systems run each prgram in a separate prcess. Prcesses have their wn state and data, hence n memry is shared between prcesses. Within such a prcess it is pssible t create multiple threads. In cntrast t prcesses, threads can share memry and allw fr mre fine-grained parallel activity. In mst mainstream languages threads are created dynamically and terminate when the tp-level prcedure they are executing returns. Hwever, ften sme functinality is prvided t abrt a thread such that it terminates befre this tp-level prcedure has returned. 2) Objects: There are several ptins t intrduce parallel activity nt bjects. In a sequential bjectriented prgramming language bjects interact via message passing. An bject sends a message t itself r anther bject and waits until the receiving bject has prcessed the message and returns cntrl back t the sender. This is ften paired with a value that is returned t the sender. Fur different ptins t map parallelism nt an bject: Attach a thread t an bject and the bject can be active withut having received a message. Allw the bject t cntinue its executin after it has sent the message. In ther wrds, an bject sends a message and cntinues its executin withut waiting fr the receiver t have cmpleted prcessing the message. Instead f sending the message t a single destinatin the message can be sent t multiple bjects that each prcess the message in parallel. The sender waits until the different receivers have finished executing the message. The receiving bject cntinues executing after it has returned cntrl t the sender. Making a chice between these ptins invlves a number f cnsideratins. Fr example, the first ptin des nt integrate well with the paradigm f bject rientatin since bjects are n lnger slely activated by means f message passing. These and ther integratin cnsideratins are discussed in integrative apprach. 3) Expressin and Statements: The mst fine-grained unit f parallelism is expressed at the level f expressins and statements. Fr example, in Occam it is pssible t declare the parallel executin f a number f statements using the PAR keywrd. Parallelism at the level f statements r expressins is easy t understand and use but difficult t maintain in large applicatins, because it is mre fine-grained. B. Design Issues in Cmmunicatin After having discussed the different ways f intrducing parallelism in prgramming languages we can nw turn ur attentin t the way ne lgically distributed parallel unit cmmunicates with anther by message sending. There are fur imprtant characteristics that must be cnsidered fr the cmmunicatin between parallel units in the cntext f distributed systems. These characteristics are further discussed belw. Characteristic #1: Addressing Parallel Units A first cnsideratin is hw t address distributed parallel units. Addressing a parallel unit can be either direct r indirect. A parallel unit is addressed directly when its cmmunicatin partner addresses it explicitly. An example f this explicit addressing are remte bject references, where an bject is directly referred t by anther bject. On the ther hand, indirect addressing f a parallel unit ccurs when its sender des nt refer t it directly, but instead refers t an abstract intermediary cmmunicatin partner that in its turn refers t the parallel unit that needs t be addressed. Nte that indirect addressing ffers greater flexibility and a higher level f abstractin that can be useful t deal with the ever-changing envirnment in which mbile devices are used. Characteristic #2: Implicit vs Explicit Cmmunicatin Once a parallel unit can be addressed it is pssible t cmmunicate with it. A parallel unit sends a message that is received by anther parallel unit. Sending a message is usually always explicit in the cde, but receiving a message can be either implicit r explicit. Fr example, when a methd is invked n a remte bject in Java RMI, then this methd invcatin is implicitly accepted. The bject des nt have t accept the message explicitly. Occam is a language where messages are accepted explicitly. In Occam syntax is prvided such that a prcess can explicitly listen t a channel fr a message. Characteristic #3: Cmmunicatin Timing Anther imprtant decisin is whether t use synchrnus r asynchrnus cmmunicatin between parallel units. ISSN: Page395

4 Definitin (Synchrnus Cmmunicatin) The sender and the receiver bth synchrnize at every message. Definitin (Asynchrnus Cmmunicatin) The sender des nt wait fr the receiver t be ready t accept its message. Asynchrnus cmmunicatin with rendezvus: The sender f a message blcks until it has received an acknwledgment frm the receiver that is has been received. Hwever, the sender des nt wait until the message has been prcessed. Asynchrnus cmmunicatin with FIFO rder: The sender f a message is guaranteed that the messages it sent t a receiver are received in the rder it has sent them. Asynchrnus cmmunicatin withut rder guarantee: Messages sent by a parallel unit can be received in any rder, irrespective f the rder in which the messages were sent. An example f a lw level messaging prtcl with such semantics is UDP. The latter tw types f asynchrnus cmmunicatin match well with inherently asynchrnus distributed systems such as the nes fund in mbile distributed systems, because they allw ne t abstract frm unavailable devices such that the autnmus nature f devices is nt hampered. Characteristic #4: Reliability There are several degrees f reliability that can be guaranteed when cmmunicating. Fr example, n the ne end when cmmunicating using UDP there are n delivery guarantees made t the sender f a message. If a message is lst in transit it will never arrive at its destinatin. On the ther hand, the sender f a message can cntinuusly retry sending a message until it receives an acknwledgment that the message has been received. Between these tw extremes there are appraches that prvide sme fault tlerance t a limited extent. An example f this is the TCP/IP prtcl, which is frequently used fr cnnectins ver the internet. In any case, there is n single strategy that is suitable fr all distributed applicatins. Hwever, in the case f mbile distributed systems, where vlatile cnnectins are the rule rather than the exceptin care must be taken in making the crrect chice. Nte that the degree f reliability is independent frm the cmmunicatin timing. On the ne hand, synchrnus cmmunicatin can be made reliable by blcking the sender and meanwhile retrying t send the message. On the ther hand asynchrnus cmmunicatin can be made reliable by transparently resending a message until an acknwledgment has been received. C. Crllaries f Mbile Distributin Abve, we have discussed fundamental cncepts fund in distributed systems and hw these cncepts can be translated int prgramming language cncepts. We can nw revisit the cnsequences f these chices in the cntext f mbile distributin. 1) Nn-deterministic interactins: Nn-deterministic interactins are a distinct characteristic f distributed systems and are a cnsequence f the use f multiple independent machines (which have their wn internal clck and speed) that are acting n a shared resurce. An imprtant insight is that the type f cmmunicatin determines t a large extend the degree f nn-determinism that can ccur. Fr example, suppse a distributed bunded buffer bject. The buffer is accessed by a single prducer and multiple cnsumers. This example can be used t cmpare synchrnus cmmunicatin with and withut an explicit receive statement. One prblem is what happens if the buffer is empty. In the case f an explicit receive statement in Occam fr example, the buffer can execute a statement: writer? element. In this case the buffer bject will wait explicitly until the writer has sent an element. In the case f a cmmunicatin mdel withut an explicit receive statement methds f the buffer bject are executed in the rder they are received. This rder is dependent n the internal clck f the cnsumers and the prducer and the quality and speed f the cnnectin, which are variable and cannt be predicted. Hence, the frmer cmmunicatin type is mre deterministic than the latter. Hwever, when cmparing synchrnus cmmunicatin t nnblcking cmmunicatin we find that the latter frm intrduces even mre nn-determinism. The extra degree f nn-determinism is caused by the fact that cmputatin is cntinued immediately after sending a message irrespective f whether the message has been accepted. Nn-determinism can be reduced by intrducing synchrnizatin mechanisms in the cncurrency mdel such that the prgram can maintain a cnsistent state. Asynchrnus cmmunicatin decuples the sender frm the receiver and therefre behaves better with respect t the autnmus nature f devices in a mbile distributed system. ISSN: Page396

5 2) Partial Failures: Als, mbile devices can fail temprarily due t batteries that are drained. Failures are generally a hard prblem in the cntext f distributed cmputatin. In a distributed system a cmpnent (netwrk link r device) can fail while the ther cmpnents in the system are unaffected and cntinue their cmputatin, hence the name partial failures. In a distributed system a failure generally cannt be detected accurately. Failures are nwadays mst ften detected based n timeuts. The prblem is that timeuts are nly an estimatin. Latencies f messages can vary based n the lad f the netwrk and the machine, such that a message that is cnsidered t be lst because n reply has been received within a certain time interval culd still be prcessed and return the reply t late. It is als pssible that a message has been received by a nde, but that the link failed just befre a reply can be sent. This makes it generally impssible fr a sender t determine whether a message that is cnsidered t be lst has actually been received. As a cnsequence, when such failures are dealt with by sending messages twice it is pssible that messages are received multiple times. It is als generally impssible fr the sender t determine which cmpnent has failed. Either the device r the netwrk link culd have failed. Current mainstream distributed mdels, such as the nes fund in CORBA r ther remte methd invcatins schemes deal with such partial failures by prpagating exceptins. Hwever, in mbile netwrks vlatile cnnectins are the cmmn rule rather than the exceptin. As a cnsequence prgramming mbile distributed systems in such mdels is hard. A number f cnceptual slutins have been develped t deal with failures in distributed systems. The mst imprtant nes are (distributed) transactins and replicatin. A transactin guarantees the atmic executin f a set f actins in the face f failures. Atmic executin means that either all actins are serially executed r nne f them at all. Anther slutin t deal with partial failures is replicatin. Replicatin is used t ensure the availability f services in a netwrk by duplicating them n multiple machines in the netwrk such that when a machine r netwrk link fails the service remains available n ther ndes. Hence, replicated services try t hide netwrk failures. Other techniques are mre applicatin specific. Fr example, when a device crdinating distributed cmputatins fails a new crdinatr culd be elected. Althugh these techniques have prven useful in the cntext f fixed distributed systems, the prtcls assciated with these techniques generally d nt scale t mbile distributed systems. This is mainly because these prtcls typically rely n centralized crdinatin and expect failures t be rare and f shrt duratin. An example is the 2 phasecmmit (2PC) prtcl used t supprt distributed transactins. In the 2-phase cmmit prtcl there is a crdinatr that asks all participants in a distributed transactin if they are able t cmmit the actins assciated t the distributed transactin. The participants in the transactin answer Yes r N. If the crdinatr receive a Yes frm all the participants then it sends a cmmit instructin t all participants. If any ne f the participants answers N then the crdinatr sends an abrt instructin t all participants t all ther participants. The result is that the transactin is either cmmitted as a whle r nt at all. Nte that this scheme nly wrks because a participant that answered Yes, cannt change this decisin until it receives either a cmmit r abrt message frm the crdinatr. Hence, if the cnnectin between the crdinatr and the participants fails after a number f participants vted Yes, then these participants cannt perfrm any peratin that wuld render its vte invalid. In a fixed distributed system, where failures are exceptinal and systems can be clsely mnitred fr failures, such prblems can be slved in an acceptable time frame. This is in cntrast t the failures encuntered in mbile distributed systems that are due t vlatile cnnectins. Vlatile cnnectins are cmmn and the time t restre a cnnectin can be directly related t the mbility f a user. IV.OBJECTS VS CONCURRENCY AND DISTRIBUTION Abve we have discussed hw cncurrency and distributin cncepts can generally be addressed in sftware. We have als discussed the cnsequences f these chices in the cntext f mbile distributed systems. Nw that we have dne this we can turn t a specific paradigm t express cncurrency and distributin. The bject-riented prgramming paradigm prvides a gd fundatin fr dealing with distributin and cncurrency, because it successfully aligns encapsulated bjects with cncurrently running distributed sftware entities. Hwever, there are a number f different appraches hw distributin and cncurrency issues can be expressed in the paradigm. These appraches are discussed in the fllwing subsectins. A. The Library Apprach Distributin and cncurrency primitives are encapsulated and are mdeled using the bject-based ISSN: Page397

6 techniques. Using aggregatin and inheritance the primitives can then be integrated in the applicatin. In this apprach is that tw kinds f bjects are used. One kind is used t express the slutins t the issues assciated with the cncurrency and distributin, while anther kind is used t mdel the dmain cncepts in the prgram. Bth kinds f bjects smetimes need t be mixed t implement the crrect slutin. An example f this is the Thread class fund in many libraries fr intrducing cncurrency in an bject riented language. This example illustrates hw cncurrency and dmain cncepts are cmpsed tgether based n the inheritance relatinship. The cmpsitin f tw different kinds f bjects generally results in tw prblems. A first prblem with this apprach is that the distinctin between dmain bjects and bjects that deal with cncurrency and distributin issues is bfuscated. A secnd prblem with this apprach is that the library, as in the example abve, smetimes enfrces a structure nt bjects that mdel dmain cncepts such that mdularizing dmain cncepts can becme impssible. A direct cnsequence f this is that the extensibility f the different kinds f bjects becmes mre difficult after they have been cmpsed. B. The Integrative Apprach The integrative apprach aims t align cncurrency and distributin cncepts with the bject paradigm. The integratin is achieved by merging sme f the cncurrency and distributin cncepts with the cncepts fund in the bject paradigm. This apprach alleviates sme f the prblems fund in the library apprach. First, since majr cncurrency and distributin aspects are merged with cncepts f the bject paradigm the prgrammer has t deal with less cncepts. This enhances the understandability f the cncurrency and distributin aspects f the prgram. Secnd, there is less need t manage the cncurrency and distributin aspects f a prgram, prvided the bject paradigm is aligned intuitively with the cncurrency and distributin cncepts. The three main dimensins alng which cncepts can be merged are discussed belw. 1) Object and Prcess: The integratin f an bject with a prcess leads t the ntin f an active bject. The tw cncepts can be unified because bth can be regarded as an encapsulated unit that can cmmunicate with thers. An bject can have nne, ne r multiple prcesses assciated with it. An bject that des nt have any prcess assciated with it is smetimes called a passive bject. The number f prcesses assciated with an bject gives rise t different types f bject-level cncurrency: Serial r atmic: nly ne message is cmputed at a time. Quasi-cncurrent: multiple bject activatins within an bject can exist at a single pint in time. Nevertheless, at mst ne activatin can be executing at a time. The ther activatins must be suspended at that time. Cncurrent: multiple unsuspended activatins can be present at a single pint in time. Hwever, certain restrictins n the cncurrency may exist. These restrictins are necessary t maintain a cnsistent state. Fully cncurrent: is the same as cncurrent bjects but withut any cncurrency restrictins. Fully cncurrent bject mdels are functinal by nature s that state des nt change during a methd executin and n incnsistent state can ccur. An imprtant issue with regard t the different types f bject-level cncurrency is maintaining a cnsistent state. Quasi-cncurrent and cncurrent bjects are susceptible t race cnditins at the level f individual instructins within a methd, because cncurrent bject activatins within the same bject can result in a nn-deterministic interleaving f instructins. On the ther hand, serial and fully cncurrent bject mdels cannt have race cnditins at the level instructins f a methd. In the case f serial bjects race cnditins can still ccur at the level f interactins. They give the example f a cunter bject with set and get methds. Clients want t increment and decrement the cunter using these methds. Due t the nn-deterministic interleaving f the get and set methds updates can get lst. Suppse the cunter is initialized at zer and tw clients want t increment the cunter by ne. Cnsider the fllwing schedule: bth clients request the state f the cunter and in bth cases the result returned will be zer. Next, bth clients update the state f the cunter and set it t the result f the get invcatin incremented by ne. The resulting state f the cunter is ne. Hence, ne cunter update can be lst due t the nn-deterministic interleaving f messages. Nw that we have discussed the different levels f cncurrency that can exist within an bject we can turn t hw cncurrency can be initiated in the bject paradigm. There are tw appraches bjects can be activated: reactive vs. autnmus activatin. In the case f reactivity bject activatin cincides with methd invcatin. A message is sent t an bject and the bject is activated by this message. In the ISSN: Page398

7 case f autnmy an explicit prcess is assciated with a cncurrent bject. The bject starts running frm the mment it is created, with little r n regard t external events. The bject paradigm naturally matches better with reactive bject activatin, but autnmus activatin usually gives mre finegrained cntrl ver the cncurrency issues. Fr example, autnmus activatin ffers cnstructs that allw an bject t explicitly receive messages, whereas reactive bject mdels are ften based n implicit message acceptance hence, when integrating prcesses and bjects a chice has t be made whether the active bject preserves the reactivity principle r whether an autnmus bject system is adpted. 2) Object Activatin and Synchrnizatin: A secnd type f integratin merges the methd invcatin and prcess synchrnizatin cncepts. Merging bth cncepts gives rise t the ntin f a synchrnized bject. When multiple prcesses are executing in parallel and wrking n shared resurces there is a need t synchrnize parts f a prgram such that it exhibits the crrect semantics and prevent that the cncurrent accesses lead t an incnsistent state. There are tw levels at which synchrnizatin can be integrated with cncepts frm the bject paradigm: 3) Message Passing Level Synchrnizatin: In a sequential bject riented language the sender f a message waits fr the receiver t execute the message and return the result f the methd invcatin. This same mechanism can be used t intrduce synchrnizatin between active bjects and is als knwn as synchrnus message passing. An active bject can send a message t anther active bject and wait until that bject has prcessed the message and sent back the return value. Message passing frms a natural means t synchrnize tw cncurrently executing bjects such that the resulting semantics remains clse t sequential semantics. Hwever, in a mbile distributed system, where the latency f messages sent between bjects can be high such semantics can harm the autnmus nature f devices. A variant that hides the latency f bjects is asynchrnus message passing. In this case the sending active bject des nt wait until the message it sent is actually delivered r even prcessed. An issue that cmplicates the use f asynchrnus message passing are return values. After all, when an active bject des nt wait until the called has prcessed the result it cannt return the result. Typically callbacks are used t prcess the return values f asynchrnus messages, but methds that are used as a callback clutter the cde since fr each different cntext in which an asynchrnus message is used a callback methd needs t be implemented. Anther disadvantage f callback methds is that they break the flw f a typical bject-riented prgram and harm the readability and understandability f the prgram. T vercme this prblem a linguistic abstractin, called futures r prmises, have been prpsed and implemented in a number f prgramming languages. 4) Object Level Synchrnizatin: Smetimes mre explicit synchrnizatin cntrl is needed that cannt be expressed slely at the message passing level. The necessary degree f cntrl ver the synchrnizatin is related t the degree f bject-level cncurrency: Intra-Object synchrnizatin: when multiple bject activatins within ne methd can be active at a single pint in time there is a need t ensure the cnsistency f the internal state f the bject. Usually, there is a need t specify which methds need t be executed in a mutually exclusive fashin. Nte that in a serial active bject all methds are mutually exclusive by definitin. Althugh such a serial active bject might be cnsidered less expressive, because it restricts the degree f parallelism, it has the benefit that it eliminates incnsistent states that result frm cncurrent accesses t the internal state f an bject. Behaviral synchrnizatin: It may be pssible that an bject, depending n its current state, is temprarily unable t perfrm methds that are part f its interface. A typical example is a queue that when empty cannt execute an enqueue methd invcatin until a dequeue methd is executed. Inter Object synchrnizatin: Smetimes synchrnizatin is necessary between a set f bjects t perfrm a certain task. An example f such a mre glbal synchrnizatin is that f a distributed transactin where a hirearchy f bjects are invlved t atmically perfrm tasks. An example f this type f synchrnizatin is a banking applicatin where ne accunt must be credited while a number f ther accunts must be debited atmically. Mre cmplex synchrnizatin schemes are needed t achieve such synchrnizatin. The integrative apprach minimizes the number f cncepts by integrating and unifying cncepts f distributin and cncurrency. This apprach has the advantage that the aspects f distributin and cncurrency are mre naturally dealt with and are easier t master. Hwever, the integrative apprach lacks adaptability and flexibility f the cncurrency and distributin cncepts ffered by the library apprach. In ther wrds, the cncurrency and ISSN: Page399

8 distributin cncepts cannt always be adapted t the requirements f the applicatins. C. The Reflective Apprach Thus far we have discussed the library and integrative apprach. The reflective apprach prvides a bridge between bth appraches. The library apprach has the advantage that it allws develpers t structure distributin and cncurrency int reusable cncepts that can be mdified thanks t the different extensibility and reusability mechanisms ffered by bject-riented techniques. This in effect gives a high degree f flexibility which allws the custmizatin f distributin and cncurrency t new cntexts. A middle grund between bth appraches is the reflective apprach. The reflective apprach can be regarded as a bridge between the library and integrative apprach. The idea is t integrate libraries int the prgramming language via a meta bject prtcl (MOP). A MOP allws mdificatins t the cncepts f the bject paradigm. In ther wrds, by using the MOP f a language we can unify cncurrency and distributin cncepts with the language and still have the flexibility ffered by the library apprach. CONCLUSION The tw different types f mbile distributed systems and distilled fur phenmena that are exhibited by the hardware cmpnents used t cmpse mbile distributed systems have been discussed. Next, we have discussed sme sftware issues that arise when develping distributed systems and cnsidered hw the bject paradigm can help t structure and develp cncurrent and distributed sftware. There have been a number f prpsals fr distributed languages that explicitly supprt pen netwrks. Nevertheless, the current state f the art in distributed languages des nt address all the imprtant characteristics that are encuntered when develping a nmadic r ad hc mbile distributed system. On the ther hand, middleware appraches ffer better, althugh ften incmplete, supprt t deal with these inherent hardware phenmena f mbile distributed systems. Unfrtunately, these appraches d nt match well with the bject riented paradigm. REFERENCES [1]Gul Agha and Christian J. Callsen. Actrspace: an pen distributed prgramming paradigm. In PPOPP 93: Prceedings f the furth ACM SIGPLAN sympsium n Principles and practice f parallel prgramming, pages ACM Press, [2]G. Agha. Actrs A Mdel f Cncurrent Cmputatin fr Distributed Systems. MIT Press, [3]Isabelle Attali, Denis Carmel, and Rmain Guider. A step tward autmatic distributin f java prgrams. In Furth Internatinal Cnference n Frmal methds fr pen bject-based distributed systems IV, pages , Nrwell, MA, USA, Kluwer Academic Publishers. [4]Gul Agha. Cncurrent bject-riented prgramming. Cmmunicatins f the ACM, 33(9): , [5] Henri E. Bal, Jennifer G. Steiner, and Andrew S. Tanenbaum. Prgramming languages fr distributed cmputing systems. ACM Cmput. Surv., 21(3): , [6] Gerge Culuris, Jean Dllimre, and Tim Kindberg. Distributed systems (4th ed.): cncepts and design. Addisn-Wesley Lngman Publishing C., Inc., Bstn, MA, USA, [7] Denis Carmel and Ludvic Henri. A Thery f Distributed Objects. Springer Verlag, [8] Nigel Davies, Adrian Friday, Stephen P. Wade, and Grdn S. Blair. An asynchrnus distributed systems platfrm fr hetergeneus envirnments. In Prceedings f the 8th ACM SIGOPS Eurpean wrkshp n Supprt fr cmpsing distributed applicatins, pages ACM Press, ISSN: Page400