File contents
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
<chapter>
<title>Acs and Zope (ZOACS)</title>
<section>
<title>Introduction</title>
<section>
<title>ACS </title>
<para>
The ArsDigita Community System is a best of breed open source toolkit
for creating high performance applications built around a community
core. </para>
</section>
</section>
<para>
heres the marketing line (from arsdigita.com)
...<para>
The ArsDigita Community System (ACS) provides a flexible platform to
develop Web applications uniting people, partners and processes. ACS
provides organizations with tools for content management, commerce,
collaboration, personalization, and marketing and analysis. Fully
integrated through a single data model to ensure consistency across
all business processes, ACS enables customers to capitalize on the
benefits of collaborative commerce.</para>
<section>
<title>Zope</title>
<para>
Zope is a best of breed open source toolkit focused on rapid
application development, OO development, and content management.</para>
<para>
heres the marketing line (from zope.org)
...<para>
Zope is the leading Open Source web application server. Zope enables
teams to collaborate in the creation and management of dynamic
web-based business applications such as intranets and portals. Zope
makes it easy to build features such as site search, news,
personalization, and e-commerce into your web applications.</para>
<section>
<title>Integration</title>
<para>
All of the above sounds pretty similiar, but the two are fundamentally
different systems under the hood. Zope is based on an object database
publishing system, while the ACS is a relational application. Zope
offers a great deal of functionality via hundreds of drop in products,
but these products vary widely in purpose and functionality which makes
them a bit difficult to integrate into an existing site. The ACS is
built around a community core, and leverages that core in all of its
applications.</para>
<para>
The focus of integration effort is to leverage the ACS datamodels with
Zope as a development environment. The degree of integration is variable.
I'm currently focused on integrating the entire community core, but
opportunities exist to piecemeal in ways that can profundly affect zope's
functionality.</para>
<section>
<title>Benefits of Integration (Zope Perspective)</title>
<itemizedlist>
<listitem><para>
scalability in high write scenarios</para></listitem>
<listitem><para>
leverage community core to build types of applications, with
easier app integration</para></listitem>
<listitem><para>
easier analysis, member value, etc. using relational model.</para></listitem>
<listitem><para>
gains whole set of applications</para></listitem>
<listitem><para>
replace existing zope products with more capable/extensible acs
versions</para></listitem>
<listitem><para>
trickle down technology. zope gets an OR layer!, PageContract</para></listitem>
</itemizedlist>
<section>
<title>Benefits of Integration (ACS Perspective)</title>
<itemizedlist>
<listitem><para>
use zope's integration capabilities to build new types of acs apps
(ldap, xml, etc).</para></listitem>
<listitem><para>
faster development. develop interfaces/ui with zope, prototype with
the zodb.</para></listitem>
<listitem><para>
trickle down tech... aid to porting/code generation.</para></listitem>
</itemizedlist>
</section>
</section>
</section>
</para>
</section>
</para>
<section>
<title>Design</title>
<section>
<title>Why ACS4</title>
<para>
the current openacs production version is 3.2.X, this is not the
version that�we're discussing integration wrt zope integration. the
acs3x system has a bunch of flaws from a design perspective that
weaken the unity of a whole, �despite the fact that individually
the modules are generally well done. the whole system grew organically
as aD did consulting gigs and implemented new functionality. the
whole thing comes across looking like a lot of line noise
� from tcl html integration (although some sites use the karl goldsteins's
� DPS, which mitigates somewhat), bloated redundant libraries, and ad hoc
� methods of integrating distinct application data models, etc. i could
go on�at length with why i think 3x is not a good platform for extensible
component based development, but i think it suffices to say that this
is not�the acs target we're looking to integrate.</para>
<para>
so why the acs4,the acs4x is a quantum leap in architecture.
it features<itemizedlist>
<listitem><para>
a templating system (content/logic separation)</para></listitem>
<listitem><para>
a request processor (acs3x relied soley on registering procs with
�aolserver)</para></listitem>
<listitem><para>
most importantly a thin oo layer over the relational
�system, including centrailized oids, metadata, versioning.
this gave support to the acs offering generic object services
and inter application communication.</para></listitem>
<listitem><para>
centralized db api (3x had a variety of styles), this also�takes
care of nested transactions contexts.</para></listitem>
<listitem><para>
autonomous virtual subsites (multiple package instances)</para></listitem>
<listitem><para>
the package system/manager</para></listitem>
</itemizedlist>
</para>
<para>
again i could probably go on at length why this is a better system
than 3x,�but here's a pointer to the docs so you can decide for yourself.</para>
<para>
http://www.arsdigita.com/doc</para>
<para>
and</para>
<para>
http://developer.arsdigita.com/doc</para>
<para>
i would not recommend to anyone, using the acs3x unless they need an
application that has not been ported to acs4x. the openacs.org is going
to�become the official platform for all further acs-tcl (4x) development
� supporting initially both postgres and oracle. check the openacs site for
� more info.</para>
<para>
http://www.openacs.org</para>
</section>
<section>
<title>Is it Possible?</title>
<orderedlist>
<listitem><para>
i think a good example of the feasibility is the complete
port of the acs-tcl to java. the key here is the data models that
comprise the domain knowledge of the acs. Integration is focused
on leveraging the datamodels for new application creation.</para></listitem>
</orderedlist>
</section>
<section>
<title>Porting Domain Logic (existing apps and core)</title>
<para>
The bulk of domain logic in the acs resides in queries to the
database. A key porting effort will be in isolating these queries
from logic pages to generate ZSQL Methods (or something similar).</para>
<section>
<title>Query Dispatcher</title>
<para>
to achieve database independence the openacs team decided to
create an intermediary to the db api which would locate a
particular query for an individual database based on a unique
query id. to operate the query dispatcher loads up queries from
xml files which contain db specific queries.</para>
<para>
this same concept can be used in zope to maintain db independence
further more as queries are actual objects it allows a greater
degree of control over caching of individual queries.</para>
</section>
<section>
<title>Query Extractor </title>
<para>
to facilitate openacs development i wrote a set of python utilities
to extract the queries from existing tcl pages and to generate
xml query files from them. this tool can be used as is in a port
to zope (minor mods for proper xml encoding of query files).</para>
</section>
<section>
<title>PageContract </title>
<para>
almost every .tcl page in the acs starts off with a ad_page_contract
function call which performs request validation and documentation.</para>
<para>
i've written a port of this to zope, which can be used in to maintain
the logic flow of .tcl pages in zope. it can be found at</para>
<para>
http://www.zope.org/Members/k_vertigo/ZopeProducts/PageContract</para>
<para>
most (~60%) of the .tcl pages in the acs consist of ad_page_contract
setting a few variables, and a query or two. </para>
</section>
</section>
<section>
<title>Porting the Presentation Layer</title>
<para>
ACS uses a simple template system (perhaps not so simple under the hood)
with a limited presentation template language. Automatic porting of all
the templates should easily be possible with Zope. This should
part of the integration should be fully automated.</para>
<para>
A couple of different strategies come to mind in porting the ACS
convention of two files for every content page (logic+presentation),
perhaps the easiest is defining an AcsPresentationObject which would
evaluate a logic section and set variables in the namespace before
evaluation of . possiblities exist to use the new Zope
PresentationTemplates, although i'm not familiar enough with them
to make any guarantees.</para>
</section>
<section>
<title>Creating Object Oriented Interfaces</title>
<para>
The real key to integrating the ACS with zope is to create a set
a of OO interfaces to the datamodels such that zope developers can
develop new applications in a normal zope manner.</para>
<section>
<title>OR Mapping/SmartObjects </title>
<para>
I started work with iuveno on designing a new OR layer for zope that
will be usable with the acs datamodels. the goals of this layer
are to give developers access to objects which map onto the
relational tables of the ACS. my fledgling design can be found @</para>
<para>
http://www.zope.org/Members/k_vertigo/smartobjects</para>
<para>
I recently went to Virginia and met with some of the Digitial
Creation (makers of zope) to discuss OR integration (among others),
Jim Fulton and Shane Hathaway brought up an alternative proposal
to smart objects namely creating the OR layer underneath the ZODB
to achieve transparency. This is surprisingly elegant and
disturbing at the sametime. </para>
<para>
shane has prototyped this and written up a proposal that can be seen
@
proposal
http://dev.zope.org/Wikis/DevSite/Proposals/ORMappingDB
prototype
http://www.zope.org/Members/hathawsh/orconn.tar.gz</para>
</section>
<itemizedlist>
<listitem><para>
Defining ACS Metamodels<para>
generated from the .sql files to create an xml definition for
acs objects</para>
</para></listitem>
<listitem><para>
Using Metamodels for portability and code generation<para>
using the xml definition to generate sql ddl for various databases
including stored proc signatures.</para>
</para></listitem>
</itemizedlist>
</section>
<para>
Translating The Libraries</para>
<para>
Security and Permissions</para>
<section>
<title>Writing a Package Manager</title>
<itemizedlist>
<listitem><para>
extending the Product definition</para></listitem>
<listitem><para>
extending the Package definition</para></listitem>
</itemizedlist>
</section>
<section>
<title>Partial Integration </title>
<para>
Using ACS Service Packages by themselves. Replacing
CMF Workflow with ACS Workflow.</para>
</section>
</section>
<section>
<title>Conclusions</title>
<para>
The infrastructure and automation tools needs to be built. After this
the bulk of the work will consist of porting .tcl www files and
porting the tcl libraries to python modules. </para>
<para>
the infrastructure and automation tools should be usable on acs-java.
at this time the number of packages and its stability don't justify
the time investment. in future this could be a very likely possiblity
depending on the direction of acs java, and due to java's more
regular syntax would likely be easier for automation tools.</para>
</section>
</chapter>
Log in
Forgot your password?
