Session module

[David Hayek]

Hello

By way of background, my current job involves programming J2EE applications.  But I discovered Erlang and Yaws a while back and have been working with them in my spare time ever since. 

One of the things I like about the J2EE servlet specification is its handling of sessions as a way of storing arbitrary data across user requests in a hash table.  I know Yaws has cookie-based sessions, but no formal way to set and get attributes for a user's session, so I created the session module below for a project I'm working on now.

I'm not sure where to submit this, so I'm posting it to the mailing list.  I'm not sure if something like this would be useful to other developers.

What I would also like to do is create distributed sessions.  I don't believe that distributed sessions are part of the J2EE specification, but most (all?) implementations offer distributed sessions as a configurable parameter for reasons of failover and general "enterprisy-ness".  To store session data, the yaws_session_server module uses ETS tables, which I believe are not distributable (please correct me if I'm wrong).  But mnesia tables are distributable.  I'm still trying to think of a way to implement this which would be in keeping with the general structure of the Yaws code.  However, since I'm fairly new to Yaws and Erlang, I'm struggling a little bit.  My questions to the group about this are:

1.  Would distributed sessions be useful for Yaws applications?

2.  If so, what would be a good way to approach the problem?


%%%----------------------------------------------------------------------
%%% File    : session.erl
%%% Author  : David Hayek dhayek@...
%%% Purpose : Adds a wrapper module around cookie-based sessions which
%%%           implements methods similar to those described in
%%%           the J2EE HttpSession interface, which is used (mostly) for storing key/value pairs:
%%%           http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/http/HttpSession.html
%%%
%%% Created : 8 October 2009 by David Hayek dhayek@...
%%%----------------------------------------------------------------------
-module(session).

-author('dhayek@...').

-include_lib("yaws/include/yaws_api.hrl").

-define(Y_SESSION_ID, "YSESSIONID").

-export([setAttribute/3, getAttribute/2, removeAttribute/2]).
-export([getAttributeNames/1, getSessionId/1, invalidate/1]).

%% Some methods defined by the HttpSession interface that can
%% be implemented in this session module if we modify the
%% yaws_session_server and yaws_api to support them.
%% -export([getCreationTime/1, getLastAccessedTime/1]).



%% returns
%% ok, if there is a session started already
%%
%% {new, CookieKey, Cookie} if this is a new session
%% and the calling routine should include this
%% as one of the return values for the out/1 function
%%
%% How do we make this function more transparent to the
%% calling function?  It would be nice if the cookie
%% header could be added to the response without forcing
%% the calling function to check for the existence of
%% a new session and then adding it to the
%% return value of the out/1 function.  I'm not familiar
%% enough with yaws_api to know if this is possible
%% with the current api.

setAttribute(Arg, Key, Value) ->
    H = Arg#arg.headers,
    C = H#headers.cookie,
    case
        yaws_api:find_cookie_val(?Y_SESSION_ID, C) of
            [] ->
                Dict = dict:new(),
                Dict2 = dict:store(Key, Value, Dict),
                Cookie = yaws_api:new_cookie_session(Dict2),
                {new, ?Y_SESSION_ID, Cookie};
            Cookie ->
                case yaws_api:cookieval_to_opaque(Cookie) of
                    {ok, Dict} ->
                        Dict2 = dict:store(Key, Value, Dict),
                        yaws_api:replace_cookie_session(Cookie, Dict2),
                        ok;
                    _ ->
                        Dict = dict:new(),
                        Dict2 = dict:store(Key, Value, Dict),
                        Cookie2 = yaws_api:new_cookie_session(Dict2),
                        {new, ?Y_SESSION_ID, Cookie2}
                end
        end           
    .

%% returns Value or undefined
getAttribute(Arg, Key) ->
    H = Arg#arg.headers,
    C = H#headers.cookie,
    case yaws_api:find_cookie_val(?Y_SESSION_ID, C) of
        [] ->
            undefined;
        Cookie ->
            case yaws_api:cookieval_to_opaque(Cookie) of
                {ok, Dict} ->
                    Value =
                        case dict:find(Key, Dict) of
                            {ok, Val} ->
                                Val;
                            error ->
                                undefined
                            end,
                    Value;
                _ ->
                    undefined
            end                   
    end       
    .

