Index of /Perl/JAAS
Name Last modified Size Description
Parent Directory 09-Jul-2013 11:27 -
README.txt 27-May-2002 02:27 3k
old/ 18-Feb-2003 23:50 -
JAAS-Config-0.03.tar.gz 19-Feb-2003 00:29 12k
JAAS-Log-0.03.tar.gz 19-Feb-2003 00:29 17k
JAAS-Object-0.03.tar.gz 19-Feb-2003 00:29 21k
JAAS-Object-Context-0.03.tar.gz 19-Feb-2003 00:29 16k
JAAS-Object-Lifetime-0.03.tar.gz 19-Feb-2003 00:29 7k
JAAS-Server-0.03.tar.gz 19-Feb-2003 00:29 26k
JAAS-Widget-0.03.tar.gz 19-Feb-2003 00:29 21k
pretty-pictures/ 19-Feb-2003 00:47 -
JAAS is Just Another Application Server.
JAAS is my attempt at a general application server architecture. I might
have failed at being general, because I work with the web and this has
scewed my thinking.
Each server listens on one or more ports or unix sockets using POE::Co::IKC.
Each server has one or more applications within it. Each application has
one or more entrypoints. The entrypoints tie a IKC request to a bunch of
JAAS objects. The entrypoint askes the objects a context (which is badly
named and needs work). The context looks for existing objects (IE in a
state database) and if that fails, asks a factory to create them. The
factory knows how to create the objects via a config object (config file).
Multipart entry points implement a forced-march, or "wizard" style of
interface. IE : one walks through many steps, all coming through one call.
The steps are implemented on the server side, rather then the client's side.
Objects are Perl objects, with a POE session "above" them to deal with
incoming POE requests. The Objects are JAAS::Object::Delegates (actually,
this naming is the wrong way around. Objects should be JAAS::Object, the
session should be JAAS::Object::Helper or something). Objects access
POE features via JAAS::Services.
Objects are supposed to be loosely coupled, in that they access each other
via JAAS::Services, hence via IKC if needed. This allows one to place
various objects in different processes.
Objects are introspective. Currently this is limited to JAAS::Services
calling a method that returns all the methods the object exposes via JAAS
along with argument signatures.
Error handling, exceptions and logging is handled by JAAS::Error and stuff
The context saves the objects via a lifetime object. The lifetime object
can also be used for creating snap-shots or logs of the state of objects at
other times in their lifetime. This could be used for waypoints,
transactions, logging and so on.
JAECA has 2 kinds of JAAS objects come in 2 flavours : application objects,
which model "physical objects" and business objects, which model business
In general, the response to a request is either a POE structure, or a bunch
of widgets. The widgets are turned into physical widgets by the client
(HTML for a web browser, X widgets or so on).
The config that the factory uses is updatable at runtime. However, if you
have a forking server, the config doesn't automatically sync with all
copies. This needs to be resolved.
Also, at some point in the future i'm going to write a cool app that will
allow you to easily modify the config at runtime, as well as sending
messages to other objects (like stem has).
Further more, I want JAAS::Server to accept XML-RPC requests and respond in
Currently, because all objects for an entrypoint live in the IKC namespace,
a server can only process one request at a time. I have a cunning plan to
fix this though.