• Introduction
• Documentation
• Download
• Development
• History

Ideal Web Application Server

Go look at WebObjects - it has the best web application architecture yet designed. Its OO rather than all the page swishing things I'm seeing and it models UI elements not tags (although you have acess to those too). Clone that design in Smalltalk and we'll have a winner. I'm rather amazed that the Smalltalk community seems to be ignorant of this architecture and its constituent patterns. -Todd Blanchard tblanchard@mac.com

I can offer some kind of support for Todd's view (from what I can see, maybe AIDA has been modeled on WebObjects, but I can't download it to look at it). I think it is a mistake for Smalltalkers to look at JSP etc. The J2EE world is thrashing about trying to find a good framework for web applications. They've come up with taglibs, and Struts, but this is still a mish-mash compared to WebObjects. And there is the GnuStepWeb stuff that is written in Objective-C. I suspect Smalltalkers would be able to see what is going on in that in a very short period (http://www.gnustepweb.org/). The other great technology (albeit with Java roots, is the Enhydra Application Framework - it does something similar to WebObjects (http://www.enhydra.org). The bottom line is surely to separate presentation from logic - the J2EE world is going round trumpeting the need for MVC! - Bernard Devlin bernard.devlin@lobstersoftware.com

It should be possible for an application server to connect to a web server in Smalltalk or to a standard one like Apache. Wave does this.

An application server takes a Request and figures out how to respond to it. It will have a set of RequestHandlers corresponding to the various applications. The server has to decode the URL and figure out which Handler should handle the Request. Wave and AIDA have a table that maps URLs to Handlers.

WikiWorks uses a tree of composites. I like the way WikiWorks does it better, but that is probably mostly because I did it. The tree of composites is just a CompositeRequestHandler, and you can easily embed one CompositeRequestHandler in another. Thus, a Wiki is just another CompositeHandler. What are the advantages of looking up URLs with a table?

Wave and WikiWorks both have the notion of a Response. Basically, a Handler takes a Request and produces a Response. AIDA has a different idea that I think is better, and Hydrogen provides something similar. AIDA has a WebComponent hierarchy. A WebComponent knows how to product HTML for itself.

All subclasses of WebComponent have a method like HTMLon:. You can build up a tree of them. Typically a WebComponent acts like a view, and a different object acts like a model. When the WebComponent prints itself out as HTML, it displays the current value of the model. AIDA comes with a library of WebComponents for things like news and lists. The great thing about these components are that they are so composable.

Hydrogen has something similar. In other words, it has objects that can print themselves out as HTML. However, its objects are much lower level. They are modeling HTML directly, while AIDA's model the user view of a web page. Hydrogen's let you display the objects in several ways; the Hydrogen objects are rendered with a visitor. I prefer the more application-oriented view of AIDA, but in fact there is no reason to make a choice. You can use both high-level and low-level objects together as long as they all can produce HTML.

A WebComponent is similar to a Response. One difference is that a Response has a status number. I would prefer to give all WebComponents a default status number and then have a decorator that can generate a different message. Perhaps ErrorComponent could have a status number and could also take a WebComponent with its message. Then any WebComponent could be used as a Response.

Wave says that a Response is a Handler. A Response handles a message by returning itself. This is neat, because you can make a Handler that always returns the same message by plugging in its Response. If a WebComponent is a Response, then any WebComponent could be used as a Handler.

A web application server needs an HTML template system like ASP and JSP. I like to call it "Active Smalltalk Pages". When one of these things gets compiled, it becomes an object that can be used to create WebComponents. A Handler for an Active Smalltalk Page will take a request, run the code corresponding to the page, and produce HTML. Since it is producing a WebComponent, the Smalltalk code inside the page will mostly just produce WebComponents, which get combined into a single composite WebComponent.

Comment: I think that something like Active Smalltalk Pages is the most generally useful of the possible approaches (not that it's right for all circumstances, but I'd use it as a default). This could be modelled with these WebComponents, but I think they'd be very, very simple ones. Essentially, you read the file once and parse it to find out where the code fragments are, and you remember that information. Then you have two kinds of WebComponents: long literal strings of partial HTML and code fragments. The strings just print themselves, and the code fragments just evaluate themselves in the current context. Alan Knight

