Merge pull request #1 from wso2/5.9.0

sync
wso2 · Nov 5, 2019 · fd6d4e4 · fd6d4e4
2 parents 8aabd48 + 9fcd56e
commit fd6d4e4
Show file tree

Hide file tree

Showing 60 changed files with 7,769 additions and 9,022 deletions.
diff --git a/en/docs/administer/browsing-the-h2-database.md b/en/docs/administer/browsing-the-h2-database.md
@@ -14,10 +14,6 @@ browse through it.
     industry-standard RDBMS such as Oracle, PostgreSQL, MySQL, or MS SQL
     instead.
 
-    You can use the embedded H2 database in development environments and as
-    the local registry in a registry mount.
-
-
 1.  Open the
     `           <IS_HOME>/repository/conf/deployment.toml          `
     file and add the following configuration.
@@ -62,7 +58,7 @@ browse through it.
       </tr>
       <tr class="even">
       <td><strong>JDBC URL</strong></td>
-      <td>location of the H2 database</td>
+      <td>location of the H2 database. All the default databases are located at `<IS_HOME>/repository/database` location.</td>
       </tr>
       </table>  
 

diff --git a/en/docs/administer/clustering-overview.md b/en/docs/administer/clustering-overview.md
@@ -1,20 +1,17 @@
 # Clustering Overview
 
-The following topics explain the basics of clustering. 
+## Introduction to clustering
 
-
-### Introduction to clustering
-
-You can install multiple instances of WSO2 products in a *cluster* . A
-cluster consists of multiple instances of a product that divide up the
-work and act as a single instance. This improves **performance** as
+A cluster consists of multiple instances of a product that divide up the
+work and act as a single instance. This improves **performance** as the
 requests are distributed among several servers instead of just one. It
-is also more **reliabile** as one instance is there to handle requests
-when another becomes unavailable. Clustering provides the following
-benefits:
+is also more **reliable** as there are other instances to handle requests
+when one instance becomes unavailable. Following are several benefits of 
+clustering.
+
 
 -   **High availability** : Some systems require high availability
-    percentages like two-nines (99%). A server may go down due to many
+    percentages such as two-nines (99%). A server may go down due to many
     reasons such as system failures, planned outage, or hardware or
     network problems. Clustering for high availability results in fewer
     service interruptions. Since downtime is costly to any business,
@@ -47,9 +44,8 @@ benefits:
     any unforeseen opportunities.
 
 These characteristics are essential for enterprise applications deployed
