Web applications unification

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Web applications unification

Mikael Karlsson
Hi,

The workgroup at www.erlang-projects.org for a Web applications unification
seems really interesting and the visions are impressive. I do not know the
progress of the project but expect that it is quite a lot of work to be done,
even when implemented in Erlang :-)

Meanwhile I have a question how to get the act together to use some of the
existing applications/libraries for a more simple web application framework -
in a jboss (www.jboss.org) or Apache/Tomcat fashion.
Erlang makes it "easy" to write http servers and clients and it seems that
everyone contributing with applications like xmlrpc, idx-soap, proxies etc.
roll their own. This is fine as long as it runs standalone, but when you want
to integrate services in an application framework things get more
complicated. So why not set some kind of standard interface or framework
to build it on?

Like:
- http server: Yaws
- http client:  inets (originally jnets) http.erl
- ODBC, Corba etc: Erlang/OTP
- application control/configuration: Erlang/OTP
- authentication: eldap ?
- XML: xmerl
- XML-RPC: xmlrpc (with interface to yaws and inets/http client)
- SOAP: idx-soap (with interface to yaws and inets/http client)

I think most things are (almost) in place to build a *really good* web
application framework with Erlang.
And I think that any higher order applications as the "Web applications
unification" would benefit from a standard interface too.

So, is this a good idea, any ideas how to get the things together?
Would one need a dedicated framework application to drive and
configure the others?

/Mikael



Reply | Threaded
Open this post in threaded view
|

Web applications unification

Ulf Wiger-4
On Tue, 27 May 2003, Mikael Karlsson wrote:

>So why not set some kind of standard interface or framework
>to build it on?
>
>Like:
>- http server: Yaws
>- http client:  inets (originally jnets) http.erl
>- ODBC, Corba etc: Erlang/OTP
>- application control/configuration: Erlang/OTP
>- authentication: eldap ?
>- XML: xmerl
>- XML-RPC: xmlrpc (with interface to yaws and inets/http client)
>- SOAP: idx-soap (with interface to yaws and inets/http client)
>
>I think most things are (almost) in place to build a
>*really good* web application framework with Erlang.


I agree. I also added 'builder' to jungerl as an attempt to
provide a lightweight aide for packaging OTP applications
and building start scripts. I don't know how well it
succeeded (and it does need more work).

The general idea was that you should be able to
incrementally build more and more complex systems with
relative ease.

/Uffe
--
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson AB, Connectivity and Control Nodes



Reply | Threaded
Open this post in threaded view
|

Web applications unification

Mikael Karlsson
tisdag 27 maj 2003 13:36 skrev Ulf Wiger:

> On Tue, 27 May 2003, Mikael Karlsson wrote:
> >So why not set some kind of standard interface or framework
> >to build it on?
> >
> >Like:
> >- http server: Yaws
> >- http client:  inets (originally jnets) http.erl
> >- ODBC, Corba etc: Erlang/OTP
> >- application control/configuration: Erlang/OTP
> >- authentication: eldap ?
> >- XML: xmerl
> >- XML-RPC: xmlrpc (with interface to yaws and inets/http client)
> >- SOAP: idx-soap (with interface to yaws and inets/http client)
> >
> >I think most things are (almost) in place to build a
> >*really good* web application framework with Erlang.
>
> I agree. I also added 'builder' to jungerl as an attempt to
> provide a lightweight aide for packaging OTP applications
> and building start scripts. I don't know how well it
> succeeded (and it does need more work).
>
> The general idea was that you should be able to
> incrementally build more and more complex systems with
> relative ease.
>
> /Uffe

Yes, hmm this means that one should use generic behaviours like
gen_server etc. in such a framework?

I noticed that xmlrpc uses generic behaviours in the latest version (1.13),
but I can not find any "-behaviour(gen_server)" statement in the code.
How is that?

For SOAP there is also ErlSOAP 0.2, which seems to make use of
inets http client:
http://www.erlang-projects.org/Public/projects/services/erlsoap_0.2/view

