| .. Licensed to the Apache Software Foundation (ASF) under one |
| or more contributor license agreements. See the NOTICE file |
| distributed with this work for additional information |
| regarding copyright ownership. The ASF licenses this file |
| to you under the Apache License, Version 2.0 (the |
| "License"); you may not use this file except in compliance |
| with the License. You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, |
| software distributed under the License is distributed on an |
| "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY |
| KIND, either express or implied. See the License for the |
| specific language governing permissions and limitations |
| under the License. |
| |
| Platform Architecture overview |
| =================================== |
| |
| I'm told that the reason you build a platform is to "reduce the marginal cost |
| of developing applications." Sounds good. Well, actually it sounds a bit |
| dry. But it's about right, we want to make creating new online development |
| tools faster, easier, and more fun, which I guess is the "reduce the marginal |
| cost" thing. |
| |
| Platform building blocks |
| --------------------------------------------------------------------- |
| |
| Before we get into the details of how to extend the Allura platform, perhaps |
| it would be smart to explain some of the big pieces and why they are there. |
| |
| We wanted Allura tools to be fast, we needed them to scale, and we had some |
| complex requirements for data storage and extensibility. So, we needed a |
| **fast,** flexible, and easy to use data persistence system. |
| |
| We were very impressed by the general message architecture of Roundup, but we |
| wanted to extend it from just email messages to include scm commits, and we |
| added a message bus (RabbitMQ which we'll talk about in a second), to make |
| it fast. |
| |
| .. image:: _static/images/messages.png |
| :alt: Message Architecture |
| |
| We were also impressed by the flexibility of Roundup's Hypertable system in |
| allowing for ad-hock ticket schema additions. |
| |
| It definitely seemed like something we wanted in a next generation forge, |
| because we wanted app tools to be able to: |
| |
| * create and version their own document types, |
| * extend existing document structures, |
| * and to mange document revisions, access control lists, and other |
| platform level data. |
| |
| In spite of the power and flexibility of the Roundup HyperTable |
| implementation, we had some concerns about performance and scalability. |
| |
| Fortunately several of the Allura authors used MongoDB |
| in rewriting the download flow of SourceForge.net, and knew that it could |
| handle huge loads (we saturated a 2gb network connection on the server |
| with 6% cpu utilization). |
| |
| We also knew that MongoDB's flexible replication system would allow us |
| to build the forge in such a way that we could easily provide a |
| package of all project data to developers concerned about lock-in. |
| |
| Not only that but Rick Copeland had built a couple of custom Object |
| *Non*-Relational Mappers (ONRMs?) before, including one for MongoDB, |
| and he whipped up Ming, which backed on MongoDB and gave us exactly |
| what we needed. |
| |
| As I mentioned before we also needed a fast, flexible message bus and queuing |
| system. RabbitMQ was (lightning) fast, (shockingly) flexible, but not super |
| easy to use. Fortunately we didn't have to roll our own wrapper here, as |
| the Python community already whipped up Carrot, and Celery, which made |
| working with the RabbitMQ based AMQP bus a LOT easer. |
| |
| |
| Application Tools |
| --------------------------------------------------------------------- |
| |
| Writing a tool for Allura is as simple as defining a few controllers |
| to handle particular URL's, templates to render pages, and defining the schemas |
| of any Allura document types that your tool requires. |
| |
| .. image:: _static/images/tools.png |
| :alt: App Tools |
| :align: right |
| |
| When you write Allura tools, you'll get lots of stuff for free: |
| |
| * Search-ability of your Artifacts |
| * Artifact versioning for accountability and transparency |
| * Ability to extend existing Artifacts |
| * Reuse central User/group/permission management |
| * A robust and flexible permissions system |
| * Access to a real-time event publishing system |
| |
| What's in a tool? |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| The most basic app tool consists of a few things: |
| |
| * A controller object (instantiated per request) |
| * Template files (optional) |
| * UI Widgets (optional) |
| * Extensions to existing Artifacts (optional) |
| * New Artifact types (optional) |
| * Event listener tools (optional) |
| * Event publisher (optional) |
| |
| Users/groups and Permissions |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| In order to facilitate more open processes, where more users can contribute |
| -- while still protecting data -- documents can easily be "versioned", and |
| the platform provides tools to manage versioned documents for you. |