[erlang-questions] Multiple applications
Sun Nov 11 08:00:52 CET 2012
Your questions allow me to understand the problem better. Thanks
:) Maybe the terms "master application" and "plugin application" is
not totally appropriate. In java world it would be:
master application = application server,
plugin application = application (or user application).
The application server governs all the user applications, provides
some infrastructure and delegates some work to them. I would like to
have ability to add those applications freely, but once particular
user application added, the application server should proceed with its
own processing only when the added application is available.
Maybe another way to solve this is to reverse the runtime
dependency: "the user applications take tasks from a queue provided by
the application server" instead of "the application server delegates
tasks to user applications". I need to think about that more. The
requirement for the solution to support cluster operation is not
making things clearer :)
On Sun, Nov 11, 2012 at 3:16 AM, Garrett Smith <> wrote:
> What makes the plugins "pluggable"? If there's no uncertainly about
> what might be registered, it might make more sense to define the
> workers as children of a supervisor in your main app.
> If you're breaking these into separate apps to manage complexity, then
> I suspect you're looking at your option 1 -- library style apps that
> are required by the main app.
> If it's not know ahead of time what the plugins are, what is the
> trigger for processing? Is it a certain number of plugins? A total
> worker capacity?
> On Sat, Nov 10, 2012 at 4:02 PM, Karolis Petrauskas
> <> wrote:
>> Thank you for the comments. It sounds reasonable to go with active
>> applications. One aspect I forgot to mention is that the main
>> application should start its own processing only when all the required
>> plugins are ready. The plugin applications act as backend processors.
>> Maybe that could be solved in more abstract way: the main application
>> could be configured with names of processes (or incoming messages) to
>> wait for before processing is started. Although I am not sure if such
>> an approach is "erlangish", I was deep in java for last ten years.
>> On Sat, Nov 10, 2012 at 6:15 PM, Garrett Smith <> wrote:
>>> On Sat, Nov 10, 2012 at 1:11 AM, Karolis Petrauskas
>>> <> wrote:
>>>> I am building an Erlang based system that is composed of several
>>>> applications. In principle, the system consists of a main application
>>>> and a number of "plug in applications". The latter have modules
>>>> implementing behaviours defined by the main application. In this
>>>> particular case, should I have all the "plug in applications" as
>>>> library applications, and access them from the main application based
>>>> on some explicit configuration? Or should all the applications have
>>>> its own application modules starting own supervisors and then
>>>> registering self to the main application? The main thing confusing me
>>>> is the recommendation to have single supervision tree for the entire
>>> There are good reasons for taking either approach, but if you're in
>>> doubt, I'd suggest the second option: each plugin is an "active"
>>> application (i.e. specifies a mod in the .app file) that registers
>>> itself as needed with the main application.
>>> The advantage to this approach is that you're further separating the
>>> components of your system:
>>> - The main application doesn't have to know about the plugins at
>>> startup, which simplifies its configuration and removes the "wiring"
>>> logic that it would otherwise need
>>> - Plugins can be added and removed by adding and removing OTP
>>> applications in the release (i.e. you use boot files to specify which
>>> plugins are run for a given Erlang process)
>>> The OTP application abstraction in Erlang is very powerful in this
>>> respect, as long as you design your applications to be as independent
>>> as possible from one another. You can add new functionality to a
>>> system by the simple act of starting a new application!
>>> Your only real design consideration then is how the plugin apps
>>> register with the main application. This is a good spot for a
>>> gen_event, or pub/sub broker model, where you use an intermediary
>>> process to broker messages/requests between the main application and
>>> the plugins.
More information about the erlang-questions