-in a production environment. You need a cluster when you go into
-production as that is when good performance and reliability are
-critical.
+in a production environment. Therefore, you need a cluster when you go into
+production when performance and reliability are critical.
 
 WSO2 provides [Hazelcast Community
 Edition](http://www.hazelcast.com/products-community.jsp) as its default
@@ -75,7 +71,7 @@ license key of Hazelcast Enterprise:
 
 ------------------------------------------------------------------------
 
-### About membership schemes
+## About membership schemes
 
 A cluster should contain two or more instances of a product that are
 configured to run within the same domain. To make an instance a member
@@ -87,22 +83,23 @@ schemes, which are as follows:
 -   AWS membership scheme
 
 All of these membership schemes are ready to be used in production. You
-can select based on your production environment. Here's a comparison of
+can select a scheme based on your production environment. Here's a comparison of
 the membership schemes:
 
-| Multicast                                                  | WKA                                                                                                                     | AWS                                                        |
-|------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------|
-| All nodes should be in the same subnet                     | Nodes can be in different networks                                                                                      | Amazon EC2 nodes                                           |
-| All nodes should be in the same multicast domain           | No multicasting requirement                                                                                             | No multicasting requirement                                |
-| Multicasting should not be blocked                         | No multicasting requirement                                                                                             | No multicasting requirement                                |
-| No fixed IP addresses or hosts required                    | At least one well-known IP address or host required.                                                                    | No fixed IP addresses or hosts required                    |
-| Failure of any member does not affect membership discovery | New members can join with some WKA nodes down, but not if all WKA nodes are down.                                       | Failure of any member does not affect membership discovery |
-| Does not work on IaaSs such as Amazon EC2                  | IaaS-friendly                                                                                                           | Works on Amazon EC2                                        |
-| No WKA requirement                                         | Requires keepalive, elastic IPs, or some other mechanism for re-mapping IP addresses of WK members in cases of failure. | No WKA requirement                                         |
-
-Note that some production environments do not support multicast.
-However, if your environment supports multicast, there are no issues in
-using this as your membership scheme.
+| Multicast                                                  | WKA                                                                                                                    | AWS                                                        |
+|------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------|
+| All nodes should be in the same subnet                     | Nodes can be in different networks                                                                                     | Amazon EC2 nodes                                           |
+| All nodes should be in the same multicast domain           | No multicasting requirement                                                                                            | No multicasting requirement                                |
+| Multicasting should not be blocked                         | No multicasting requirement                                                                                            | No multicasting requirement                                |
+| No fixed IP addresses or hosts required                    | At least one well-known IP address or host required                                                                    | No fixed IP addresses or hosts required                    |
+| Failure of any member does not affect membership discovery | New members can join with some WKA nodes down, but not if all WKA nodes are down                                       | Failure of any member does not affect membership discovery |
+| Does not work on IaaSs such as Amazon EC2                  | IaaS-friendly                                                                                                          | Works on Amazon EC2                                        |
+| No WKA requirement                                         | Requires keepalive, elastic IPs, or some other mechanism for re-mapping IP addresses of WK members in cases of failure | No WKA requirement                                         |
+
+!!! note
+    Some production environments do not support multicast.
+    However, if your environment supports multicast, there are no issues in
+    using multicast as your membership scheme.
 
 !!! info "About Well-Known Addresses (WKA)"
     The Well-Known Addresses (WKA) feature is a mechanism that allows
@@ -118,7 +115,7 @@ using this as your membership scheme.
 
 ------------------------------------------------------------------------
 
-### Clustering compatibility with WSO2 products
+## Clustering compatibility with WSO2 products
 
 WSO2 products are compatible with each other if they are based on the
 same WSO2 Carbon version. See the [release
@@ -127,19 +124,11 @@ compatibility information.
 
 !!! info "About performance of WSO2 products in a cluster"
     If you are setting up multiple WSO2 products in a cluster, it is
-    recommended to set up each product on a separate server. For example,
-    WSO2 ESB is used for message mediation, so a considerable amount of
-    processing happens in the ESB. The DSS does data service hosting and has
-    a different architecture layer from the ESB. If you deploy both the ESB
-    and DSS in the same instance/runtime, it can negatively impact the
-    performance of both, and it also makes scaling difficult. However, you
-    can set up hybrid servers (installing selected DSS features on top of
-    the ESB and vice versa) using WSO2 products without the above
-    performance concerns.
+    recommended to set up each product on a separate server. 
 
 ------------------------------------------------------------------------
 
-### Deciding how to set up your cluster
+## Deciding how to set up your cluster
 
 When setting up your cluster, you must decide how you want to set up and
 [share your databases](../../administer/sharing-databases-in-a-cluster), whether to

diff --git a/en/docs/administer/configuring-the-primary-user-store.md b/en/docs/administer/configuring-the-primary-user-store.md
@@ -8,19 +8,16 @@ documentation explains the process of setting up a primary user store
 for your system.
 
 !!! info "The default User Store"
-    The primary user store that is configured by default in every WSO2
-    product is a JDBC user store, which reads/writes into the internal
-    database of the product server. By default, the internal database is H2
-    (except for WSO2 IS, which uses an LDAP as the default user store). This
-    database is used by the Authorization Manager (for user authentication
+    The primary user store that is configured by default in WSO2 Identity Server
+    is an LDAP user store, This database is used by the Authorization Manager (for user authentication
     information) as well as the User Store Manager (for defining users and
     roles).
 
-Instead of using the embedded database, you can set up a separate
+Instead of using the embedded LDAP, you can set up a separate
 repository and configure it as your primary user store. Since the user
 store you want to connect to might have different schemas from the ones
 available in the embedded user store, it needs to go through an
-adaptation process. WSO2 products provide the following adapters, for
+adaptation process. WSO2 Identity Server provides the following adapters, for
 connecting to LDAP, Active Directory and JDBC. Thereby, these adapters
 enable you to authenticate users from different types of user stores.
 
@@ -50,7 +47,7 @@ enable you to authenticate users from different types of user stores.
 </tr>
 <tr class="even">
 <td><pre><code>org.wso2.carbon.user.core.jdbc.JDBCUserStoreManager</code></pre></td>
-<td><p>Use <code>              JDBCUserStoreManager             </code> for both internal and external JDBC user stores. This is the user store configuration which is uncommented in the code in the <code>              user-mgt.xml             </code> file for all WSO2 products, except WSO2 Identity Server (which uses the <code>              ReadWriteLDAPUserStoreManager             </code> ).</p></td>
+<td><p>Use <code>              JDBCUserStoreManager             </code> for both internal and external JDBC user stores.</p></td>
 </tr>
 </tbody>
 </table>

diff --git a/en/docs/administer/load-balancing.md b/en/docs/administer/load-balancing.md
@@ -1,18 +1,39 @@
 # Load Balancing
 
-You cluster services in production environments to scale up applications
-and/or achieve high availability. By scaling up, the application can
-support more user requests and through high availability, the service is
-available even when a few servers are down.
+Clustering services in production environments will enable applications to scale up
+and achieve high availability. By scaling up, the application can
+support more user requests and via high availability, the service will 
+be seamlessly available even when a several servers are down. Load balancing 
+is the most straightforward method of scaling out a server infrastructure. Load 
+balancing is the process of efficiently distributing network traffic across 
+multiple servers of a service.
 
-You use a load balancer to distribute requests among the nodes in a
+![load-balancing](../../assets/img/administer/load balancing/load-balancing.png)
+
+## Load Balancer
+
+A load balancer can be a device or software which is capable of distributing network 
+traffic across a cluster of servers. Simply, a load balancer acts a cop whose is trying 
+to minimize the traffic in roads. A load balancer sits in between the clients and the servers 
+accepting incoming network traffic and routing those requests backend servers so that minimum 
+traffic is available.
+
+![load-balancing](../../assets/img/administer/load balancing/load-balancer.png)
+
+A load balancer to is used to distribute requests among the nodes in a
 cluster. The nodes that receive incoming traffic are a set of backend
-worker nodes. They are either pre-defined (static) or discovered
-dynamically. In the static mode, you cannot add new nodes to the
-pre-defined set of worker nodes at runtime. In the dynamic mode, you can
-add nodes to the load balancer at runtime without knowing the IPs and
+worker nodes. They can be either,
+
+ - Pre-defined (static) nodes or 
+ - Dynamically discovered nodes. 
+
+In the static mode, you won't be able to add any new nodes at runtime since all the 
+set of worker nodes are pre-defined. In dynamic mode, you will be able to 
+add nodes at runtime to the load balancer without knowing the IPs and
 other connection details.
 
+### Types of load balancers
+
 Among the many varieties of load balancers are hardware, DNS,
 transport-level (e.g., HTTP level like Apache Tomcat), and
 application-level load balancers (e.g., Synapse). High-level load
@@ -29,14 +50,14 @@ controlled by application-specific requirements like sticky sessions.
 With a reasonably diverse set of users, simple approaches perform as
 well as complex ones.
 
-### Session affinity
+## Session affinity
 
 Stateful applications inherently do not scale well. State replication
 induces a performance overhead on the system. Instead of deploying
 stateful applications in a cluster, you can use session-affinity-based
 load balancing.
 
-Session affinity ensures that, when a client sends a session ID, the
+Session affinity ensures, when a client sends a session ID, the
 load balancer forwards all requests containing the session ID to the
 same backend worker node, irrespective of the specified load balancing
 algorithm. Before the session is created, the request is dispatched to

diff --git a/en/docs/administer/working-with-databases.md b/en/docs/administer/working-with-databases.md
@@ -19,6 +19,13 @@ Explained below are the default databases that you will find in the
 -   **Workflow database:** `          jpadb.mv.db         ` This database has the 
     workflow related data. 
 
+Following image shows the default databases and the data that are stored in each database.
+<div>
+    <center>
+        <img src="../../assets/img/administer/working-with-databases/default-database-structure.png">
+    </center>
+</div>
+
 ### Changing the default databases
 
 The embedded H2 databases shipped with your product are suitable for evaluation,

diff --git a/en/docs/assets/img/administer/load balancing/load-balancer.png b/en/docs/assets/img/administer/load balancing/load-balancer.png
diff --git a/en/docs/assets/img/administer/load balancing/load-balancing.png b/en/docs/assets/img/administer/load balancing/load-balancing.png
diff --git a/...ocs/assets/img/administer/working-with-databases/default-database-structure.png b/...ocs/assets/img/administer/working-with-databases/default-database-structure.png
diff --git a/en/docs/assets/img/setup/component-diagram.png b/en/docs/assets/img/setup/component-diagram.png
diff --git a/...img/setup/configuring-sp-Idp-using-configuration-files/no-service-providers.png b/...img/setup/configuring-sp-Idp-using-configuration-files/no-service-providers.png
diff --git a/...cs/assets/img/setup/configuring-sp-Idp-using-configuration-files/sp_configs.png b/...cs/assets/img/setup/configuring-sp-Idp-using-configuration-files/sp_configs.png
diff --git a/...ting-up-separate-databases-for-clustering/separate-databases-for-clustering.png b/...ting-up-separate-databases-for-clustering/separate-databases-for-clustering.png
diff --git a/en/docs/assets/img/tutorials/add-secondary-user-store.png b/en/docs/assets/img/tutorials/add-secondary-user-store.png
diff --git a/en/docs/develop/approvals-rest-api.md b/en/docs/develop/approvals-rest-api.md
@@ -1,12 +1,11 @@
 ---
 template: templates/swagger.html
 ---
-??? note "Note: Click to view"
+??? note "Click to view"
     Do the following to try out the REST APIs with your local instance of WSO2 Identity Server. 
 
-      1. [Add a new workflow definition](https://is.docs.wso2.com/en/5.9.0/learn/adding-a-new-workflow-definition/) 
-      and [engage the workflow in an operation](https://is.docs.wso2.com/en/5.9
-      .0/learn/engaging-a-workflow-in-an-operation/)
+      1. [Add a new workflow definition](../../learn/adding-a-new-workflow-definition/) 
+      and [engage the workflow in an operation](../../learn/engaging-a-workflow-in-an-operation/)
       2. Perfom few related operations to generate few human task approvals.
       3. Click on **Authorize** button and provide desired values for authentication.
       4. Expand the relevant API operation and click the **Try It Out** button.  

diff --git a/en/docs/develop/association-rest-api.md b/en/docs/develop/association-rest-api.md
@@ -1,7 +1,7 @@
 ---
 template: templates/swagger.html
 ---
-??? Note "Note: Click to view"
+??? Note "Click to view"
     Do the following to try out the REST APIs with your local instance of WSO2 Identity Server. 
 
        1.  Click on **Authorize** button and provide desired values for authentication. 

diff --git a/en/docs/develop/authenticating-and-authorizing-rest-apis.md b/en/docs/develop/authenticating-and-authorizing-rest-apis.md
@@ -55,7 +55,7 @@ Let's learn how to authenticate and authorize REST APIs:
 
         !!! example
             ```toml
-            [[resource.access_control]]
+            [resource.access_control]
             context = "/api/identity/*"
             secured = true
             http_method = "all"

diff --git a/en/docs/develop/authorized-apps-rest-api.md b/en/docs/develop/authorized-apps-rest-api.md
@@ -1,7 +1,7 @@
 ---
 template: templates/swagger.html
 ---
-??? Note "Note: Click to view"
+??? Note "Click to view"
     Do the following to try out the REST APIs with your local instance of WSO2 Identity Server. 
 
        1.  Click on **Authorize** button and provide desired values for authentication.