%% returns ok
removeAttribute(Arg, Key) ->
    H = Arg#arg.headers,
    C = H#headers.cookie,
    case yaws_api:find_cookie_val(?Y_SESSION_ID, C) of
        [] ->
            ok;
        Cookie ->
                case yaws_api:cookieval_to_opaque(Cookie) of
                    {ok, Dict} ->
                        Dict2 = dict:erase(Key, Dict),
                        yaws_api:replace_cookie_session(Cookie, Dict2),
                        ok;
                    _ ->
                        ok
                end
    end       
    .

%% Returns a list of keys in the dictionary associated
%% with the session id.  Returns an empty list if no
%% session exists or if the session has expired
getAttributeNames(Arg) ->
    H = Arg#arg.headers,
    C = H#headers.cookie,
    case yaws_api:find_cookie_val(?Y_SESSION_ID, C) of
        [] ->
            [];
        Cookie ->
                case yaws_api:cookieval_to_opaque(Cookie) of
                    {ok, Dict} ->
                        dict:fetch_keys(Dict);
                    _ ->
                        []
                end
    end.

%% Returns undefined if no session exists or if the
%% session has expired.
getSessionId(Arg) ->
    H = Arg#arg.headers,
    C = H#headers.cookie,
    case yaws_api:find_cookie_val(?Y_SESSION_ID, C) of
        [] ->
            undefined;
        Cookie ->
                case yaws_api:cookieval_to_opaque(Cookie) of
                    {ok, _} ->
                        Cookie;
                    _ ->
                        undefined
                end
    end.


%% Return ok in all cases
invalidate(Arg) ->
    H = Arg#arg.headers,
    C = H#headers.cookie,
    case yaws_api:find_cookie_val(?Y_SESSION_ID, C) of
        [] ->
            ok;
        Cookie ->
                yaws_api:delete_cookie_session(Cookie),
                ok
    end.



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Erlyaws-list mailing list
Erlyaws-list@...
https://lists.sourceforge.net/lists/listinfo/erlyaws-list

[Steve Vinoski-2]

On Tue, Oct 20, 2009 at 7:40 AM, David Hayek <dhayek@...> wrote:

Hello

By way of background, my current job involves programming J2EE applications.  But I discovered Erlang and Yaws a while back and have been working with them in my spare time ever since. 

One of the things I like about the J2EE servlet specification is its handling of sessions as a way of storing arbitrary data across user requests in a hash table.  I know Yaws has cookie-based sessions, but no formal way to set and get attributes for a user's session, so I created the session module below for a project I'm working on now.

Have you considered that encouraging session state goes against the tenets of the REST architectural style? Servlets were designed at a time when REST and its constraints, especially its statelessness constraint, were understood thoroughly by only a handful of people on the planet, but thankfully that knowledge has spread and the rest of us have collectively learned much since then about designing RESTful web applications. I'd be interested in hearing more about why you think you need stateful interactions of the session variety.

Have you read this: <http://oreilly.com/catalog/9780596529260>

--steve

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Erlyaws-list mailing list
Erlyaws-list@...
https://lists.sourceforge.net/lists/listinfo/erlyaws-list

[Praveen Ray-6]

IMO, distributed sessions in the servlet container world are more of a vanity. Most real world applications use database backed sessions anyway and in reality you can't let the servlet container manage distributed sessions - they simply don't scale very well. Plus, sessions are not really part of HTTP transport, so, I don't think it's wise to carry that code as part of core web server codebase. In any case, creating/managing sessions is pretty easy anyway. 

What would be more useful are two hooks in the yaws code which get called 

• early in the request phase - something like 'create_session' 
• and another at the very end of the request called 'cleanup_session'. 

Let the application install these hooks. Actual session handling is then delegated to the app, as it should.

-Praveen 

On Tue, Oct 20, 2009 at 7:40 AM, David Hayek <dhayek@...> wrote:

Hello

By way of background, my current job involves programming J2EE applications.  But I discovered Erlang and Yaws a while back and have been working with them in my spare time ever since. 

One of the things I like about the J2EE servlet specification is its handling of sessions as a way of storing arbitrary data across user requests in a hash table.  I know Yaws has cookie-based sessions, but no formal way to set and get attributes for a user's session, so I created the session module below for a project I'm working on now.

