Polyglot Plugin Patterns Part 2
In a previous post, I discussed a general approach to writing Cloudify plugins in languages other than Python. I got as far as discussing the implementation of an example Go plugin, but stopped short of describing a Java plugin, which is the topic of this post. I encourage you to read the previous post for context, as this post assumes you have that background.
A cloudify plugin is a Python package containing Cloudify DSL definitions (typically types, relationships, and/or workflows) that permits easy re-use across blueprints. Since a plugin is a Python package, there needs to be a "bridge" of sorts between Python and the target language (Java in this case). This "bridge" takes two forms in my examples; the "operation" bridge - a small "shim" of Python code that executes a process, and the "context" bridge - a small HTTP server that permits the foreign language code to access the Cloudify context which is crucial for logging and setting and getting runtime properties.
In the case of Go code, which must be built for each target architecture, the source code itself was bundled in the plugin project. When first accessed, an executable is built which is then executed by the plugin Python "shim".
With all approaches, a non-Python plugin needs an executable to run. In the case of Java, this is an executable jar. Unlike Go, Java doesn't need to be built per-architecture, so it can be built in advance and the resulting jar packaged with the plugin. By convention, this plugin is named plugin.jar.