#90 - clarify service invocation conceptual doc with an endpoint. Also, improve the diagram. (#135)

concepts/service-invocation/service-invocation.md

@@ -12,6 +12,18 @@ Dapr-enabled apps can communicate with each other through well-known endpoints i
 5. Dapr forwards the response to Service A's Dapr sidecar.
 6. Service A receives the response.
 
+As an example for all the above, suppose we have the collection of apps described in the following sample, where a python app invokes a Node.js app: https://github.com/dapr/samples/blob/master/2.hello-kubernetes/README.md
+
+In such a scenario, the python app would be "Service A" above, and the Node.js app would be "Service B".
+
+The following describes items 1-6 again in the context of this sample:
+1. Suppose the Node.js app has a Dapr app id of "nodeapp", as in the sample.  The python app invokes the Node.js app's `neworder` method by posting `http://localhost:3500/v1.0/invoke/nodeapp/method/neworder`, which first goes to the python app's local Dapr sidecar.
+2. Dapr discovers the Node.js app's location and forwards it to the Node.js app's sidecar.
+3. The Node.js app's sidecar forwards the request to the Node.js app.  The Node.js app performs its business logic, which, as described in the sample, is to log the incoming message and then persist the order ID into Redis (not shown in the diagram above).
+
+Steps 4-5 are the same as the list above.
+
+
 For more information, see:
 - The [Service Invocation Spec](https://github.com/dapr/spec/blob/master/service_invocation.md)
 - A [HowTo]() on Service Invocation