[erlang-questions] otp application organization

[Adam Lindberg]

Hi Bernhard!

First of all, think about what you want to do. If we're talking about
decoding, the code should be run in the calling process, I suppose in your
case the Yaws processes (for each request), so that it's not bottlenecked in
a gen_server somewhere when it's not needed to.

If you're taking care of requests coming from a web server, they're run in
the request process in the beginning. Try to keep them there as long as
possible. Only route them to a common gen_server if they are dependent on
each other and the state of the gen_server.



Example 1: You have a booking system that enables you to book a meeting room
for example. In this case, there should be a gen_server (or any process, for
that matter) that takes care of all requests for a resource (e.g. a room)
that can be raced to or used simultaneously.

Example 2: You have a calendar system in which users can edit and view their
personal calendars. In this case, there should be a process for each users
calendar, and not for each request, since the users calendar is the resource
that is being used and can be raced to.

Example 3: You have a math server which performs calculations based on
independent input data. In this case, why not go for the web server process
all the way, since no central resource is being modeled in the system.



As for OTP applications, the common case is that an application owns a top
level supervisor, which starts any sub-processes (either at application
startup or dynamically when needed). Then everything is handled behind the
scenes when you call application:start(my_app).

So let's say we have the room booking system, here you would read which
rooms are available at startup, create a process for each room when you
start the application. Also if rooms are added at runtime, you can start
another process for them. Or remove, if a rooms is deleted. The application
supervisor is always started at application start and is always available so
that you can add and remove subprocesses.

If you're having a system which has these "semi-static" processes (based on
configuration) and also other dynamic process (e.g. created for off-loading
certain processing tasks) it could probably make sense to have one
supervisor for each type of process (look into the simple_one_for_one
supervisor pattern when creating small dynamic processes that perform a
small task and then die).



As for Yaws, it depends on how the rest of your systems looks. If you share
the node with many other applications that access Yaws too, make Yaws
standalone. If you have this and only this application using Yaws, why not
embed it? Another application could embed another Yaws on another port
should that be necessary and you can later rip out Yaws and make it
standalone when that is needed.



Hope this helps you!

Cheers!
Adam
--
Adam Lindberg
http://www.erlang-consulting.com

On Fri, May 16, 2008 at 9:27 AM, Bernhard Damberger <bernied@REDACTED>
wrote:

>
> I am trying to understand how to organize some otp based code I am thinking
> of writing. I have WSDL for SOAP that has about 10 API calls which each
> take
> a fair number of parameters and do a significant chunk of work.
>
> What is the best way to organize this?
>
> Do I create one gen_server per SOAP call to handle each different request?
>
> Or do I create one gen_server for all the SOAP calls and do some sort of
> dispatch internally?
>
> What is the granularity that the gen_server should have?
>
> In the former case it seems to me, an application then becomes a collection
> of gen_servers which are all started up together?
>
> Another question which is about Yaws. For this kind of application does it
> make sense to have Yaws run the application, or to have it embedded in the
> application?
>
> Any hints or advice on the "standard" way to organize otp applications and
> the granularity of various behaviors are greatly appreciated. Thanks.
>
> _bernhard
> --
> View this message in context:
> http://www.nabble.com/otp-application-organization-tp17269040p17269040.html
> Sent from the Erlang Questions mailing list archive at Nabble.com.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080516/f1af80cb/attachment.htm>