I'm not sure where to submit this, so I'm posting it to the mailing list.  I'm not sure if something like this would be useful to other developers.

What I would also like to do is create distributed sessions.  I don't believe that distributed sessions are part of the J2EE specification, but most (all?) implementations offer distributed sessions as a configurable parameter for reasons of failover and general "enterprisy-ness".  To store session data, the yaws_session_server module uses ETS tables, which I believe are not distributable (please correct me if I'm wrong).  But mnesia tables are distributable.  I'm still trying to think of a way to implement this which would be in keeping with the general structure of the Yaws code.  However, since I'm fairly new to Yaws and Erlang, I'm struggling a little bit.  My questions to the group about this are:

1.  Would distributed sessions be useful for Yaws applications?

2.  If so, what would be a good way to approach the problem?

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Erlyaws-list mailing list
Erlyaws-list@...
https://lists.sourceforge.net/lists/listinfo/erlyaws-list

[David Hayek]

Steve

Thanks for responding so quickly. 

One of my goals has been to find an alternative to J2EE, and Java in general, for web programming.  Part of the problem with the J2EE projects that I've seen is the sheer un-manageability of the code as the project grows.  And part of the blame for that can be laid at static type systems, as I've slowly come to understand,  and Java's tendency to verbosity, and over-reliance on various J2EE frameworks rather than good design.  As the difficulty of managing the code grows, there is a push to "abstract" a lot it into re-usable web services.  But from what I've been reading recently about WS vs REST, it looks like WS is far more trouble than it's worth, which was sort-of my sense about it, but it's nice to have that confirmed.  In fact, at one meeting devoted to developing my company's web services strategy that I attended a long time ago, one of the developers mentioned using a RESTful approach instead, but that got nowhere since most people didn't know what he was talking about.   I saved a copy of an interesting article you wrote about WS vs REST and I'm going to pass that around to the senior developers in our group and to my management.

I have banged my head up against REST for a couple of years now and I think I can safely say that I get the idea of REST without grokking it.  So my first reaction to your comments was, Well, who wouldn't want sessions?  Sessions are great!  And distributed sessions are even better!  But this speaks, perhaps, to the narrowed way of thinking that I have approached web development.  I'm not saying it's wrong or right, just narrow.

Here are a couple of scenarios that I came up with where I tried to think of a RESTful approach but eventually found myself stuck. 

The first has to do with expensive transactions that only have to be done once for a user's session, although the data itself may be used on several different pages.  The transactions might involve a lot of IO, a lot of communication overhead to back-end systems, or a lot of CPU usage.  The data is private, not publicly cacheable, and unique to that user.  An example would be saving product pricing data on a user's session, where the prices are actually calculated by a very complex process on a back-end system and are unique to that user.  But once the prices are calculated, they won't change during the time the user is browsing the site.  Using REST, I could specify this resource as something like:

/path/to/pricing/data/product_number/user_account_number

which is just like a specification for any static resource such as

/path/to/my/static/page.html

where the mime type for the first resource could be text (returning, say, "$100.00") and the second would be text/html.   REST doesn't make any distinction about the difficulty of retrieving any given resource or how it's likely to be used.  It does note that that scalability of RESTful applications is dramatically improved by caching, especially by user agents and intermediaries.  But in my example, the pricing data can not be cached in such a way since it is private and may change from day to day.

In a broader sense, then, when I talk about sessions I'm really talking about another way to cache data, albeit one that is not recommended for RESTful applications due to its scalability problems.  But server-side caching for database-driven applications is extremely useful for performance reasons - for example, memcached. 

Another example involves authentication.  In a B2B transaction using xml for a purchase request, the xml will contain fields with the necessary credentials for authentication.  Any subsequent transaction must also contain valid credentials.  This, to me, seems like a good example of REST.  Each request carries enough information for the server to decide what to with it.  But what about the situation where a user is continuously browsing a site after logging in? 

So for a RESTful approach, after a user has logged in, every link could be re-written to include the user's credentials, and every form could have extra, hidden fields with the user's credentials.  That could work, as long as the user stayed exclusively on the site and all of the pages they viewed were generated by a dynamic application server.  But if, for example, they left the site and came back to it, but not by using the back button on their browser, the user would have to  log in again. 

