| 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: |
|
| http://www.omg.org/technology/documents/modeling_spec_catalog.htm |
|
| |
|
| * 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). |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| * 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 |
|
| providers. |
|
| |
|
| - 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 |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| 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 |
Diff of /PEAK/README.txt
Parent Directory
| 
Revision Log