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

[ningjiang]

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 <jiangni...@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
ningji...@apache.org.