Group communication patterns are building blocks and / or communication algorithms frequently encountered in applications employing group communication. Some patterns make use of (the abstract notion of) channels, while others use channels only indirectly and / or can be used independently altogether. They greatly simplify programming by encapsulating recurring pieces of group communication into sufficiently small and reusable Java classes. There are two types of patterns: following the terminology in [GHJV95] they are structural patterns and behavioral patterns. Structural patterns are concerned with how objects and classes are composed to form larger structures. They typically show in the form of classes. Behavioral patterns are concerned with capturing algorithms in a reusable form. They are typically represented by class methods.
A programmer is free to choose whether to use channels and none of the patterns, or whether he requires a higher level of abstraction by using one (or more) patterns.
An example of a structural pattern is the SyncCall class which emulates synchronous message exchange on top of (inherently asychnronous) channels. Its value is that the caller does not have to correlate one or more responses to requests himself, but is blocked until the first (or any N responses) is returned.
An example of a behavioral pattern is failure detector which regularly pings designated members of a group and - if a member crashed - indicates this to the group membership service.2.1
Both structural and behavioral patterns are intended to be used in both developing communication applications and protocols.
The value of patterns is that they are independently reusable pieces of recurring design decisions which are based on a very generalized concept of group communication (namely channels) and can therefore also be used on top of other group communication toolkits.2.2 However, contrary to frameworks, which impose a certain structure of usage on clients, JavaGroups is only a toolkit which gives programmers the freedom to decide which pieces to use and which not.