Acs and Zope (ZOACS) Introduction ACS The ArsDigita Community System is a best of breed open source toolkit for creating high performance applications built around a community core. heres the marketing line (from arsdigita.com) ... 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. Zope Zope is a best of breed open source toolkit focused on rapid application development, OO development, and content management. heres the marketing line (from zope.org) ... 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. Integration 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. 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. Benefits of Integration (Zope Perspective) o scalability in high write scenarios o leverage community core to build types of applications, with easier app integration o easier analysis, member value, etc. using relational model. o gains whole set of applications o replace existing zope products with more capable/extensible acs versions o trickle down technology. zope gets an OR layer!, PageContract Benefits of Integration (ACS Perspective) o use zope's integration capabilities to build new types of acs apps (ldap, xml, etc). o faster development. develop interfaces/ui with zope, prototype with the zodb. o trickle down tech... aid to porting/code generation. Design Why ACS4 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. so why the acs4,the acs4x is a quantum leap in architecture. it features o a templating system (content/logic separation) o a request processor (acs3x relied soley on registering procs with �aolserver) o 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. o centralized db api (3x had a variety of styles), this also�takes care of nested transactions contexts. o autonomous virtual subsites (multiple package instances) o the package system/manager 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. http://www.arsdigita.com/doc and http://developer.arsdigita.com/doc 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. http://www.openacs.org Is it Possible? definitely. 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. Porting Domain Logic (existing apps and core) 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). Query Dispatcher 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. 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. Query Extractor 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). PageContract almost every .tcl page in the acs starts off with a ad_page_contract function call which performs request validation and documentation. 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 http://www.zope.org/Members/k_vertigo/ZopeProducts/PageContract most (~60%) of the .tcl pages in the acs consist of ad_page_contract setting a few variables, and a query or two. Porting the Presentation Layer 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. 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. Creating Object Oriented Interfaces 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. OR Mapping/SmartObjects 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 @ http://www.zope.org/Members/k_vertigo/smartobjects 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. 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 o Defining ACS Metamodels generated from the .sql files to create an xml definition for acs objects o Using Metamodels for portability and code generation using the xml definition to generate sql ddl for various databases including stored proc signatures. Translating The Libraries Security and Permissions Writing a Package Manager o extending the Product definition o extending the Package definition Partial Integration Using ACS Service Packages by themselves. Replacing CMF Workflow with ACS Workflow. Conclusions 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. 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.