/
README
executable file
·84 lines (60 loc) · 3.32 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
// $Id: README,v 1.3 2004/04/08 13:57:05 yaron-r Exp $
JGroups - A Framework for Group Communication in Java
========================================================
March 3, 1998
Bela Ban
4114 Upson Hall
Cornell University
Ithaca, NY 14853
bba@cs.cornell.edu
bela@nms.fnc.fujitsu.com
JGroups is a Java package for reliable group communication. It
consists of 3 parts: (1) a socket-like API for application
development, (2) a protocol stack, which implements reliable
communication, and (3) a set of building blocks, which give the
application/protocol programmer high-level abstractions
(e.g. DistributedHashtable, derived from java.util.Hashtable, which is
similar to Linda/JavaSpaces).
The API (a channel) looks like a socket: there a methods for joining
and leaving groups, sending and receiving messages to/from members,
getting the shared group state, and registering for notifications when
a member joins, or an existing member leaves or crashes.
The protocol stack is a linked list of protocols, through which each
message has to be passed. Each protocol implements an Up() and Down()
method, and may modify, reorder, encrypt, fragment/unfragment, drop a
message, or pass it up/down unchanged. The protocol stack is created
according to a specification given when a channel is created. New
protocols can be plugged into the stack easily.
Building blocks hide the channel and provide a higher
abstraction. Example: DistributedHashtable is a subclass of
java.util.Hashtable and overrides all methods that change the
hashtable (clear, put, remove). Those methods are invoked on all
hashtables in the same group simultaneously, so that all hashtables
have the same state. A new hashtable uses a state transfer protocol to
initially obtain the shared group state from an existing member. This
enables replication of data structures across process boundaries.
Group communication is important the following situations:
- A service has to be replicated for availability. As long as at
least one of the servers remains operational, the service itself
remains operational
- Service requests have to be balanced between a set of servers
- A large number of objects have to be managed as one entity (e.g. a
management domain)
- Notification service / push technology: receivers subscribe to a
channel, senders send data to the channels, channels distribute
data to all receivers subscribed to the channel (see iBus, CastaNet
etc.). Used for example for video distribution, videoconferencing
JGroups deliberately models a rather low-level message-oriented
middleware (MOM) model. The reason is that we don't want to impose a
one-size-fits-all model on the programmer, who usually will want to
extend the model in various (previously unconceived) ways anyway.
Providing low level Java classes allows the programmer to
extend/replace classes at will, as the granularity of the system is
finer.
JGroups can also be used for the construction of higher level
toolkits/frameworks. Such frameworks should provide a certain
transparency, without, however, preventing extensions to be made. The
principle of creating partly 'opened-up' black boxes is called Open
Implementation (OI, http://www.parc.xerox.com/spl/projects/oi/) and
will be applied both to JGroups and to a further higher level
toolkit.