Hi Bernhard!<br><br>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.<br>
<br>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.<br>
<br><br><br>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.<br>
<br>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.<br>
<br>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.<br>
<br><br><br>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).<br>
<br>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. <br>
<br>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).<br>
<br><br><br>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.<br>
<br><br><br>Hope this helps you!<br><br>Cheers!<br>Adam<br>--<br>Adam Lindberg<br><a href="http://www.erlang-consulting.com">http://www.erlang-consulting.com</a><br><br><div class="gmail_quote">On Fri, May 16, 2008 at 9:27 AM, Bernhard Damberger <<a href="mailto:bernied@gmail.com">bernied@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
I am trying to understand how to organize some otp based code I am thinking<br>
of writing. I have WSDL for SOAP that has about 10 API calls which each take<br>
a fair number of parameters and do a significant chunk of work.<br>
<br>
What is the best way to organize this?<br>
<br>
Do I create one gen_server per SOAP call to handle each different request?<br>
<br>
Or do I create one gen_server for all the SOAP calls and do some sort of<br>
dispatch internally?<br>
<br>
What is the granularity that the gen_server should have?<br>
<br>
In the former case it seems to me, an application then becomes a collection<br>
of gen_servers which are all started up together?<br>
<br>
Another question which is about Yaws. For this kind of application does it<br>
make sense to have Yaws run the application, or to have it embedded in the<br>
application?<br>
<br>
Any hints or advice on the "standard" way to organize otp applications and<br>
the granularity of various behaviors are greatly appreciated. Thanks.<br>
<br>
_bernhard<br>
<font color="#888888">--<br>
View this message in context: <a href="http://www.nabble.com/otp-application-organization-tp17269040p17269040.html" target="_blank">http://www.nabble.com/otp-application-organization-tp17269040p17269040.html</a><br>
Sent from the Erlang Questions mailing list archive at Nabble.com.<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
</font></blockquote></div><br>