Site: Added skeletons for documentation.

Change-Id: I5b74acecf67a939b91c0c27cdec417b9902e373f
Signed-off-by: Tony Tkacik <ttkacik@cisco.com>

diff --git a/src/site/asciidoc/architecture.adoc b/src/site/asciidoc/architecture.adoc
new file mode 100644 (file)
index 0000000..a54e9d8
--- /dev/null
+++ b/src/site/asciidoc/architecture.adoc
@@ -0,0 +1,21 @@
+= Architecture
+
+
+[plantuml]
+....
+  package "MD-SAL Project" {
+
+    () "MD-SAL Binding API" as mdsal.binding.api
+    () "MD-SAL DOM API" as mdsal.dom.api
+    [Binding Adapter] as mdsal.binding.adapter
+    [Binding Data Codec] as mdsal.binding.codec
+    [MD-SAL DOM Router] as mdsal.dom.router
+    () "MD-SAL Shard SPI" as mdsal.shard.spi
+
+    mdsal.binding.adapter --> mdsal.binding.codec : uses
+    mdsal.binding.api -- mdsal.binding.adapter
+    mdsal.binding.adapter .> mdsal.dom.api : uses
+    mdsal.dom.api -- mdsal.dom.router
+    mdsal.dom.router -- mdsal.shard.spi
+  }
+....

diff --git a/src/site/asciidoc/overview.adoc b/src/site/asciidoc/overview.adoc
new file mode 100644 (file)
index 0000000..4048e52
--- /dev/null
+++ b/src/site/asciidoc/overview.adoc
@@ -0,0 +1,96 @@
+= MD-SAL Overview
+
+The Model-Driven Service Adaptation Layer (MD-SAL) is message-bus inspired
+extensible middleware component that provides messaging and data storage
+functionality based on data and interface models defined by application developers
+(i.e. user-defined models).
+
+The MD-SAL:
+
+ * Defines a *common-layer, concepts, data model building blocks and messaging
+   patterns* and provides infrastructure / framework for applications and
+   inter-application communication.
+
+// FIXME: Common integration point / reword this better
+ * Provide common support for user-defined transport and payload formats, including
+   payload serialization and adaptation (e.g. binary, XML or JSON).
+
+The MD-SAL uses *YANG* as the modeling language for both interface and data
+definitions, and provides a messaging and data-centric runtime for such services
+based on YANG modeling.
+
+The MD-SAL provides two different API types (flavours): +
+
+* *MD-SAL Binding:* MD-SAL APIs which extensively uses APIs and classes generated
+  from YANG models, which provides compile-time safety.
+* *MD-SAL DOM:* (Document Object Model) APIs which uses DOM-like
+  representation of data, which makes them more powerful, but provides less
+  compile-time safety.
+
+NOTE: Model-driven nature of the MD-SAL and *DOM*-based APIs allows for
+behind-the-scene API and payload type mediation and transformation
+to facilitate seamless communication between applications - this enables
+for other components and applications to provide connectors / expose different
+set of APIs and derive most of its functionality purely from models, which
+all existing code can benefit from without modification.
+For example *RESTCONF Connector* is an application built on top of MD-SAL
+and exposes YANG-modeled application APIs transparently via HTTP and adds support
+for XML and JSON payload type.
+
+==== Basic concepts
+
+Basic concepts are building blocks which are used by applications, and from
+which MD-SAL uses to define messaging patterns and to provide services and
+behavior based on developer-supplied YANG models.
+
+Data Tree::
+All state-related data are modeled and represented as data tree,
+with possibility to address any element / subtree
++
+  * *Operational Data Tree* - Reported state of the system, published by the
+     providers using MD-SAL. Represents a feedback loop for applications
+     to observe state of the network / system.
+  * *Configuration Data Tree* - Intended state of the system or network,
+     populated by consumers, which expresses their intention.
+
+Instance Identifier::
+Unique identifier of node / subtree in data tree, which provides unambiguous
+information, how to reference and retrieve node / subtree from conceptual
+data trees.
+
+Notification::
+Asynchronous transient event which may be consumed by subscribers and they may
+act upon it
+
+RPC::
+asynchronous request-reply message pair, when request is triggered
+by consumer, send to the provider, which in future replies with reply message.
++
+NOTE: In MD-SAL terminology, the term 'RPC' is used to define the input and
+output for a procedure (function) that is to be provided by a provider,
+and mediated by the MD-SAL, that means it may not result in remote call.
+
+==== Messaging Patterns
+
+MD-SAL provides several messaging patterns using broker derived from
+basic concepts, which are intended to transfer YANG modeled data between
+applications to provide data-centric integration between applications instead
+of API-centric integration.
+
+* *Unicast communication*
+** *Remote Procedure Calls* - unicast between consumer and provider, where
+consumer sends *request* message to provider, which asynchronously responds
+with *reply* message
+
+* *Publish / Subscribe*
+** *Notifications* - multicast transient message which is published by provider
+   and is delivered to subscribers
+** *Data Change Events* - multicast asynchronous event, which is sent by data
+broker if there is change in conceptual data tree, and is delivered to subscribers
+
+* *Transactional access to Data Tree*
+** Transactional *reads* from conceptual *data tree* - read-only transactions with
+   isolation from other running transactions.
+** Transactional *modification* to conceptual *data tree* - write transactions with
+   isolation from other running transactions.
+** *Transaction chaining*

diff --git a/src/site/asciidoc/release-notes.adoc b/src/site/asciidoc/release-notes.adoc
new file mode 100644 (file)
index 0000000..9dc85a6
--- /dev/null
+++ b/src/site/asciidoc/release-notes.adoc
@@ -0,0 +1,3 @@
+= Release Notes
+
+== Boron Release (in progress)

diff --git a/src/site/asciidoc/resources.adoc b/src/site/asciidoc/resources.adoc
new file mode 100644 (file)
index 0000000..e69de29