anchor.diff:  Here is the simplest possible Muon RPC endpoint. It accepts any data pushed to it, and responsds with a simple text message
   
   [source,java,indent=0]
  -```
  +----
   include::src/main/java/io/muoncore/example/ReactiveRPC.java[]
  -```
  +----
   
   The client for this looks like
   
   [source,java,indent=0]
  -```
  +----
   include::src/main/java/io/muoncore/example/ReactiveRPC.java[]
  -```
  +----
   
   The Response object contains meta data about the reponse, if it succeeded.
   
  
positive.code: having to update every other service to match. Muon takes the position that _availability_ (in the CAP theorum sense) is more
  likely to be systemically useful than _consistency_. Not all service discovery systems take this same view.
  
  Service discovery is baked into the core of Muon, and every implementation has a similar looking subsystem.
  
  This is accessed in Muon Java by the ```Discovery``` object. This is accessible on the Muon and gives access to listings
  of the existing services and a ```ServiceDescriptor``` for each remote service that is currently accessible by the local service.
  
negative.code: To access the data from another service, use the subscribe method, passing in the logical Muon discovery url.
  
  [source,java,indent=0]
  ----
  include::src/main/java/io/muoncore/example/ReactiveStreams.java[]
  ----
  
  Again, this example uses Java and shows two applications communicating over a stream, with back pressure.
  
  