Allow ledger selection to be done at runtime for solo.

This also adds a README.md file which has a basic explanation
of the pieces currently in the orderer dir.  It also contains
brief instructions regarding how to use the existing code, as
well as some future plans.

https://jira.hyperledger.org/browse/FAB-327

Change-Id: I6ffa3ef6569b422263115fa95f3479b1516ed0af
Signed-off-by: Jason Yellick <jyellick@us.ibm.com>

orderer/README.md

@@ -0,0 +1,31 @@
+# Hyperledger Ordering Service
+The hyperledger fabric ordering service is intended to provide an atomic broadcast ordering service for consumption by the peers.  This means that many clients may submit messages for ordering, and all clients are delivered the same series of ordered batches in response.
+
+## Protocol definition
+The atomic broadcast ordering protocol for hyperledger fabric is described in `hyperledger/fabric/orderer/atomicbroadcast/ab.proto`.  There are two services, the `Broadcast` service for injecting messages into the system, and the `Deliver` service for receiving ordered batches from the service.  Sometimes, the service will reside over the network, while othertimes, the service may be bound locally into a peer process.  The service may be bound locally for single process development deployments, or when the underlying ordering service has its own backing network protocol and the proto serves only as a wrapper.
+
+## Service types
+* Solo Orderer:
+The solo orderer is intended to be an extremely easy to deploy, non-production orderer.  It consists of a single process which serves all clients, so no `consensus' is required as there is a single central authority.  There is correspondingly no high availability or scalability.  This makes solo ideal for development and testing, but not deployment.  The Solo orderer depends on a backing raw ledger.
+
+* Kafka Orderer (pending):
+The Kafka orderer leverages the Kafka pubsub system to perform the ordering, but wraps this in the familiar `ab.proto` definition so that the peer orderer client code does not to be written specifically for Kafka.  In real world deployments, it would be expected that the Kafka proto service would bound locally in process, as Kafka has its own robust wire protocol.  However, for testing or novel deployment scenarios, the Kafka orderer may be deployed as a network service.  Kafka is anticipated to be the preferred choice production deployments which demand high throughput and high availability but do not require byzantine fault tolerance.  The Kafka orderer does not utilize a backing raw ledger because this is handled by the Kafka brokers.
+
+* PBFT Orderer (pending):
+The PBFT orderer uses the hyperledger fabric PBFT implementation to order messages in a byzantine fault tolerant way.  Because the implementation is being developed expressly for the hyperledger fabric, the `ab.proto` is used for wireline communication to the PBFT orderer.  Therefore it is unusual to bind the PBFT orderer into the peer process, though might be desirable for some deployments.  The PBFT orderer depends on a backing raw ledger.
+
+## Raw Ledger Types
+Because the ordering service must allow clients to seek within the ordered batch stream, orderers must maintain a local copy of past batches.  The length of time batches are retained may be configurable (or all batches may be retained indefinitely). Not all ledgers are crash fault tolerant, so care should be used when selecting a ledger for an application.  Because the raw leger interface is abstracted, the ledger type for a particular orderer may be selected at runtime.  Not all orderers require (or can utilize) a backing raw ledger (for instance Kafka, does not).
+
+* RAM Ledger
+The RAM ledger implementation is a simple development oriented ledger which stores batches purely in RAM, with a configurable history size for retention.  This ledger is not crash fault tolerant, restarting the process will reset the ledger to the genesis block.  This is the default ledger.
+* File Ledger
+The file ledger implementation is a simple development oriented ledger which stores batches as JSON encoded files on the filesystem.  This is intended to make inspecting the ledger easy and to allow for crash fault tolerance.  This ledger is not intended to be performant, but is intended to be simple and easy to deploy and understand.  This ledger may be enabled before executing the `orderer` binary by setting `ORDERER_LEDGER_TYPE=file` (note: this is a temporary hack and may not persist into the future).
+* Other Ledgers
+There are currently no other raw ledgers available, although it is anticipated that some high performance database or other log based storage system will eventually be adapter for production deployments.
+
+## Experimenting with the orderer service
+
+To experiment with the orderer service you may build the orderer binary by simply typing `go build` in the `hyperledger/fabric/orderer` directory.  You may then invoke the orderer binary with no parameters, or you can override the bind address, port, and backing ledger by setting the environment variables `ORDERER_LISTEN_ADDRESS`, `ORDERER_LISTEN_PORT` and `ORDERER_LEDGER_TYPE` respectively.  Presently, only the solo orderer is supported.  The deployment and configuration is very stopgap at this point, so expect for this to change noticably in the future.
+
+There are sample clients in the `fabric/orderer/sample_clients` directory.  The `broadcast_timestamp` client sends a message containing the timestamp to the `Broadcast` service.  The `deliver_stdout` client prints received batches to stdout from the `Deliver` interface.  These may both be build simply by typing `go build` in their respective directories.  Neither presently supports config, so editing the source manually to adjust address and port is required.

orderer/main.go

@@ -18,10 +18,14 @@ package main
 
 import (
 	"fmt"
+	"io/ioutil"
 	"net"
 	"os"
 	"time"
 
+	"github.com/hyperledger/fabric/orderer/rawledger"
+	"github.com/hyperledger/fabric/orderer/rawledger/fileledger"
+	"github.com/hyperledger/fabric/orderer/rawledger/ramledger"
 	"github.com/hyperledger/fabric/orderer/solo"
 
 	"google.golang.org/grpc"
@@ -47,6 +51,27 @@ func main() {
 
 	grpcServer := grpc.NewServer()
 
-	solo.New(100, 10, 10, 10*time.Second, grpcServer)
+	// Stand in until real config
+	ledgerType := os.Getenv("ORDERER_LEDGER_TYPE")
+	var rawledger rawledger.ReadWriter
+	switch ledgerType {
+	case "file":
+		name, err := ioutil.TempDir("", "hyperledger") // TODO, config
+		if err != nil {
+			panic(fmt.Errorf("Error creating temp dir: %s", err))
+		}
+
+		rawledger = fileledger.New(name)
+	case "ram":
+		fallthrough
+	default:
+		historySize := 10 // TODO, config
+		rawledger = ramledger.New(historySize)
+	}
+
+	queueSize := 100 // TODO configure
+	batchSize := 10
+	batchTimeout := 10 * time.Second
+	solo.New(queueSize, batchSize, batchTimeout, rawledger, grpcServer)
 	grpcServer.Serve(lis)
 }

orderer/solo/solo.go

@@ -21,7 +21,6 @@ import (
 
 	ab "github.com/hyperledger/fabric/orderer/atomicbroadcast"
 	"github.com/hyperledger/fabric/orderer/rawledger"
-	"github.com/hyperledger/fabric/orderer/rawledger/ramledger"
 
 	"github.com/op/go-logging"
 	"google.golang.org/grpc"
@@ -39,13 +38,11 @@ const MagicLargestWindow = 1000
 type server struct {
 	bs *broadcastServer
 	ds *deliverServer
-	rl rawledger.ReadWriter
 }
 
 // New creates a ab.AtomicBroadcastServer based on the solo orderer implementation
-func New(queueSize, batchSize, historySize int, batchTimeout time.Duration, grpcServer *grpc.Server) ab.AtomicBroadcastServer {
-	logger.Infof("Starting solo with queueSize=%d batchSize=%d historySize=%d batchTimeout=%v", queueSize, batchSize, historySize, batchTimeout)
-	rl := ramledger.New(historySize)
+func New(queueSize, batchSize int, batchTimeout time.Duration, rl rawledger.ReadWriter, grpcServer *grpc.Server) ab.AtomicBroadcastServer {
+	logger.Infof("Starting solo with queueSize=%d, batchSize=%d batchTimeout=%v and ledger=%T", queueSize, batchSize, batchTimeout, rl)
 	s := &server{
 		bs: newBroadcastServer(queueSize, batchSize, batchTimeout, rl),
 		ds: newDeliverServer(rl, MagicLargestWindow),