Issue-591: Holistic review of non-quarkus service orchestration chapter

serverlessworkflow/modules/ROOT/pages/service-orchestration/orchestration-of-openapi-based-services.adoc

@@ -55,7 +55,7 @@ For more information about the tooling, see {getting-familiar-with-our-tooling}[
 In the previous example function definition, the `type` attribute can be omitted as the link:{spec_doc_url}#Function-Definition[default value] is `rest`.
 ====
 
-In the previous example, the `operation` attribute is a string, which is composed using the following parameters:
+In the previous example, the `operation` attribute is a string composed of the following parameters:
 
 * URI that the engine uses to locate the specification file, such as `classpath`.
 * Operation identifier. You can find the operation identifier in the link:{open_api_spec_url}#fixed-fields-7[OpenAPI specification file].
@@ -180,7 +180,7 @@ components:
 <2> Data structure of the REST operation.
 --
 
-. Use the same `operationId` to compose the final URI in the function definition as shown in the following example:
+. Use the same `operationId` to compose the final URI in the workflow function definition as shown in the following example:
 +
 --
 .OpenAPI functions definition in the Temperature Conversion example
@@ -221,7 +221,7 @@ After defining the function definitions, you can access the defined functions in
 . Use a link:{spec_doc_url}#Action-Definition[workflow action] to call a function definition that you added.
 +
 --
-Any workflow action that consists of a similar approach of referencing the functions that you used in the function definition can call a defined function.
+Any workflow action can call a function defined in the function definition.
 --
 
 . To map the arguments of a function, you can refer to the parameters described in the link:{open_api_spec_url}#operation-object[Operation Object] section of OpenAPI specification.