Migration from Java?

[Mikael Karlsson]

Hi Tim,
this would be the Erlang applications I would investigate:
As front end - 
Yaws : http://yaws.hyber.org/
for dynamic and static pages. It is a quite capable engine that has been
benchmarked for 80000 parallell sessions. See:
http://www.sics.se/~joe/apachevsyaws.html

For your XML/XSL support you could use xmerl:
http://sowap.sourceforge.net/

If you do not need to be XSL standards compliant xmerl has 
native support for transforms in an XSL:ish fashion:
http://www.creado.com/xmerl_xs/index.html

otherwise you have a Sablotron adapter:
http://www.lfcia.org/projects/sablotron_adapter/

Database:
The standard Erlang/OTP distribution comes with an odbc application
as well as the Erlang native database Mnesia. See the database 
folder under:
http://www.erlang.org/doc/r9c/doc/index.html

If you use http calls to the backend servers the http client in the inets
application (which is in Erlang/OTP) supports asynchromous calls.
The Yaws webserver also has a reverse proxy.

Now it is just to assemble the pieces  and start the application  :-) 

Good luck!
Mikael

Mon 20 Sep 2004 08:23 Tim Lavoie wrote:
> Hello all,
>
> I've stumbled across Erlang fairly recently, and have started reading,
> stepping through tutorials and so on. So far, so good! This has been
> primarily for my own interest, so far, but I can see where it might
> scratch an itch or two for my employer as well. It hasn't been
> suggested yet, never mind approved, but I would like to explore the
> ways in which Erlang might help, as well as any land mines to avoid.
>
> Perhaps it would be helpful to describe the current scenario to some
> degree, and where I see Erlang being helpful.
>
> Our current environment is modular, running on a variety of hardware
> and operating systems, with a web-based interface. A Java app server
> runs the front part, perhaps with a separate web server out in front,
> handling static content. The Java app is the main piece I'm involved
> with, and it touches everything. XSL templates are used to generate
> the pages dynamically, and a relational database is used fairly
> extensively. Also, some operations involve passing beefy chunks of XML
> to a separate number-crunching server, which can run for minutes on
> end.
>
> I'm not expecting to get anyone to make huge changes any time soon,
> but would like to at demonstrate that there are alternatives to some
> design choices which might be good to know about. If that helps
> improve things down the road, I'm happy.
>
> My main area of concern tends to be performance, so I have run
> repeatedly into areas which could use help.
>
> First, XSL. I understand now why it was chosen, back in the mists of
> time. I don't know that Erlang is able to help directly here, but it
> does cause headaches. Even if things stay in Java, there is some hope
> that this will go away. It's fine for morphing documents on occasion,
> but brutal when generating many large, dynamic pages while someone is
> waiting. Incidentally, my boss was the original architect, but took it
> well when I ranted unwittingly about this particular ugliness in his
> baby. I'm guessing there is hope for future change.  <grin>
>
> Now, the main issue as I see it is that scalability is a problem. The
> performance woes are less apparent when subjected to few users, and
> the application server layer can be scaled with more hardware... given
> sufficient will and resources.  Still, a few dozen users on this large
> app, and the app server is suffering badly.
>
> One area I can see Erlang's approach helping is with asyncronous I/O,
> combined with message passing. Right now, everything effectively
> blocks sequentially. Page transitions mean that current state gets
> written to the database, though most often this is "just in
> case". Similarly, requests needing that back-end number cruncher
> essentially tie up the user's browser until it comes back.
>
> I can see the database writes being implemented as sending the message
> to a process which handles the details, with the original web request
> then continuing on its way without waiting. This isn't generally an
> issue in my performance-test environment, but on client sites, with
> different networking and servers, it creates delays. In the case where
> the original process needs the result, it could ask for notification
> back, and carry on from there.
>
> The requests to the back-end server(s) are similar, and also block
> until done. Some of these requests naturally take longer than others,
> so I see Erlang as providing something of a more intelligent
> queue. Now, all requests are spawned together, so they slow down if
> there are more requests than processors. I'd like to see this as a
> queue with a notification back, like the database. Also, since we know
> what type of requests take much longer, Erlang's selective receive
> mechanism is a natural for giving priority to those which should
> return quickly.
>
> Phew... Sorry, that was long-winded, and I still have questions.
>
>  - Has anyone migrated a large project of this sort? How did it go?
>
>  - Is there some equivalent of Java's JDBC? Relational databases are
>  pretty much a given, and persistent connection pools are pretty much
>  required. I have seen mention of ODBC for Erlang; if this does the
>  trick, particularly from Linux, that's a good start. Targets are the
>  main RDBMS vendors, on several platforms.
>
>  - Any other suggestions are naturally welcome.
>
>
>    Thanks!
>    Tim Lavoie