Q21. What patterns are particularly useful in building networked applications?

I suggest starting with Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects (POSA2). POSA2 specifically brings together 17 interrelated patterns addressing Service Access and Configuration, Event Handling, Synchronization, and Concurrency. The patterns and many of the examples in POSA2 come primarily from the design and implementation of the ACE framework.

Q22. Are there any good Java-specific patterns books available?

The Java-specific patterns books are:
• Java Design Patterns: A Tutorial
• Patterns in Java, Volume 1
• Patterns in Java, Volume 2
• Concurrent Programming in Java , Second Edition: Design Principles and Patterns
• SanFrancisco Design Patterns

As far as the good part of the question.... Doug Lea's Concurrent Programming book is
probably the best of the bunch. However, its patterns are specific to concurrent
programming. Many people don't like the quality of Mark Grand's two Patterns in Java
books. [They are rated 3 and 2 stars at Amazon, respectively]. The first printing of the Cooper tutorial book was riddled with errors. If you get that, be sure to get at least the second printing. [Look on last line of page before TOC.] The SanFrancisco book is definitely good, but I'm not sure how good if you aren't using SF.

Q23. What are Collaboration Patterns?

Collaboration Patterns are repeatable techniques used by teams of people to help them work together (collaborate). Ellen Gottesdiener of EBG Consulting has created these patterns in order to help facilitate good teamwork. These patterns really have nothing to do with object-oriented development or Java, besides the fact that they can help with requirements gathering or CRC design sessions. In a nutshell, Collaboration Patterns are techniques to help make meetings useful.

Q24. Is it correct from a design point of view to make an object both an Observer and Observable at the same time?

Yes, and this can be the preferred pattern in some cases.
For example, suppose you were writing a supply chain management system for a retail chain. Each store object in your system generates item-sold events; when the chain generates enough of these for a particular product, a buyer object generates a purchase order for more of the product. However, the buyer object has no particular interest in individual item sold events. Instead, the buyer (Observer) registers to receive out-of-stock events from the warehouse (Observable); the warehouse, as Observer, registers with the individual stores (Observables) to receive item-sold events. Thus, the warehouse is both Observer and Observable. (Please note that this is a synthetic example, and probably not the way to organize a supply chain.)
Another reason to use one or more central Observer-Observable object in between ultimate Observers and Observables is to fully decouple the two. In some cases, Observer and Observable may exist on different machines, and may rely on the central Observer- Observable to hide this complication. A good source for more details is the Publisher-Subscriber section of Buschmann et al.,
Pattern-Oriented Software Architecture: A System of Patterns.