This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
at:tutorial:distribution [2007/07/26 10:30] stijnm Reformulated |
at:tutorial:distribution [2009/01/30 16:13] tvcutsem *fixed |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | < | ||
- | This tutorial is under heavy construction! | ||
- | </ | ||
- | ====== Distributed Programming ====== | ||
- | |||
- | Building on the actor-based concurrency model explained in the [[actors|previous chapter]], this chapter discusses the distribution provisions of AmbientTalk. For actors to communicate across the boundaries of a single device, actor' | ||
- | |||
- | These requirements correspond to the cornerstones of the Ambient-Oriented Programming paradigm. The seamless integration of language support for dealing with partial failures and performing service discovery, hinge on AmbientTalk' | ||
- | |||
- | Before delving in these topics, we illustrate how to activate the network facilities of AmbientTalk in the next section. | ||
- | |||
- | ===== Starting the Network.. ===== | ||
- | |||
- | AmbientTalk provides an unique native object, named '' | ||
- | |||
- | When the virtual machine goes online, this allows the built-in discovery lookup mechanism to export the local objects and let local objects to find other remote objects. AmbientTalk' | ||
- | |||
- | < | ||
- | Be aware that by default the network access is shut down. | ||
- | </ | ||
- | |||
- | ===== Exporting and discovering objects ===== | ||
- | |||
- | AmbientTalk provides language support to make some objects available to other objects residing in remote actors by means of the '' | ||
- | < | ||
- | deftype Printer; | ||
- | def service := object: { | ||
- | def print(aDoc) { | ||
- | system.println(" | ||
- | } | ||
- | }; | ||
- | export: service as: Printer; | ||
- | </ | ||
- | |||
- | When an object its exported by its actor, it becomes discoverable by other actors by means of the service type. Internally, this means that the object is placed in the export table of its actor. As shown in the example, a service type is represented by a type tag. This means that services types are not associated with a set of methods, but they denote an abstract publication topic that objects exports. As a type tag, a service type can thus be a subtype of one or more other service types. For example, an object could offer a color printing services by exporting the following type tag: | ||
- | < | ||
- | deftype ColorPrinter <: Printer; | ||
- | </ | ||
- | |||
- | The '' | ||
- | |||
- | ==== Discovering objects ==== | ||
- | |||
- | AmbientTalk has a built-in peer-to-peer discovery lookup mechanism based on a publish-subscribe scheme that was designed to be able to discover objects in mobile ad hoc network interactions where no centralized lookup infrastructure may be available. | ||
- | |||
- | As previously explained, objects broadcast to the network the service types they offer using the export statement. AmbientTalk also provides language constructs to install an observer whose block of code will be triggered when a remote object of a certain service type becomes available in the network. For example, one can discover a proximate buddy of an instant messenger application by means of the '' | ||
- | < | ||
- | when: InstantMessenger discovered: { |messenger| | ||
- | when: (messenger< | ||
- | buddyList.put(name, | ||
- | system.println(" | ||
- | }; | ||
- | }; | ||
- | </ | ||
- | |||
- | The code block to execute when the service type becomes available is parameterized with the actual remote reference to the discovered service object. In the example above, '' | ||
- | |||
- | < | ||
- | We are using a future to get the return value of the '' | ||
- | </ | ||
- | |||
- | The '' | ||
- | |||
- | As '' | ||
- | |||
- | |||
- | ===== Partial Failure Handling ===== | ||
- | |||
- | Let us consider again the example instant messenger application described in previous section to further explain the semantics of AmbientTalk' | ||
- | |||
- | When an object discovers a service type, the '' | ||
- | |||
- | - Objects are always passed //by far reference//, | ||
- | - Native data types are always passed by copy. | ||
- | |||
- | When a remote far reference receives a messages, it flushes the message to the remote object providing that it is connected. If the remote far reference is disconnected, | ||
- | |||
- | Therefore, a remote far reference abstracts a client object from the actual network connection state. However, it is often useful for an application to be informed when a connection to a remote object is lost or reconnected. To this end, AmbientTalk offers language constructs to install observers on a far reference which are triggered when the reference becomes disconnected or reconnected. For example, the instant messenger application can notify the user whenever a buddy moves in and out of the communication range as follows: | ||
- | |||
- | < | ||
- | when: InstantMessenger discovered: { |messenger| | ||
- | ... | ||
- | when: messenger disconnected: | ||
- | | ||
- | }; | ||
- | when: messenger reconnected: | ||
- | | ||
- | }; | ||
- | }; | ||
- | </ | ||
- | |||
- | This code illustrate how the instant messenger application notifies when a buddy goes online or offline. In the above code, '' | ||
- | |||
- | In other to cope with partial failures, AmbientTalk also allows developers to retract all currently unsent messages from the far reference outbox by means of the '' | ||
- | |||
- | The '' | ||
- | |||
- | < | ||
- | when: Service discovered: { | reference | | ||
- | when: reference disconnected: | ||
- | | ||
- | } | ||
- | } | ||
- | </ | ||
- | |||
- | The construct returns a table containing copies of all messenges that were sent to this far reference, but not yet transmitted by the far reference to the remote object pointed to. Note that this has the side effect that the returned messages will not be sent automatically anymore; the programmer is thus responsible to explicitly resend all messages that were retracted but still need to be sent. | ||
- | |||
- | ===== Garbage collecting remote references ===== | ||
- | |||
- | As explained in the previous section, AmbientTalk' | ||
- | |||
- | < | ||
- | takeOffline: | ||
- | </ | ||
- | |||
- | The construct removes from the export table of the actor where the code is executed the object passed as argument. When the object is removed from the export table, it no longer belongs to the set of root objects and as such, it can be reclaimed by the local garbage collector once when it is no longer locally referenced. Although the actual reclamation of an unexported object may be trigger at a later point in time, any attempt to access it via a far reference will result in a '' | ||
- | |||
- | < | ||
- | As you may have noticed, the '' | ||
- | </ | ||
- | |||
- | On the client side, taking offline an object results in a permanent disconnection of the remote references pointing to it. In other words, despite having network connection, unexporting an object renders remote far references permanently disconnected. This implies that client have to deal explicitly with unexported objects. To this end, '' | ||
- | |||
- | < | ||
- | when: messenger takenOffline: | ||
- | | ||
- | // | ||
- | }; | ||
- | </ | ||
- | |||
- | Be aware that unexporting a object will not only trigger the takenOffline observers but also the disconnected observers since the taking offline event is also considered as a logical disconnection between two devices. Unlike the network observers, the block of code of a takenOffline observer will be triggered only once. The remote object becomes then subject to be eventually reclaimed by the garbage collector. As a result, the disconnected and reconnected observers will be no longer trigger for such remote reference. | ||
- | |||
- | Note that disconnection, | ||
- | |||
- | < | ||
- | The complete implementation of the instant messenger application explained along this chapter can be found in the file '' | ||
- | </ |