Wouldn't the Erlang projects site be good forum for setting an application
server framework/interface ?

/Mikael


Reply | Threaded
Open this post in threaded view
|

Web applications unification

jocke
Mikael Karlsson wrote:

>tisdag 27 maj 2003 13:36 skrev Ulf Wiger:
>
>>On Tue, 27 May 2003, Mikael Karlsson wrote:
>>
>>>So why not set some kind of standard interface or framework
>>>to build it on?
>>>
>>>Like:
>>>- http server: Yaws
>>>- http client:  inets (originally jnets) http.erl
>>>- ODBC, Corba etc: Erlang/OTP
>>>- application control/configuration: Erlang/OTP
>>>- authentication: eldap ?
>>>- XML: xmerl
>>>- XML-RPC: xmlrpc (with interface to yaws and inets/http client)
>>>- SOAP: idx-soap (with interface to yaws and inets/http client)
>>>
>>>I think most things are (almost) in place to build a
>>>*really good* web application framework with Erlang.
>>>
>>I agree. I also added 'builder' to jungerl as an attempt to
>>provide a lightweight aide for packaging OTP applications
>>and building start scripts. I don't know how well it
>>succeeded (and it does need more work).
>>
>>The general idea was that you should be able to
>>incrementally build more and more complex systems with
>>relative ease.
>>
>>/Uffe
>>
>
>Yes, hmm this means that one should use generic behaviours like
>gen_server etc. in such a framework?
>
>I noticed that xmlrpc uses generic behaviours in the latest version (1.13),
>but I can not find any "-behaviour(gen_server)" statement in the code.
>How is that?
>

The server part of the xmlrpc lib _behaves_ as a gen_server it isn't
written using a gen_server behaviour though.

Like this:
http://www.erlang.org/doc/r9b/doc/design_principles/spec_proc.html
as in:
http://www.gleipnir.com/xmlrpc/unpacked/LATEST/src/tcp_serv.erl

/Jocke




Reply | Threaded
Open this post in threaded view
|

Web applications unification

Ulf Wiger (AL/EAB)
In reply to this post by Mikael Karlsson
On Tue, 27 May 2003, Mikael Karlsson wrote:

> tisdag 27 maj 2003 13:36 skrev Ulf Wiger:
> >
> > I agree. I also added 'builder' to jungerl as an attempt to
> > provide a lightweight aide for packaging OTP applications
> > and building start scripts. I don't know how well it
> > succeeded (and it does need more work).
> >
> > The general idea was that you should be able to
> > incrementally build more and more complex systems with
> > relative ease.
>
> Yes, hmm this means that one should use generic behaviours like
> gen_server etc. in such a framework?

If you want to use gen_servers, you could of course, but that has nothing to
do with builder.

The builder utility is intended to simplify the task of building .app files,
.rel files, and finally .script and .boot files in order to start a system.

When building a framework of different Open Source contributions, I think it
helps to agree on a way to start the appl?cations. OTP provides such a way.
What you want to do in the start function in order to get your processes
running is another matter. I believe that the gen_server behaviour is quite
useful, and I use it myself as much as I can, but it's not really something
that affects your APIs, so it's normally an internal implementation detail.

/Uffe



Reply | Threaded
Open this post in threaded view
|

Web applications unification

Mikael Karlsson
In reply to this post by jocke
Joakim G. wrote:
> Mikael Karlsson wrote:
..

> >I noticed that xmlrpc uses generic behaviours in the latest version
> > (1.13), but I can not find any "-behaviour(gen_server)" statement in the
> > code. How is that?
>
> The server part of the xmlrpc lib _behaves_ as a gen_server it isn't
> written using a gen_server behaviour though.
>
> Like this:
> http://www.erlang.org/doc/r9b/doc/design_principles/spec_proc.html
> as in:
> http://www.gleipnir.com/xmlrpc/unpacked/LATEST/src/tcp_serv.erl
>