Comment: Some time ago (8 months or so), I built SSP (Squeak Server Pages) for Squeak, which I think is exactly what you are looking for. You can manipulate straight HTML with standard "server page" tags that have Smalltalk code embedded in them. This is all done in the class browser with special compiler pragmas to indicate the special SSP syntax. We have used it heavily for www.swiki.net and www.netunify.com for quite some time. It's all based on a special parser and it strings together statements that append to a stream...which makes it very fast when compared with the alternative of some kind of search and replace scheme. (see ssp-squeak.swiki.net) -Stephen Pair.

One of the things that AIDA provides is database support and session support. Sessions are stored in the database. When a Request is decoded, it can be associated with a session. This means that a application server is stateless. State is stored in the DBMS between requests, so if you had several servers, each request in a session could go to a different server and everything would work normally.

Ralph Johnson

In my opinion (and based on our needs of course) the ideal web app server should have at least those features:

• standalone http server or connected to standard server like Apache
• session support with or without cookies
• security (authentication, access control, SSL, certificates)
• scalability (cluster, load balancing, failover)
• business logic separated from HTML presentation
• able to call external modules, servlets etc
• able to parse special tags in HTML (Active Smalltalk Pages)
• to be easy connected to design tools like Macromedia Dreamweaver
• persistent anything architecture

