A STIX/TAXII community member, Stephen Russett, recently contributed a new open source tool to the CTI community. Here is what he provided as guidance.
“The TAXII-Worker is a “External Task Worker”, which interacts with the Taxii server’s workflow engine. Whenever any work needs to be executed, rather than executing on the Taxii server, it is tasked for fetching by the cluster of Workers. This is all based on Vertx so you get clustering, non-blocking, and scaling.
The extra flavour for the worker is, it also can execute on GraalVM and use the polymorphic language support.
Example: you can have The STIX JSON be parsed by the OASIS STIX Python lib instead of the STIX-java lib. 
Or you can have your STIX 1.x json get upgraded to 2.x using The STIX elevator, but when it fails, the Workflow engine will trigger a manual task for human review of the specific STIX object that failed to “elevate” to 2.x, or if you have some scripts that execute custom manipulations of inbound data, you can easily drop this into the automation without custom standup of new systems. (Such as you can easily pass your data into a Node app and have it return back to the taxii server without have to build any “extras” )Another example would be if you wanted to parse data from STIX into some other non-STIX data format. You can use the workflow engine and the Graal execution to convert using your language of choice into the end format of your choice.
You can also use this setup to execute work on other systems, such as if a STIX cyber observable is evaluated and determined that some sort of script should be executed as mitigation or prevention. No need for extra layers of systems, you can execute this with ease, and with your language of choice. This also plays well into OpenC2 style of requirements, where the worker becomes a micro app which is the executor, and the workflow engine is the upstream Command system. The actual openC2 spec is just a light json layer on top.”