One solution I saw involved setting a cookie with a unique security token.  The server would generate this cookie and then store it.  Since cookies are transmitted with every request, the server could check the value of this cookie and see if had stored this value previously.  If so, then let the user have access to the resource.  If not, return an appropriate error code. 

But I see two difficulties with this.  The first is that the server still has to look up the value of the security token it stored to see if it exists and if it is valid.  Most likely, this value will be stored in a database.  Even if the database is fast, this lookup is a bottleneck, although one which can be mitigated with appropriate caching (again, memcached or something like it). 

And the second is that we would want the security token to expire after a certain amount of time after the user's last access on the server.  You could have a routine that runs either in javascript or on the server that sets a new expires value of the cookie every time the user requests a resource from the server.  But I think you would also have to have a routine on the server that updates a last-accessed time in the database table that holds the values of the tokens.  And then there's the problem of deleting stale tokens from the database, which may not be a big problem, but it does add complexity.

And even if you use server-based authentication, some of the same patterns apply.  The basic process in all of these cases goes something like:

1.   
Check for security credentials (security token, session id, or credentials sent in a http header).

2.
If no credentials exists, return an error, or redirect to a login page.

3.
If credentials exist, check their validity by performing some kind of lookup.

4.
If the credentials are not valid, return an error or redirect to a login page.

5.
If the credentials are valid, allow access to the resource.

I see the point about the scalability problems inherent in maintaining state on the server.  But I'm not sure how to address some of these things I have to deal with on a day-to-day basis.

In addition to your response, I got one from Praveen Ray.  He said:

"IMO, distributed sessions in the servlet container world are more of a vanity. Most real world applications use database backed sessions anyway and in reality you can't let the servlet container manage distributed sessions - they simply don't scale very well. Plus, sessions are not really part of HTTP transport, so, I don't think it's wise to carry that code as part of core web server codebase. In any case, creating/managing sessions is pretty easy anyway. 

What would be more useful are two hooks in the yaws code which get called 

• early in the request phase - something like 'create_session' 
• and another at the very end of the request called 'cleanup_session'. 

Let the application install these hooks. Actual session handling is then delegated to the app, as it should."

I like his idea of using hooks in the yaws code to handle sessions.  I think some kind of gen_server module could handle this pretty well.  And it could be simply a matter of adding a configuration parameter in yaws.conf to instantiate it. 

However, I'm not sure about his suggestion of delegating session management to the application.  Again, here's my J2EE/EJB background coming out.  I have been led to believe that container-managed persistence and container-managed sessions are the way to approach scalability problems, rather than having each application take care of it on its own.  And I know that the J2EE spec came out about 10 years ago, but I think the problems of client-server interaction it tried to address are still valid.  The problem with EJBs, though, is that it takes 4 to 5 classes just to define and implement a single one of them, along with the usual xml descriptor files.  I mean, wherever I look, there's another xml file.  Plus, I've seen the the additional problem of vendors adding proprietary extensions to EJBs to deal with their limitations, but thereby removing their portability. 

Now, I think Java does a fine job when it comes to serialization, threading, and rmi, as compared to its predecessors.  But Erlang/OTP, it seems, is in a class by itself when it comes to these things.  And ironically enough, it might make a better EJB container than most actual EJB containers.  If I could argue by analogy, Mnesia seems an awful lot like an EJB container.  It can handle a distributed schema (entity beans), and it can handle table replication on an arbitrary number of nodes for ram_copies tables (session beans).  What it doesn't do is automatically remove stale sessions.  But I think that a gen_server process that's hooked into Yaws could handle that part of it.

None of what I've said means that I'm closed to changing my views about web development - I certainly have a lot to learn.   I'm going to take a look at the book you recommended in order to get a better idea of REST.  But I think I'm also going to look into the Yaws source code a little more deeply to see if there's any promise to implementing those hooks into the Yaws server.

David
 


Steve Vinoski wrote:

On Tue, Oct 20, 2009 at 7:40 AM, David Hayek <dhayek@...> wrote:

Hello

By way of background, my current job involves programming J2EE applications.  But I discovered Erlang and Yaws a while back and have been working with them in my spare time ever since. 

One of the things I like about the J2EE servlet specification is its handling of sessions as a way of storing arbitrary data across user requests in a hash table.  I know Yaws has cookie-based sessions, but no formal way to set and get attributes for a user's session, so I created the session module below for a project I'm working on now.

