First iteration comments

Dockerfile.intent_brokering

@@ -7,7 +7,7 @@ FROM docker.io/library/rust:${RUST_VERSION} AS builder
 
 # Dockerfile for building Eclipse Chariott Intent Brokering runtime container
 #
-# This Dockerfile utilizes a two step build process. It builds Intent Brokering
+# This Dockerfile utilizes a two step build process. It builds the Intent Brokering
 # service with statically linked dependencies (using musl) for a x86_64
 # architecture.
 

docs/design/intent_brokering_design.md

@@ -6,7 +6,7 @@
 
 ## <a name="introduction">Introduction</a>
 
-Project Eclipse Chariott delivers a metadata-driven application programming model. Today, the Intent Brokering service serves two main purposes. First, it offers service discovery of "provider" applications advertising their functionality. These providers register their capabilities with the intent broker. Second, the Intent Broker provides the brokering of intent requests from any application towards the offering providers. This was founded on [Capability Oriented Architecture](https://www.linkedin.com/pulse/brief-introduction-capability-oriented-architecture-coa-haishi-bai/) (COA). Since the service provides a common [gRPC](https://grpc.io/) interface for interacting with applications, it can be used with any language supporting gRPC. For more details on the gRPC interfaces, please see the [proto folder](../../intent_brokering/proto/).
+Project Eclipse Chariott delivers a metadata-driven application programming model. Today, the Intent Brokering service serves two main purposes. First, it offers service discovery of "provider" applications advertising their functionality. These providers register their capabilities with the Intent Broker. Second, the Intent Broker provides the brokering of intent requests from any application towards the offering providers. This was founded on [Capability Oriented Architecture](https://www.linkedin.com/pulse/brief-introduction-capability-oriented-architecture-coa-haishi-bai/) (COA). Since the service provides a common [gRPC](https://grpc.io/) interface for interacting with applications, it can be used with any language supporting gRPC. For more details on the gRPC interfaces, please see the [proto folder](../../intent_brokering/proto/).
 
 ## <a name="architecture">Architecture</a>
 
@@ -41,24 +41,24 @@ Below is the component diagram.
 3. The AnnounceRequest is sent to the Intent Broker. This step is optional, but it will tell the provider if they have already been registered.
 4. A result of “ANNOUNCED” means that a provider with this namespace is not currently in the registry.
 5. A RegisterRequest adds the provider to the Intent registry. It sends its service information and the intents it can fulfill.
-6. When this change is triggered, on_change will get called to add the intent bindings for this provider to the intent broker.
+6. When this change is triggered, on_change will get called to add the intent bindings for this provider to the Intent Broker.
 7. A RegisterResponse is sent back to the provider
 8. Provider starts a loop of AnnounceRequests so it does not get pruned
 9. As long as the AnnounceResponse is NOT_CHANGED, the provider is still present in the registry. If at any point it receives an “ANNOUNCED” response, it should re-register itself with the Intent registry.
 10. Consuming application sends a Fulfill request to Discover the ‘sdv.sample.namespace’
 11. Intent Broker sends a Fulfill request to its intent binding for ‘sdv.sample.namespace’ Discover
 12. Consuming application returns a fulfillment response with a list of services for that namespace including the url, protocol, and schemaReference file (i.e. proto file name) for how to directly communicate with the provider
-13. The intent broker returns this fulfillment response to the consuming application
+13. The Intent Broker returns this fulfillment response to the consuming application
 14. Consuming application directly calls API_A on the provider (which it found in the schema file). This is an example of direct application communication after using the service for Service Discovery.
 15. Provider sends its response to the consuming application directly for API_A
 16. Consuming application sends a Fulfill request to Inspect information about ‘sdv.sample.namespace’
 17. Intent Broker sends a Fulfill request to its intent binding for ‘sdv.sample.namespace’ Inspect
 18. Provider sends a FulfillResponse with the properties of the provider.
-19. The intent broker returns this fulfillment response to the consuming application
+19. The Intent Broker returns this fulfillment response to the consuming application
 20. Consuming application sends a Fulfill Request to Invoke command1 on the ‘sdv.sample.namespace’
 21. Intent Broker sends a Fulfill request to its intent binding for ‘sdv.sample.namespace’
 22. Provider sends a FulfillResponse
-23. The intent broker returns this fulfillment response to the consuming application
-24. At this point, the provider exits. When this happens, it will no longer be pushing its continuous announce heartbeat to the Intent Brokering service. After a configured amount of time, the service will be pruned from the registry and on_change will get called to remove the intent bindings for this provider to the intent broker.
+23. The Intent Broker returns this fulfillment response to the consuming application
+24. At this point, the provider exits. When this happens, it will no longer be pushing its continuous announce heartbeat to the Intent Brokering service. After a configured amount of time, the service will be pruned from the registry and on_change will get called to remove the intent bindings for this provider to the Intent Broker.
 25. Consuming application sends a Fulfill request to Discover the ‘sdv.sample.namespace’
 26. Since the provider has been removed from the registry, it will return an Error saying no provider found.

intent_brokering/README.md

@@ -32,7 +32,7 @@ an intent with the Intent Broker, other applications can use that intent to inte
 the provider. The intent is a gRPC method that is defined in the provider's
 protobuf definition. That definition is only used by the Intent Broker itself.
 
-The intent broker also provides a gRPC interface for applications to interact with
+The Intent Broker also provides a gRPC interface for applications to interact with
 providers and delegates the calls based on the intent to the provider transparently.
 Therefore, clients don't need to know the location and details of the provider as long as
 their intent is fulfilled.

intent_brokering/common/src/streaming_ess.rs

@@ -18,7 +18,7 @@ use uuid::Uuid;
 type EventSubSystem<T> = ess::EventSubSystem<Box<str>, Box<str>, T, Result<Event, Status>>;
 
 /// [`StreamingEss`](StreamingEss) integrates the reusable
-/// [`EventSubSystem`](ess::EventSubSystem) component with the intent broker gRPC
+/// [`EventSubSystem`](ess::EventSubSystem) component with the Intent Broker gRPC
 /// streaming contract. Cloning [`StreamingEss`](StreamingEss) is cheap, it will
 /// not create a new instance but refer to the same underlying instance instead.
 #[derive(Clone)]

intent_brokering/examples/applications/cloud-object-detection/README.md

@@ -5,8 +5,8 @@ Cognitive Services.
 
 To run the application:
 
-1. Start chariott runtime by executing `cargo run -p intent_brokering`
-2. Start it by executing `cargo run` from the
+1. Start the Intent Brokering runtime by executing `cargo run -p intent_brokering`
+2. Start the cloud object detection by executing `cargo run` from the
    `intent_brokering/examples/applications/cloud-object-detection` directory while specifying
    `COGNITIVE_ENDPOINT` (i.e. `myendpoint.cognitiveservices.azure.com`) and
    `COGNITIVE_KEY` environment variables.

intent_brokering/examples/applications/invoke-command/README.md

@@ -30,7 +30,7 @@ Once the service is confirmed registered, the below command can be run to call a
 on the provider. The command takes a json string and parses it/prints it out on the provider side.
 The 'command' parameter is used to tell the desired provider what command to run.The 'args'
 parameter is a list of arguments for the command. The args can be several types, defined
-in `proto\intent_brokering\common\v1\common.proto` file under the `Value` message.
+in `proto/intent_brokering/common/v1/common.proto` file under the `Value` message.
 
 ```bash
 grpcurl -plaintext -d @ 0.0.0.0:4243 intent_brokering.runtime.v1.IntentBrokeringService/Fulfill <<EOF

intent_brokering/examples/applications/local-object-detection/README.md

@@ -5,7 +5,7 @@ TensorFlow and ssd_mobilenet_v1_coco model.
 
 To run the application:
 
-1. Start intent brokering runtime by executing `cargo run -p intent_brokering`
+1. Start the Intent Brokering runtime by executing `cargo run -p intent_brokering`
 2. Start detection application by executing `cargo run` from the
    `intent_brokering/examples/applications/local-object-detection` directory.
 3. In the root directory create a `detect_image.json` file with the following

intent_brokering/examples/applications/mock-vas/README.md

@@ -4,7 +4,7 @@ This code sample shows you how to use the mocked VAS for the dog mode scenario.
 The dog mode allows a car owner to keep their dog safe, while they are away from
 the car.
 
-## How-to consume a streaming service using Chariott intent brokering
+## How-to consume a streaming service using Chariott Intent Broker
 
 > As an application developer, I want to consume events from a streaming
 > service.
@@ -39,7 +39,7 @@ From the root directory:
    ```
 
    This makes a single request for 2 subscription intents for the
-   dog mode status and the temperature events to the intent broker. The intent broker then passes these
+   dog mode status and the temperature events to the Intent Broker. The Intent Broker then passes these
    intents to the mock-vas that can fulfill them.
 5. In terminal B, type `temp 20` in the standard input and notice the response
    coming through terminal C. However, if you type `battery 10` you see that

intent_brokering/examples/applications/simulated-camera/README.md

@@ -7,9 +7,9 @@ manual mode where you specify the frame rate event yourself.
 
 ## To run the application
 
-1. Start intent brokering runtime by executing `cargo run -p intent_brokering` from the root directory
+1. Start the Intent Brokering runtime by executing `cargo run -p intent_brokering` from the root directory
 2. Navigate to `intent_brokering/examples/applications/simulated-camera` directory
-3. Create a `images` directory and place there all the `.jpg` files you want the
+3. Create an `images` directory and place there all the `.jpg` files you want the
    camera application to stream
 4. Start camera application by executing `cargo run` from the
    `intent_brokering/examples/applications/simulated-camera` directory.
@@ -36,7 +36,7 @@ manual mode where you specify the frame rate event yourself.
    ```
 
    This makes a single request for a subscription intent for simulated camera
-   frames arriving at the desired frame per minute rate. The broker then passes
+   frames arriving at the desired frame per minute rate. The Intent Broker then passes
    these intents to the simulated camera application that can fulfill it.
 
    Other allowed sources (i.e. event rate) can be found via `Inspect` intent:

intent_brokering/proto/intent_brokering/common/v1/common.proto

@@ -113,7 +113,7 @@ message InspectFulfillment {
 /**
 * Invoke Intent
 *
-* The invoke intent is used to invoke a method on the application through the intent brokering runtime.
+* The invoke intent is used to invoke a method on the application through the Intent Brokering runtime.
 */
 message InvokeIntent {
     string command = 1;

intent_brokering/proto/intent_brokering/provider/v1/provider.proto

@@ -5,7 +5,7 @@
 /**
 * Provider definition
 *
-* This proto file defines the contract between the intent broker and an intent provider.
+* This proto file defines the contract between the Intent Broker and an intent provider.
 */
 
 
@@ -18,7 +18,7 @@ import "intent_brokering/common/v1/common.proto";
 /**
 * The provider service definition.
 *
-* This service is used by intent_brokering to communicate with the provider. Each service application
+* This service the Intent Broker to communicate with the provider. Each service application
 * that wants to be a provider must implement this service.
 */
 service ProviderService  {

intent_brokering/proto/intent_brokering/streaming/v1/streaming.proto

@@ -7,9 +7,9 @@
 *
 * This contract is used to stream data from a service application registered as provider and
 * a service application that is a consumer. This interface will be discovered using the
-* `Discover` intent through the intent broker runtime. The communication is done after discovery
-* peer to peer without the intent broker being involved. Only the subscription of sources will be
-* handled by the intent broker again, but data flows peer to peer without the broker in between.
+* `Discover` intent through the Intent Broker runtime. The communication is done after discovery
+* peer to peer without the Intent Broker being involved. Only the subscription of sources will be
+* handled by the Intent Broker again, but data flows peer to peer without the broker in between.
 * More details found here:
 * [ADR-0016](docs/adr/ctp-2/0016-streaming-support.md)
 */

intent_brokering/src/main.rs

@@ -71,7 +71,7 @@ async fn main() -> Result<(), Box<dyn std::error::Error>> {
 
     tracing::info!("starting grpc services");
     let addr = format!("0.0.0.0:{PORT}").parse().unwrap();
-    tracing::info!("intent broker listening on {addr}");
+    tracing::info!("Intent Broker listening on {addr}");
 
     let server = Arc::new(IntentBrokeringServer::new(registry, broker));
     let router = Server::builder()

intent_brokering/tools/charc.md

@@ -1,7 +1,7 @@
 # `charc`
 
 `charc` is a Bash script for simple and quick session-based interactions with
-Chariott intent brokering. `charc` stands for _Chariott intent console_.
+Chariott Intent Brokering. `charc` stands for _Chariott intent console_.
 
 ## Usage
 
@@ -24,7 +24,7 @@ Chariott intent brokering. `charc` stands for _Chariott intent console_.
 
     charc inspect <namespace> <query>
 
-Issues the _inspect intent_ to the intent broker for fullfilment by some provider
+Issues the _inspect intent_ to the Intent Broker for fullfilment by some provider
 providing the capability.
 
 For inspection of the intent registry of providers, use `system.registry`
@@ -36,7 +36,7 @@ for the `<namespace>` argument:
 
     charc discover <namespace>
 
-Issues the _discover intent_ to the intent broker for fullfilment by some provider
+Issues the _discover intent_ to the Intent Broker for fullfilment by some provider
 providing the capability, e.g.:
 
     ./charc discover sdv.vdt
@@ -48,7 +48,7 @@ connections.
 
     charc read <namespace> <key>
 
-Issues the _read intent_ to the intent broker for fullfilment by some provider
+Issues the _read intent_ to the Intent Broker for fullfilment by some provider
 providing the capability, e.g.:
 
     ./charc read sdv.kvs time
@@ -57,7 +57,7 @@ providing the capability, e.g.:
 
     charc write <namespace> <key> <value>
 
-Issues the _write intent_ to the intent broker for fullfilment by some provider
+Issues the _write intent_ to the Intent Broker for fullfilment by some provider
 providing the capability, e.g.:
 
     ./charc write sdv.kvs time "$(date)"
@@ -66,7 +66,7 @@ providing the capability, e.g.:
 
     charc invoke <namespace> <command> [(<type> <arg>)...]
 
-Issues the _invoke intent_ to the intent broker for fullfilment by some provider
+Issues the _invoke intent_ to the Intent Broker for fullfilment by some provider
 providing the capability.
 
 The arguments after `<command>` are always in pairs of `<type>` and `<arg>`,
@@ -113,7 +113,7 @@ eventually to close all opened streams.
 
     charc subscribe <namespace> <source>
 
-Issues the _subscribe intent_ to the intent broker for fullfilment by some provider
+Issues the _subscribe intent_ to the Intent Broker for fullfilment by some provider
 providing the capability, e.g.:
 
     ./charc subscribe sdv.kvs time
@@ -148,7 +148,7 @@ for `<namespace>` to open a streaming channel.
     charc show (req|request|rsp|response)
 
 Shows the last gRPC request (`req`) sent or response (`rsp`) received by the
-last sub-command that communicated with the intent broker.
+last sub-command that communicated with the Intent Broker.
 
 ### `end`