Index of /Perl/JAAS

      Name                             Last modified       Size  Description


[DIR] Parent Directory                 09-Jul-2013 11:27      -  
[GZ] JAAS-Config-0.03.tar.gz          19-Feb-2003 00:29    12k  
[GZ] JAAS-Log-0.03.tar.gz             19-Feb-2003 00:29    17k  
[GZ] JAAS-Object-0.03.tar.gz          19-Feb-2003 00:29    21k  
[GZ] JAAS-Object-Context-0.03.tar.gz  19-Feb-2003 00:29    16k  
[GZ] JAAS-Object-Lifetime-0.03.tar.gz 19-Feb-2003 00:29     7k  
[GZ] JAAS-Server-0.03.tar.gz          19-Feb-2003 00:29    26k  
[GZ] JAAS-Widget-0.03.tar.gz          19-Feb-2003 00:29    21k  
[TEXT] README.txt                       27-May-2002 02:27     3k  
[DIR] old/                             18-Feb-2003 23:50      -  
[DIR] 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
like that.  

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
logic.

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
kind.

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.