SmartWorker, a New Web Application Server
Search Our Site
For news and reviews of the latest computer audio tools, visit:
|
|
|
|
A New Web Application Server
SmartWorker
SmartWorker is a new Web app server based on modperl. The brainchild of Hard Boiled Egg Software, it is now an open source project. There are several unique things about it, so if you're into Web application development, it's worth checking out. Here's some information adapted from their site at http://www.smartworker.org/.
September 14, 1999
Overview
SmartWorker is a platform for web application development. The core
technology in Smartworker is contained in a set of application framework
classes (written in Perl). The system uses any SQL database (via DBI)
for backend data storage, and a web server (Apache + mod_perl) for
front-end client access.
Web App vs. Web Site
The purpose of SW is not to provide another means of generating HTML
pages on-the-fly from databases. There are plenty of ways to do this
already. SW applications are not Web sites, but true applications that
happen to be served over the Web. In fact, it is possible (when the
renderers are written!) to access SW apps via non-Web interfaces, such
as handheld devices and PCS phones.
Why is SmartWorker different?
SmartWorker is different from other web-based application
development/deployment platforms because it is based on an
event-driven, persistent, application framework model like GTK, JFC, MFC
etc. etc. instead of a transaction-based model such as Cold Fusion,
LiveWire, ASP or CGI.
This model is revolutionary because it entirely abstracts the workings of
the web from the app developer, and it is a familiar development model
to most app programmers who have used MFC, KDE or the like.
We've also make an effort to model the technology as a complete class
structure that happens to use Apache and the web to reach end users.
This is a different approach than other technologies which are built on
the back of Apache, and built the way they are because of the web.
The SmartWorker model also frees developers from dealing with the ugly
details of different browser implementations by providing a platform
independent set of GUI widgets which are drawn by platform dependent
renderers. This means that applications are portable and can even be
displayed on future handheld devices and alternative GUIs as new
renderers are written to support them.
What does it offer?
SmartWorker apps get a lot for free. Users and groups are automatically
built into the system, so when an app runs, it executes with the
permissions of the user who is running it, just like an app under Unix or
NT. Moreover, the framework handles persistence and session
management, so that, too, is transparent (generally) to the developer.
The database backend, data storage and retrieval, user authentication
and so on are handled by SmartWorker framework classes, and the
developer doesn't need to spend a lot of time on the details (ie. NO SQL
will be written by the developer).
Finally, the applications are not built with HTML interfaces, they are
built
with widgets and objects, just like in normal GUI application frameworks.
This removes much of the pain from web-app development: how to
combine HTML and executable code together in a structured way. We
solve this by *never* combining HTML and code, and instead
programmatically generating the interface to our apps using the
framework classes. This is a totally different approach then the Cold
Fusion way of doing things (embedding code in HTML templates). You
could say (if you don't mind the Microsoft reference) that SmartWorker is
closer to the Visual Basic way of doing things (less interface flexibility,
but more intuitive app development environment) than traditional Web
page generating technologies.
Groovy Features?
Yes, there are groovy features! The app rendering architecture
detects which browser the user is viewing the app with, and it adapts
accordingly. So, if a user is viewing an app using IE 5.0, the framework
will build the app's interface in DHTML code that will work under IE5.0. If
it is being viewed using Lynx, the interface willbe sent in text-only
format
that Lynx can view. All of this is also transparent to the application
programmer, because the programmer doesn't write out HTML, but builds
the interface using objects. The more renderers we have, the more
portable SmartWorker is.
Another great and groovy feature is the fact that SmartWorker
anticipates multi-lingualism from the ground up. Every application can
be run in different languages without requiring huge code-rewrites. This
is accomplished through the use of string tables, one for each language
that an app supports. As an example of how easy this is, we converted a
full-featured contact management application from English to Chinese in
about 10 minutes (learning Chinese was not part of the 10 minutes).
Doesn't all this mean extra work?
No. Very functional apps can be built with a minimum of code (see the
sample apps page), yet these apps will render themselves properly under
many different browsers on many different platforms. It's still a
client-server protocol, but this tends to be abstracted so much that app
programmers generally won't notice.
So what can SmartWorker be used for?
SmartWorker can be used to build powerful Web applications quickly and
in a way that makes it easy to modify and extend the feature set
through high-level object-oriented programming instead of writing lots of
HTML templates. SmartWorker is trying to be device independent so
ultimately we hope it is more than just for Web browsers. While it is Web
hosted, this doesn't mean that the client can't be WebTV, a PalmPilot, or
your PCS phone.
We also hope that SmartWorker will catch on in the international
community. Because we're building objects and not pages, it is easier to
translate apps via string tables and abstracting language selection at the
user level. This will hopefully make it easier to write apps where people
speaking different languages can collaborate on the same application.
This applies both to the language of the user interface and eventually to
built-in instant translation facilities.
|
|
|