TransWarp Preview Release 0.1 |
PEAK Release 0.5 alpha 3 |
|
|
Copyright (C) 2001 Phillip J. Eby, All rights reserved. |
Copyright (C) 1996-2004 by Phillip J. Eby and Tyler C. Sarna. |
This software may be used under the same terms as Zope or Python. |
All rights reserved. This software may be used under the same terms |
|
as Zope or Python. THERE ARE ABSOLUTELY NO WARRANTIES OF ANY KIND. |
|
Code quality varies between modules, from "beta" to "experimental |
|
pre-alpha". :) |
|
|
Please see http://www.zope.org/Members/pje/Wikis/TransWarp for tutorials, |
Package Description |
FAQs, package layout, etc. Selected pages from the Wiki are included |
|
in the docs/ directory for your convenience. |
|
|
|
At this time, the 'Features', 'Aspects', 'SOX', and 'tests' modules |
PEAK is the "Python Enterprise Application Kit". If you develop |
and packages are usable, if not necessarily full-featured. All other |
"enterprise" applications with Python, or indeed almost any sort of |
modules/packages (except as imported by the above) are under heavy |
application with Python, PEAK may help you do it faster, easier, on a |
construction - don't enter without a hard hat! (That is, |
larger scale, and with fewer defects than ever before. The key is |
use them at your own risk. Although, there's no warranty that any of |
component-based development, on a reliable infrastructure. |
the other stuff works, beyond the fact that the tests run on my |
|
home computer.) |
|
|
|
|
PEAK tools can be used with other "Python Enterprise" frameworks such as |
|
Zope, Twisted, and the Python DBAPI to construct web-based, GUI, or |
|
command-line applications, interacting with any kind of storage, or with |
|
no storage at all. Whatever the application type, PEAK can help you put |
|
it together. |
|
|
INSTALLATION INSTRUCTIONS |
|
|
|
To use this package, you will need to install it by placing the TW/ directory |
Package Features |
inside a directory which is listed in your Python path. You will also need |
|
to install Aaron Watters' "kjbuckets" library, and Jim Fulton's "Scarecrow" |
|
Interfaces package. |
|
|
|
Later versions will hopefully automate some of this as we learn to use the |
|
Python distutils, but for now, you have to do everything yourself... |
|
|
|
Getting and Installing kjbuckets |
As of version 0.5a3, PEAK features include: |
|
|
Unix Platforms |
* 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. |
|
|
You can download the C source code for kjbuckets at: |
* 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. |
|
|
http://www.chordate.com/kjbuckets/ |
* 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. |
|
|
And build as you would any other Python module. |
* 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. |
|
|
Windows Platforms |
* A storage management and persistence system, including: |
|
|
If you're using Python 1.5, you can download a pre-built kjbuckets.pyd at: |
- Atomic, multi-database transactions with two-phase commit. |
|
|
http://www.chordate.com/kwParsing/kjbuckets.pyd |
- "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. |
|
|
And then place it in your Python path. If you're using Python 2.0, |
- "Stackable" data managers: one DM might serialize a set of objects |
or can't get this to work, see "If You Can't Compile kjbuckets" below. |
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. |
|
|
If You Can't Compile kjbuckets |
- 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. |
|
|
If for whatever reason you can't get the C version of kjbuckets to work |
|
on your system, download this file: |
|
|
|
http://www.chordate.com/kwParsing/kjbuckets0.py |
|
|
|
Rename it to "kjbuckets.py", and place it in your Python path. This runs |
|
slower than the C version, but it'll do in a pinch. |
|
|
|
Getting and Installing the Interface package (aka "The Scarecrow") |
|
|
|
The easiest place to find a copy of the Interface package is in the |
|
lib/python directory of a Zope installation. Just copy it over to your |
|
main Python path, or add the lib/python directory to your Python path. |
|
|
|
Failing that, you can look at this URL for downloads: |
* 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 |
|
|
|
This is ALPHA software. Although much of the system is extensively |
|
tested by a battery of automated tests, it may contain bugs, especially |
|
in areas not covered by the test suites. Also, many system interfaces |
|
are still subject to change. |
|
|
|
PEAK includes early copies of Zope X3's 'ZConfig' and 'persistence' |
|
packages, which have had - and may continue to have - significant |
|
implementation changes. We will be tracking Zope X3 periodically, but |
|
can't guarantee compatibility with arbitrary (e.g. CVS) versions of |
|
Zope X3. |
|
|
|
Documentation at present is limited, and scattered. The principal |
|
documentation is an API reference generated from the code's lengthy |
|
docstrings (which usually contain motivating examples for using that |
|
class, method, or function). The mailing list and its archives |
|
provide a wealth of information on actual usage scenarios, |
|
recommended approaches, etc. There is also the beginnings of a |
|
tutorial on using the component binding package. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Third-Party Software Included with PEAK |
|
|
|
All third-party software included with PEAK are understood by PEAK's |
|
authors to be distributable under terms comparable to those PEAK is |
|
offered under. However, it is up to you to understand any obligations |
|
those licenses may impose upon you. For your reference, here are the |
|
third-party packages and where to find their license terms: |
|
|
|
The 'kjbuckets' module is Copyright Aaron Watters and contributors; |
|
please see the 'src/kjbuckets/COPYRIGHT.txt' file for details of its |
|
license. |
|
|
|
The 'csv' module is part of Python 2.3 and above, and is included for |
|
backward compatibility in Python 2.2. See the Python license for license |
|
details. |
|
|
|
The 'datetime', 'persistence' and 'ZConfig' packages are Copyright Zope |
|
Corporation and contributors; please see the 'LICENSE.txt' files in their |
|
directories for details of their licenses. |
|
|
|
The 'fcgiapp' module is Copyright Digital Creations, LC (now Zope Corp.); |
|
see the 'fcgiappmodule.c' for details of its license. In the same |
|
directory are distributed portions of the FastCGI Development Kit, which |
|
is Copyright Open Market, Inc. See the 'LICENSE.TERMS' file in that |
|
directory for details of its license. |
|
|
|
Installation Instructions |
|
|
|
Please see the INSTALL.txt file. |
|
|
|
|
|
|
|
|
|
|
http://www.zope.org/Members/michel/Products/Interfaces/ |
|
|
|
This may not be the best place for an up-to-date copy, but the current |
|
TransWarp code doesn't do much with interfaces yet, so it probably doesn't |
|
matter right now. |
|
|
|
|
|
TESTING YOUR INSTALLATION |
|
|
|
TransWarp comes with a fairly hefty built-in test suite. If you have |
|
the Python "unittest" module installed in your Python path, you can use |
|
it to run the test suites, like this:: |
|
|
|
python unittest.py TW.tests.suite |
|
|
|
This will run about 114 tests on various parts of TransWarp. If you have |
|
installed everything correctly, 100% of the tests should succeed. If |
|
you're missing any needed parts, you will probably experience a massive |
|
number of failures and errors. |
|
|
|