at:tutorial:distribution
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
at:tutorial:distribution [2007/05/04 08:34] – * elisag | at:tutorial:distribution [2007/07/26 10:30] – Reformulated stijnm | ||
---|---|---|---|
Line 5: | Line 5: | ||
====== Distributed Programming ====== | ====== Distributed Programming ====== | ||
- | This tutorial | + | Building on the actor-based concurrency model explained in the [[actors|previous chapter]], this chapter discusses |
- | The integration | + | |
- | More specifically, | + | These requirements correspond |
+ | |||
+ | Before delving in these topics, we illustrate | ||
===== Starting the Network.. ===== | ===== Starting the Network.. ===== | ||
Line 24: | Line 25: | ||
AmbientTalk provides language support to make some objects available to other objects residing in remote actors by means of the '' | AmbientTalk provides language support to make some objects available to other objects residing in remote actors by means of the '' | ||
< | < | ||
- | defstripe | + | deftype |
def service := object: { | def service := object: { | ||
def print(aDoc) { | def print(aDoc) { | ||
Line 33: | Line 34: | ||
</ | </ | ||
- | 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 [[actors# | + | 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 |
< | < | ||
- | defstripe | + | deftype |
</ | </ | ||
Line 57: | Line 58: | ||
< | < | ||
- | We are using a future to get the return value of the '' | + | We are using a future to get the return value of the '' |
</ | </ | ||
Line 69: | Line 70: | ||
Let us consider again the example instant messenger application described in previous section to further explain the semantics of AmbientTalk' | 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 '' | + | When an object discovers a service type, the '' |
- | - Objects are always passed by far reference, except for isolate objects which are passed by copy. | + | - Objects are always passed |
- Native data types are always passed by copy. | - 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, | 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, | ||
Line 92: | Line 92: | ||
This code illustrate how the instant messenger application notifies when a buddy goes online or offline. In the above code, '' | 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 ===== | ===== Garbage collecting remote references ===== | ||
Line 104: | Line 118: | ||
< | < | ||
- | As you may have noticed, the '' | + | 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, '' | + | 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, '' |
< | < | ||
Line 121: | Line 135: | ||
< | < | ||
- | The complete implementation of the instant messenger application explained along this chapter can be found in the file at/ | + | The complete implementation of the instant messenger application explained along this chapter can be found in the file '' |
</ | </ |
at/tutorial/distribution.txt · Last modified: 2009/01/30 16:13 by tvcutsem