[Subversion] / PEAK / README.txt  

Diff of /PEAK/README.txt

Parent Directory | Revision Log

version 1633, Sun Jan 25 02:32:15 2004 UTC version 1636, Sun Jan 25 02:44:19 2004 UTC
Line 20 
Line 20 
     no storage at all.  Whatever the application type, PEAK can help you put      no storage at all.  Whatever the application type, PEAK can help you put
     it together.      it together.
  Package Features   Package Features
      Far too many to list even briefly here: see FEATURES.txt for a very high
     As of version 0.5a3, PEAK features include:     level overview.
     * A component binding framework that makes it easy to parameterize  
       components and thus more easily combine and "wire" them together.  
       Interfaces, adaptation, and "assembly events" (notification when  
       components have been engaged as part of a "complete" application)  
       are all available.  
     * A comprehensive configuration framework that allows accessing  
       "utilities" and "configuration properties" in context.  Properties  
       and utilities can be loaded or computed on demand, supplied by rules,  
       defined in configuration files or code, in a supplied or custom  
       format.  Properties and utilities are contextual and can be safely  
       acquired from parent/context components automatically.  
     * A "document-driven testing" framework similar to "FIT":http://fit.c2.com/  
       that lets you automatically extract test data from design and requirements  
       documents created with popular word processors, then create HTML reports  
       on what passed or failed.  
     * Naming system/framework that's midway between J2EE's JNDI and CORBA's  
       cosNaming in features, but much easier to use and extend than either  
       of those systems.  
     * A storage management and persistence system, including:  
         - Atomic, multi-database transactions with two-phase commit.  
         - "Data Manager" class framework for persistence management, that  
           allows you to separate business logic from storage implementation.  
           If you can write a few simple methods like "load" and "save" for  
           a given object type and storage approach, you can create your own  
           "DM" components.  You can think of a DM as an advanced form of  
           Python "shelve", that supports references to other objects,  
           transactions, arbitrary back-end storages, and caching.  
         - "Stackable" data managers: one DM might serialize a set of objects  
           to XML, which could then be stored in a database record by another  
           DM, and then the database record might be implemented via a DM  
           that writes to disk files!  Each DM only needs to know how to  
           manipulate objects offered by the next-level DM, not the details  
           of the next DM's implementation, so all the DM's are potentially  
           replaceable with alternate storage mechanisms.  
         - RDBMS and LDAP connection framework based on the Python DBAPI,  
           that handles data type conversions (via the configuration  
           framework) and seamlessly integrates with the transaction system  
           and naming services framework.  DB Connections can be accessed  
           by name or URL, and bound as default collaborators or utilities  
           for access by other application components.  
     * CASE/modelling tools: PEAK includes APIs to read object  
       models created in the XML-based XMI format.  Many open-source and  
       commercial modelling tools support XMI, inlcuding Argo/Poseidon and  
       MagicDraw UML.  PEAK includes pre-built support for UML versions 1.3  
       and 1.4, and MOF 1.3.1, using XMI versions 1.0 and 1.1. (UML 1.5,  
       CWM 1.0, CWM 1.1, and XMI 1.2-2.0 are anticipated for version 0.6.)  
       Also included is a MOF->Python code generator, which was used to generate  
       the UML support, and which you can use to generate support for other  
       modelling languages based on the MOF.  
       For the specifications of XMI, MOF, CWM, and UML, visit:  
     * A domain modelling framework for creating "business object models"  
       with unidirectional and bidirectional associations, generated  
       getters/setters and validators for fields, etc., and all necessary  
       persistence support for use with the PEAK storage framework.  Domain  
       types can also define string parsing and formatting syntax, so you can  
       create domain-specific data languages or just string formats for data  
       types (such as specialized date/time or currency types).  
       The business object framework supplies structural metadata about  
       classes built with it, so you can query a class for its fields and  
       links, and their names, types, etc.  This can be useful for  
       implementing model-driven storage or user interfaces.  And the  
       metadata is aligned with the MOF, so generating MOF, UML, or CWM  
       from PEAK models (and vice versa) is possible (although  
       not yet implemented for anything but MOF->PEAK).  
Line 121 
Line 35 
     * Application Runtime tools, including:  
       - a "command objects" framework for creating command-line applications,  
         including the ability to create "executable configuration files"  
         or "configuration interpreters" that can load a configuration file  
         and run an application instance constructed using the configuration  
         data.  Supported formats include an .ini-like PEAK format, and  
         arbitrary schemas defined using ZConfig.  
       - a "periodic tasks" framework for executing tasks that perform "as  
         needed", scheduling themselves in response to their available workloads  
       - a CGI/FastCGI publishing framework that uses 'zope.publisher' to  
         publish a PEAK component tree and its associated transaction service  
       - An "event-driven" programming framework that supports ultralight  
         "microthreads" implemented via generators, and interacts with Twisted  
         or stands alone.  
       - an event-driven "reactor" framework that seamlessly integrates with  
         Twisted, but can also be used without Twisted for applications that are  
         mostly scheduling-oriented, or which use only third-party protocol  
         implementations such as FAM, FastCGI, ReadyExec, etc.  
       - a robust and flexible logging framework that can integrate with the  
         PEP 282 logging module, or stand alone.  It's simpler than the PEP 282  
         system for simple log configuration, and is configured on demand  
         rather than "up front", and is thus more manageably configurable for  
         large or complex applications consisting of components from diverse  
       - a "process supervisor" framework for multiprocess servers using  
         long-running child processes (created via 'fork()') to take maximum  
         advantage of multiprocessor machines for CPU-intensive services.  
     * AOP and SOP: PEAK allows you to separate concerns as modules, then  
       combine the modules via a "module inheritance" technique.  This  
       lets you define a generated business object model as a  
       "structural" concern, and then combine it with a "behavioral"  
       concern.  This is as simple as writing classes that contain only  
       what you want to add, and then telling PEAK that your new module  
       "inherits" from the generated module.  This is similar to (but  
       designed independently from) the "MixJuice" tool for AOP in Java.  
  Known Issues and Risks of this Version   Known Issues and Risks of this Version
Line 203 
Line 70 
  Third-Party Software Included with PEAK   Third-Party Software Included with PEAK
      All third-party software included with PEAK are understood by PEAK's       All third-party software included with PEAK are understood by PEAK's

Generate output suitable for use with a patch program
Removed from v.1633  
changed lines
  Added in v.1636


Powered by ViewCVS 1.0-dev

ViewCVS and CVS Help