Have you considered that encouraging session state goes against the tenets of the REST architectural style? Servlets were designed at a time when REST and its constraints, especially its statelessness constraint, were understood thoroughly by only a handful of people on the planet, but thankfully that knowledge has spread and the rest of us have collectively learned much since then about designing RESTful web applications. I'd be interested in hearing more about why you think you need stateful interactions of the session variety.

Have you read this: <http://oreilly.com/catalog/9780596529260>

--steve

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Erlyaws-list mailing list
Erlyaws-list@...
https://lists.sourceforge.net/lists/listinfo/erlyaws-list

[Praveen Ray-6]

I think most of the issues arise because people have been trained to think of sessions as something special. Session is just another piece of data in your database. Read it when you need. Write it once you're done. It's just another table and another POJO entity.
In functional world, you might write few functions to make it easy to extract from cookie,read and write the session.
That's pretty much it.
Redirecting to a login page for missing sessions is just another facet of your application. It might be an oft repeated pattern but still has nothing to do with web server and the container. Just abstract it away in an erlang module and reuse the module in all your apps.
Let's KISS !

On Sat, Oct 24, 2009 at 11:59 AM, David Hayek <dhayek@...> wrote:

Steve

Thanks for responding so quickly. 

One of my goals has been to find an alternative to J2EE, and Java in general, for web programming.  Part of the problem with the J2EE projects that I've seen is the sheer un-manageability of the code as the project grows.  And part of the blame for that can be laid at static type systems, as I've slowly come to understand,  and Java's tendency to verbosity, and over-reliance on various J2EE frameworks rather than good design.  As the difficulty of managing the code grows, there is a push to "abstract" a lot it into re-usable web services.  But from what I've been reading recently about WS vs REST, it looks like WS is far more trouble than it's worth, which was sort-of my sense about it, but it's nice to have that confirmed.  In fact, at one meeting devoted to developing my company's web services strategy that I attended a long time ago, one of the developers mentioned using a RESTful approach instead, but that got nowhere since most people didn't know what he was talking about.   I saved a copy of an interesting article you wrote about WS vs REST and I'm going to pass that around to the senior developers in our group and to my management.

I have banged my head up against REST for a couple of years now and I think I can safely say that I get the idea of REST without grokking it.  So my first reaction to your comments was, Well, who wouldn't want sessions?  Sessions are great!  And distributed sessions are even better!  But this speaks, perhaps, to the narrowed way of thinking that I have approached web development.  I'm not saying it's wrong or right, just narrow.

Here are a couple of scenarios that I came up with where I tried to think of a RESTful approach but eventually found myself stuck. 

The first has to do with expensive transactions that only have to be done once for a user's session, although the data itself may be used on several different pages.  The transactions might involve a lot of IO, a lot of communication overhead to back-end systems, or a lot of CPU usage.  The data is private, not publicly cacheable, and unique to that user.  An example would be saving product pricing data on a user's session, where the prices are actually calculated by a very complex process on a back-end system and are unique to that user.  But once the prices are calculated, they won't change during the time the user is browsing the site.  Using REST, I could specify this resource as something like:

/path/to/pricing/data/product_number/user_account_number

which is just like a specification for any static resource such as

/path/to/my/static/page.html

where the mime type for the first resource could be text (returning, say, "$100.00") and the second would be text/html.   REST doesn't make any distinction about the difficulty of retrieving any given resource or how it's likely to be used.  It does note that that scalability of RESTful applications is dramatically improved by caching, especially by user agents and intermediaries.  But in my example, the pricing data can not be cached in such a way since it is private and may change from day to day.

In a broader sense, then, when I talk about sessions I'm really talking about another way to cache data, albeit one that is not recommended for RESTful applications due to its scalability problems.  But server-side caching for database-driven applications is extremely useful for performance reasons - for example, memcached. 

Another example involves authentication.  In a B2B transaction using xml for a purchase request, the xml will contain fields with the necessary credentials for authentication.  Any subsequent transaction must also contain valid credentials.  This, to me, seems like a good example of REST.  Each request carries enough information for the server to decide what to with it.  But what about the situation where a user is continuously browsing a site after logging in? 

