[incubator-servicecomb-saga] branch master updated: SCB-330 Polished the document of README

[ni...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

ningjiang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-servicecomb-saga.git


The following commit(s) were added to refs/heads/master by this push:
     new dec3675  SCB-330 Polished the document of README
dec3675 is described below

commit dec3675e3e411a3424accd6a031ff22954cc1d20
Author: Willem Jiang <ji...@huawei.com>
AuthorDate: Thu Feb 8 17:16:22 2018 +0800

    SCB-330 Polished the document of README
---
 README.md      |  2 --
 docs/design.md | 10 +++++-----
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/README.md b/README.md
index fd569ea..e8e62a2 100644
--- a/README.md
+++ b/README.md
@@ -7,8 +7,6 @@ Apache ServiceComb (incubating) Saga is an eventually data consistency solution
 * High performance. Transaction events are reported to coordinator via gRPC and transaction payloads are serialized/deserialized by Kyro.
 * Low invasion. All you need to do is add 2-3 annotations and the corresponding compensate methods.
 * Easy to deploy. All components can boot via docker.
-* Supported micro-service frameworks:
-  + Spring Cloud
 * Support both forward(retry) and backward(compensate) recovery.
 
 ## Architecture
diff --git a/docs/design.md b/docs/design.md
index 625cb95..d976d1a 100644
--- a/docs/design.md
+++ b/docs/design.md
@@ -1,16 +1,16 @@
 # Saga Pack Design
 ## Overview
-Pack contains two components: *alpha* and *omega*. Alpha is the pack leader and backed by database to make sure transaction events stored permanently while omega is the pack worker and embeded inside services to intercept incoming/outgoing requests and report events to alpha.
+Pack contains two components: *alpha* and *omega*. Alpha is the pack leader and backed by database to make sure transaction events stored permanently while omega is the pack worker and embedded inside services to intercept transaction invocation and report events to alpha.
 
 ![Pack Architecture](static_files/pack.png)
 
 ## Omega Internal
-Omega plays as an embeded agent inside services. When a request arrives, omega intercepts its header and retrieve the global transaction id as its global transaction id and retrieve the local transaction id as its parent transaction id. In pre-process phase, a transaction started event will be recorded in alpha. In post-process phase, a transaction ended event will be recorded in alpha to mark the end of the sub-transaction.
+Omega plays as an embedded agent inside services. When a service request arrives, omega intercepts its header and retrieve the global transaction id as its global transaction id (Saga event id) and retrieve the local transaction id as its parent transaction id. In pre-process phase, a transaction started event will be recorded in alpha. In post-process phase, a transaction ended event will be recorded in alpha to mark the end of the sub-transaction.
 
 ![Omega Internal](static_files/omega_internal.png)
 
 ## Inter-Service Communication
-The process of Inter-Service Communication is similiar to [Zipkin](https://github.com/openzipkin/zipkin)'s. In the producer side, omega intercepts the transaction ids from request to retrieve the transaction context. In the consumer side, omega inject the transaction ids into request to pass the transaction context. Sub-transactions can chain as a single global transaction by co-operating producers and consumers.
+The process of Inter-Service Communication is similar to [Zipkin](https://github.com/openzipkin/zipkin)'s. In the producer side, omega intercepts the transaction ids from request to retrieve the transaction context. In the consumer side, omega inject the global transaction ids into request to pass the transaction context. Sub-transactions can chain as a single global transaction by co-operating producers and consumers.
 
 ![Inter-Service Communication](static_files/inter-service_communication.png)
 
@@ -21,11 +21,11 @@ In a successful scenario, all started events will have a corresponding ended eve
 ![Successful Scenario](static_files/successful_scenario.png)
 
 ### Exception Scenario
-In an exception scenario, omega inside the abnormal service will report an aborted event to alpha. Apha will then send compensate commands to the completed events within the global transaction to make suer all sub-transactions are either completed or rollbacked.
+In an exception scenario, omega inside the abnormal service will report an aborted event to alpha. Apha will then send compensate commands to the completed events within the global transaction to make sure all sub-transactions are either completed or rollbacked.
 
 ![Exception Scenario](static_files/exception_scenario.png)
 
 ### Timeout Scenario
-In timeout scenario, timeouted events will be detected by alpha's periodly scanner and abort the corresponding global transaction.
+In timeout scenario, timeouted events will be detected by alpha's period scanner, the corresponding global transaction will be abort at the same time.
 
 ![Timeout Scenario](static_files/timeout_scenario.png)

-- 
To stop receiving notification emails like this one, please contact
ningjiang@apache.org.