One non-Smalltalk product to take a good look at is Zope (http://zope.org). It has an awful lot of good ideas, like versioning, ttw content management, everything in an object database, but lacks Smalltalk.

Cees de Groot

Some Issues about the syntax and semantics of Smalltalk server pages.

1. The tags used to indicate Smalltalk code in a Web page.

The tags need to be compatible with html editors used to generate web pages. PHP uses <? ?>, <?php ?> and <script language="php"> </script> all of which do the same thing. JSP uses <%! %>, <%= %>, <% %>, <%@ %>, <jsp:XXX > which all do different things. Different tags are used for comments, code which does not place text in the page, code which does place text in the page, code that includes other files in the current one, code that defines page wide properties. JSP seems overly complex, but does provide a list of functionality to consider.

I see the need for tags that place text in the html page and tags that do not. How should this be indicated? PHP requires the code to use echo place text in the html page. JSP uses different tags to indicate the difference.

2. Syntax and semantics of the code in a tag.

I currently use block semantics for the code in a tag. All variables must be defined first. The code is evaluated and if there are no explicit returns, the result of the last expression is used as the value of the tag. If the value of the tag is nil, nothing is placed in the html page. If the value is not nil, it is converted to a string and placed in the html page. So

<%	 | x  | 
	x := 5.
	Date today %>

would result in the current date being displayed in the html page.

3. Page variables.

I see the need for defining variables that can be accessed in all the Smalltalk code tags in the html page. In particular I like the PHP idea of providing direct access to form variables directly in the code tags. For example if a form is sent to the server with a text field named foo, then in a code tag I can use foo as a variable to get the text in the text field. However, I require all variables to be declared. So there is a special tag used to define all page variables. Currently this looks like:

<%vars | foo bar |
	bar := 5. %>

All form variables and other page variables are defined in this block. Code can appear in the tag, but does not result in any text being placed in the html page.

The tags need access to the http headers, but it is not clear if they need to be direct variables or can be stored in a dictionary.

4. Avaiable Services

As others have pointed out there is a list of srevices that are needed by teh code in the tags.

I would love to hear from anyone that has ideas about this.

By the way I see that VW5i4 is going to have Smalltalk server pages. Does anyone know any details? When can I start developing Web pages?

Roger Whitney

1. Tags. Both ASP and JSP use the basic tags <&vars;= &vars;> for code whose result is inserted in the page and <% %> for code that does. And they use <&vars;@ &vars;> for directives that modify the way code or the page is interpreted without actually being code, but those are much rarer. Those seem pretty reasonable. <jsp:XXX> are alternative, more XML-ish syntax for the same things. <&vars;! &vars;> I wouldn't care too much about because it's closely tied to the implementation of a JSP as a Java servlet, and generally not recommended, even in Java. (Note: JSP also supports all of the servlet mechanisms, including direct access to the output stream).

2. Block semantics are appealing, but only really work when displaying the result. In particular, if using <&vars; (i.e. not displaying the result) it is possible to have statements that span multiple chunks of code. e.g.

  <&vars; something ifTrue: &vars; ifFalse: &vars;.&vars;>

One could make the argument that this is really stupid and we shouldn't support it, but it is legal and not uncommon in templating frameworks (ASP/JSP/PHP), so if you're going to implement something directly compatible with ASP/JSP you have to support this. Note that this essentially means that the only possible way to extract the code portions is to make the entire HTML page a method, leave the code alone, and turn the HTML into #nextPutAll: operations.

3. Page variables. We went in the other direction, deciding that declaring the variables in the page just got in the way too much, particularly given the previous translation mechanism. The special tag would have worked, but we chose to allow variables to be implicitly defined (which really just means that at translation time we insert declarations for undeclared variables. Access to header variables (both incoming and outgoing) are provided through Request and Response objects. The ability to automatically make headers visible as variables is interesting, but I think you're better off to use something like servlets for form processing anyway.

4. Services. There's a bunch. Clearly you need to be able to access any of the incoming information and set any of the outgoing: headers, cookies, redirect information and obviously text. Access to session state is good, and being able to forward requests. There's probably more, but I can't think of it right now.

One of the things that rapidly becomes obvious with a technology like this is that putting large amounts of code into the pages makes it very difficult to do any work. I think some of the most important supplementary services are going to be mechanisms for letting the pages stay as close to pure HTML as possible and delegating logic into the image where it belongs and is maintainable.

By the way I see that VW5i4 is going to have Smalltalk server pages. Does anyone know any details? When can I start developing Web pages?

I know lots of details <grin>. Essentially we are implementing as a basis the ASP/JSP/servlet specifications, following them as closely as is reasonable in a Smalltalk environment. This is targeted for the summer Cincom Smalltalk release (i.e. if all goes well we'll ship at the beginning of August, if not it'll slip a bit). There will be early access before that, dates not yet determined. If you're interested, talk to Jim Robertson.

-- Alan Knight

Comments on Alans Comments

2. Block semantics are appealing, but only really work when displaying the result.

Not clear why block semantics only work when displaying the result. In <&vars; tags any returned results are not displayed.

It makes all of the statements completely self-contained. Not only can you not have statements that span multiple chunks of html, you can't do things like assign to a variable in one chunk and reference it in another.

I agree that having statements that span multiple chunks of code is "really stupid". I don't see the need to support it just because ASP/JSP do. The advantage of being late is to selecting the good features of the existing systems. The differences between Java/ASP from Smalltalk means Java/ASP are going to be a bit slow in moving from JSP/ASP to Smalltalk server pages. Smalltalkers are already used to different ways of doing things.

Well, I'm trying to generate significant numbers of new Smalltalkers, so doing things the way the rest of the world does is an advantage there. There's a fairly broad feature set there, and no one is obliged to use all of them.

I don't know that people will necessarily be slow. In fact, if people use JSP custom tags exclusively, we should be able to run existing JSPs directly with no modifications

Please save the world from servlets. I have stopped using them. Most of the people on campus using them have lots of problems. They think long and difficult debug sessions are normal. I am tired of answering their questions about servlets. Much of the problem is Java and its edit, compile, run cycles and the how it interacts with webservers.

What would you prefer? How would you feel about servlets that didn't have Java and its problems? Servlets themselves seem pretty harmless to me, it's a very minimal API. The devil is in making things usable, which we've put a lot of work into

Implicit variable declarations add to debug problems, which is one reason I do not use Zope. I hope that the 5i4 stuff will prove me wrong.

Yes, they can. I just found it too troublesome to have to declare them. It would be better if Smalltalk allowed variable declarations in the middle of a method, but that would have been much harder to implement. I can let that be turned off very easily

Roger Whitney Alan Knight