Software (Open-Source):
Interactive Command Modules (ICM) and Players
A Framework For Cohesive Generalized Scripting
http://www.by-star.net/PLPC/180050 — [4]
Remote Operations Interactive Command Modules (RO-ICM)
Best Current (2019) Practices For Web Services Development
http://www.by-star.net/PLPC/180056 — [3]
A Generalized Swagger (OpenAPI) Centered Web Services Invocations And Testing Framework
http://www.by-star.net/PLPC/180057 — [1]
Extending SON To Clouds And Things
GOSSONoT: A Generalized Open-Source Self Organizing Network of Things Platform
http://www.by-star.net/PLPC/180052 — [2]
This Software is Part Of A Much Bigger Picture.
This Software Is Part Of:
The Libre-Halaal ByStar Digital Ecosystem
And Part Of:
BISOS: ByStar Internet Services OS
This software is primarily being used and developed in that context.
Implemenation Of Remote Operations Can Typically Be Structured As:
This document focuses on Remote Invoker Implementation.
You should read this document alongside the mentioned documents.
Interactive Command Modules (ICM) allow for consistent Direct and Remote Operations.
Our implementation model for remote operations is based on the model of Interactive Command Modules (ICM).
The Interactive Command Modules Framework allows for a Direct Operation to be split into a Performer Remote Operation module and an Invoker Remote Operation module.
The Interactive Command Modules Framework allows for a Remote Operation to also be used as Direct Remote.
The Interactive Command Modules Framework allows for operations to be mapped to command-line invocations.
Given a Service Definition (a swagger file) and a Performer Server, you should be able to conveniently Invoke any of the offered Operations through:
Main software packages that implement the framework include:
Install The Software:
Run The PetStore Example:
svcOpsList command digests the Service Specification (swagger-file) specified on command line as --svcSpec= parameter and produces a complete list of ALL remotely invokable commands with their corresponding --resource, --opName and url or body arguments. Applicable options, parameters and arguments are: * Parameter (Mandatory) : --svcSpec= * Parameter (Optional) : --perfSap= --headers=
rinvoker command invokes the "opName" operation at "resource" with specified arguments. Applicable options, parameters and arguments are: * Parameter (Mandatory) : --svcSpec= --resource= --opName= * Parameter (Optional) : --perfSap= --headers= * Arguments : name=value bodyStr=jsonStr
The swagger file as a url or as a json/yaml file is specified with the –svcSpec= parameter.
The Performer Service Access Point Address (perfSap) is specified as a URL with the –perfSap= parameter.
Additional headers (e.g., a token) can be included with the –svcSpec= parameter.
The resource to be invoked should be specified with the –resource= parameter
The operation name to be invoked should be specified with the –opName= parameter
Allows you to list all possible invocations based on a service specification (swagger file).
rinvoker.py --svcSpec="http://petstore.swagger.io/v2/swagger.json" -i svcOpsList
Allows you to fully specify an invocation on command line. Example:
rinvoker.py --svcSpec="http://petstore.swagger.io/v2/swagger.json" --resource="user" --opName="createUser" -i rinvoke bodyStr="{...}"
In pure python specify invocation of each operation, for example:
thisRo = ro.Ro_Op( svcSpec=petstoreSvcSpec, perfSap=petstoreSvcPerfSap, resource="pet", opName="getPetById", roParams=ro.Ro_Params( headerParams=None, urlParams={ "petId": 1}, bodyParams=None, ), roResults=None, ) rosList.opAppend(thisRo)
Building on the previously mentioned Operation Specification, in pure python you can the specify Operation Expectations, for example:
thisExpectation = ro.Ro_OpExpectation( roOp=thisRo, preInvokeCallables=[sleep1Sec], postInvokeCallables=[ verify_petstoreSvcCommonRo, ], expectedResults=None, ) roExpectationsList.opExpectationAppend(thisExpectation)
preInvokeCallables(ro.Ro_OpExpectation) can include a function that initializes the DB or sleepFor1Sec.
postInvokeCallables(ro.Ro_OpExpectation) can include a function that verifies the result was as expected and then reports success or failure.
opScn-seed provides the following commands and parameters:
roListInv command serially invokes the list of ro.Ro_Op() opersations specified in the loaded scenario files. roListInv displays the invokation and its results. But does not do any verifications. Applicable options, parameters and arguments are: * Parameter (Mandatory) : --load=
roListExpectations command serially invokes the list of ro.Ro_OpExpectation() specified in the loaded scenario files. roListExpectations displays the invokation and its results and additionally runs the list of preInvokeCallables and postInvokeCallables. postInvokeCallables can include functions that verify the results of the invocation were as expected. Applicable options, parameters and arguments are: * Parameter (Mandatory) : --load=
The output format is:
* ->:: Invoke Request * <-:: Invoke Response * ==:: Invoke Validation (SUCCESS or FAILURE)
Additional information for each is include with "**" tags.
This output format can then be used in outline or org-mode.
With these in place, building Invoke-Apps becomes very simple.
Very Often, These Best Current Practices Are Not Being Followed.