So for a RESTful approach, after a user has logged in, every link could be re-written to include the user's credentials, and every form could have extra, hidden fields with the user's credentials.  That could work, as long as the user stayed exclusively on the site and all of the pages they viewed were generated by a dynamic application server.  But if, for example, they left the site and came back to it, but not by using the back button on their browser, the user would have to  log in again. 

One solution I saw involved setting a cookie with a unique security token.  The server would generate this cookie and then store it.  Since cookies are transmitted with every request, the server could check the value of this cookie and see if had stored this value previously.  If so, then let the user have access to the resource.  If not, return an appropriate error code. 

But I see two difficulties with this.  The first is that the server still has to look up the value of the security token it stored to see if it exists and if it is valid.  Most likely, this value will be stored in a database.  Even if the database is fast, this lookup is a bottleneck, although one which can be mitigated with appropriate caching (again, memcached or something like it). 

And the second is that we would want the security token to expire after a certain amount of time after the user's last access on the server.  You could have a routine that runs either in javascript or on the server that sets a new expires value of the cookie every time the user requests a resource from the server.  But I think you would also have to have a routine on the server that updates a last-accessed time in the database table that holds the values of the tokens.  And then there's the problem of deleting stale tokens from the database, which may not be a big problem, but it does add complexity.

And even if you use server-based authentication, some of the same patterns apply.  The basic process in all of these cases goes something like:

1.   
Check for security credentials (security token, session id, or credentials sent in a http header).

2.
If no credentials exists, return an error, or redirect to a login page.

3.
If credentials exist, check their validity by performing some kind of lookup.

4.
If the credentials are not valid, return an error or redirect to a login page.

5.
If the credentials are valid, allow access to the resource.

I see the point about the scalability problems inherent in maintaining state on the server.  But I'm not sure how to address some of these things I have to deal with on a day-to-day basis.

In addition to your response, I got one from Praveen Ray.  He said:

"IMO, distributed sessions in the servlet container world are more of a vanity. Most real world applications use database backed sessions anyway and in reality you can't let the servlet container manage distributed sessions - they simply don't scale very well. Plus, sessions are not really part of HTTP transport, so, I don't think it's wise to carry that code as part of core web server codebase. In any case, creating/managing sessions is pretty easy anyway. 

What would be more useful are two hooks in the yaws code which get called 

• early in the request phase - something like 'create_session' 
• and another at the very end of the request called 'cleanup_session'. 

Let the application install these hooks. Actual session handling is then delegated to the app, as it should."

I like his idea of using hooks in the yaws code to handle sessions.  I think some kind of gen_server module could handle this pretty well.  And it could be simply a matter of adding a configuration parameter in yaws.conf to instantiate it. 

However, I'm not sure about his suggestion of delegating session management to the application.  Again, here's my J2EE/EJB background coming out.  I have been led to believe that container-managed persistence and container-managed sessions are the way to approach scalability problems, rather than having each application take care of it on its own.  And I know that the J2EE spec came out about 10 years ago, but I think the problems of client-server interaction it tried to address are still valid.  The problem with EJBs, though, is that it takes 4 to 5 classes just to define and implement a single one of them, along with the usual xml descriptor files.  I mean, wherever I look, there's another xml file.  Plus, I've seen the the additional problem of vendors adding proprietary extensions to EJBs to deal with their limitations, but thereby removing their portability. 

Now, I think Java does a fine job when it comes to serialization, threading, and rmi, as compared to its predecessors.  But Erlang/OTP, it seems, is in a class by itself when it comes to these things.  And ironically enough, it might make a better EJB container than most actual EJB containers.  If I could argue by analogy, Mnesia seems an awful lot like an EJB container.  It can handle a distributed schema (entity beans), and it can handle table replication on an arbitrary number of nodes for ram_copies tables (session beans).  What it doesn't do is automatically remove stale sessions.  But I think that a gen_server process that's hooked into Yaws could handle that part of it.

None of what I've said means that I'm closed to changing my views about web development - I certainly have a lot to learn.   I'm going to take a look at the book you recommended in order to get a better idea of REST.  But I think I'm also going to look into the Yaws source code a little more deeply to see if there's any promise to implementing those hooks into the Yaws server.

David

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Erlyaws-list mailing list
Erlyaws-list@...
https://lists.sourceforge.net/lists/listinfo/erlyaws-list