Thanks,

I will not ask you why you implement your own gen_server :-)

One note, the spec. says that you also must implement the function:
system_code_change(Misc, OldVsn, Module, Extra) -> {ok, NMisc} | Error.
Neither tcp_serv.erl or the example in the spec. implements it so is this not
really necessary? I guess that if I write code for own use and know that it
will not be updated on a running system thats ok, but for generic libraries ?

/Mikael



Reply | Threaded
Open this post in threaded view
|

Web applications unification

Mikael Karlsson
In reply to this post by Ulf Wiger (AL/EAB)
onsdag 28 maj 2003 01:08 skrev Wiger Ulf:

> On Tue, 27 May 2003, Mikael Karlsson wrote:
> > tisdag 27 maj 2003 13:36 skrev Ulf Wiger:
> > > I agree. I also added 'builder' to jungerl as an attempt to
> > > provide a lightweight aide for packaging OTP applications
> > > and building start scripts. I don't know how well it
> > > succeeded (and it does need more work).
> > >
> > > The general idea was that you should be able to
> > > incrementally build more and more complex systems with
> > > relative ease.
> >
> > Yes, hmm this means that one should use generic behaviours like
> > gen_server etc. in such a framework?
>
> If you want to use gen_servers, you could of course, but that has nothing
> to do with builder.
>
> The builder utility is intended to simplify the task of building .app
> files, .rel files, and finally .script and .boot files in order to start a
> system.
>
> When building a framework of different Open Source contributions, I think
> it helps to agree on a way to start the appl?cations. OTP provides such a
> way. What you want to do in the start function in order to get your
> processes running is another matter. I believe that the gen_server
> behaviour is quite useful, and I use it myself as much as I can, but it's
> not really something that affects your APIs, so it's normally an internal
> implementation detail.
>
Thanks,
I guess a good starting point for such a framework would be that one should
implement the generic behaviour API then, so that a supervisor can start the
application or by using application:start.
This seems to be the case already for most contributions, either "by hand"
like in xmlrpc, or by implementing gen_{server,fsm,event} like yaws, btt,
inets/httpc_manager etc. Because those contributing knows how to do it
since ages ago :-)
If you provide a library with no processes, like xmerl, then there is of
course no need for this.
Then you have a choice of using builder and making .app, .rel, .script and
.boot files or using application:start in your own code?
I guess that using application:start to start other applications from my own
app is fine as long as my own contribution is standalone, but as soon as it
integrated by others it should not. If I for instance wan't to incorporate
BTT, (Bluetail Ticket Tracker), as a part in a larger application that also
uses Yaws, I probably do not wan't BTT to start and configure the Yaws
webserver. Just as an example, BTT is great.

/Mikael



Reply | Threaded
Open this post in threaded view
|

Web applications unification

Ulf Wiger-4
On Wed, 28 May 2003, Mikael Karlsson wrote:

>I guess a good starting point for such a framework would be
>that one should implement the generic behaviour API then,
>so that a supervisor can start the application or by using
>application:start.

If you have a runnable application, you need to write a
start/2 function and define it in an .app file. In most
cases, such a start function would call
supervisor:start_link(), and while this is definitely
recommended, it is no requirement.

There are other ways to start an erlang node, e.g. using the
-s flag and then calling application:start() (which assumes
the existence of an .app file), or simply spawning
processes. For a robust framework, we should definitely go
with the OTP way of doing things, since it works well, and
comes with both support and documentation.

>If you provide a library with no processes, like xmerl,
>then there is of course no need for this.

Correct.

>Then you have a choice of using builder and making .app,
>.rel, .script and .boot files or using application:start in
>your own code?

If your applications do not have a start function, using
builder will still give you the benefit of a start script,
always picking the latest version of each application (if
that's what you want, otherwise, a specific version of some
app) and making sure they're in the path, and semi-automatic
configuration of environment variables.

/Uffe
--
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson AB, Connectivity and Control Nodes