I’ve been interviewed by Open Enterprise Trends about Ampoliros (Web Archive version). This is the interview.
By Vance McCarthy
Last week, the developer team behind Ampoliros released the latest upgrade to its Open Source project aimed at providing developers a component-based platform for building and deploying web services by marrying Open Source and commercial software.
Ampoliros 3.0 is based on PHP technologies, and brings developers the ability to build integrateable web services by allowing them to code in smaller modules. In addition, the technology helps sysadmins centrally administer distributed services based on SOAP, XML and/or SQL — across both corporate intranets and extranets.
Open Enterprise Trends spoke with Alex Pagnoni, Ampoliros Team Project Leader, to get details on how the technology works and how developers can best use it. The latest version is available for download free from http://ampoliros.com/ and at SourceForge.
OET: What was your goal in inventing Ampoliros? What functionality was
missing for Open Source developers that prompted your work?
Pagnoni: Ampoliros was born to provide developers the opportunity to reuse their code at the maximum level and to let system administrators do real administration stuff with minimum installation and management efforts for the applications. We also wanted to offer end users a pleasant and uniform interface. Another Ampoliros goal is to administer not only a site, but an unlimited number of sites with a single Ampoliros installation; this is very important for service providers. The first release was out on February 2000.
OET: What technology(ies) is Ampoliros based on (PHP, Python, etc.)?
Pagnoni: Ampoliros is based on and introduces open technologies and standards. It is written in PHP language and uses technologies and formats like XML, XML-RPC, SOAP, and SQL. Even the various included images are based on the PNG open format as much as possible. To allow for groups of developers to work on deployment, Ampoliros also uses CVS (Concurrent Version Systems).
OET: What skills would a developer or sysadmin need to work with Ampoliros?
Pagnoni: The developer who would work with Ampoliros should meet three basic requirements: (1) good knowledge of PHP and object-oriented programming under PHP; (2) knowledge of SQL language; and (3) comprehension of XML. The Ampoliros site contains a development overview page, with links to the various needed resources: APIs, useful tools, the current SDK with examples. We’re also putting together an Ampoliros applications style guide.
OET: What features of Ampoliros do you think developers would find most interesting or useful?
Pagnoni: In a few words, our focus is to give developers less code to write, and to provide extreme reusability of components. The idea is to provide developers an easy way to customize applications, as well as support easier types of database and application integration through support of abstraction and web services.
OET: Sounds impressive. How does Ampoliros provide these capabilities? Do you leverage existing database and web services standards?
Pagnoni: Right now, Ampoliros delivers SQL database abstraction (MySQL and PostgreSQL are available at this stage), and provide a web services interface (through both XML-RPC and SOAP). The Ampoliros platform also provides special services based on these standards, including caching, automatic database tables update, “hooks” (a way to extend code, even written by others, beyond the original specifications) and a debugger.
OET: Will Ampoliros work well with commercial and web services technologies such as Java, .NET, XML, etc.?
Pagnoni: In general, Ampoliros is designed to achieve scalability, provide availability and manage and hide complexity. As side effects, you also obtain manageability, rapid development and deployment, interface common look and feel, and adaptability to end-user needs. An Ampoliros white paper is available.
OET: So, would you say Ampoliros changes the nature of app development or system administration?
Pagnoni: Perhaps, but let’s explain it this way: In Ampoliros terminology, applications are called modules.
The usual paradigm is to install and configure each application for each
site in several steps:
- (1) read their own installation documentation;
- (2)manually change various files (sometimes even the code);
- (3) set up database (or change tables if you are updating); and then
- (4) hope all this works, integrate it with other applications and so on.
In Ampoliros, you install the application once by simply uploading a file in the root administration and enable it to as many sites as you need with only a mouse click. To upgrade a module (application), you only upload the new module archive. Since Ampoliros itself is a module, you can upgrade an entire Ampoliros installation with hundreds of sites with only an upload, too. All this greatly improves time to market and total cost of ownership.
OET: What is your road map for Ampoliros moving forward? Are there any new web services features on your to-do list?
Pagnoni: For the next Ampoliros versions, I have a lot of ideas. One is to automatically map a web-based (server-side) interface into a Gtk-based (client-side) one by only changing a setting at runtime. The Ampoliros framework is ready for this.
Another idea would be to implement a scripting feature to allow developers to better combine or integrate web services, complex tasks and events in a very easy manner.
For example: As an event occurs, such as “registering a new user to a site,” a call to a remote web service would be performed automatically. With one line of text in a form, the user would trigger that update. This kind of feature, while not implemented yet, is based on Ampoliros technology that’s already there. Only a parser needs to be implemented.
Take this idea one step further, and you can see where a workflow graphical interface may also be implemented for this feature, in order to create short procedures for very complex tasks with a few mouse clicks.
OET: These examples seem targeted toward support for working with enterprise applications. Are there other elements of Ampoliros that might help enterprise developers be more productive using their existing enterprise software?
Pagnoni: There are two other projects not directly involved in our code: the AmpCentral and the ModBuilder. With the AmpCentral, a developer or sysadmin could retrieve and upgrade modules through web services calls. The ModBuilder, now in the concept stage, will be a “module for building Ampoliros modules,” even allowing multiple developers to work together work groups. AmpCentral and ModBuilder may work together to make web services easier to build, deploy and manage.
An example scenario might go like this: As soon as you release a new module version with ModBuilder, with a mouse click you send it to the AmpCentral, and the AmpCentral resends it to the various subscribed Ampoliros installations. Imagine what this would mean to productivity.
OET: And all this would remain Open Source?
Pagnoni: Yes. I’m also working on Envoy, a Linux distribution based on Ampoliros as application server.
OET: You mentioned a debugger earlier. Does it help debug or optimize code modules/components that might come from different contributors, or allow developers to work in workgroups?
Pagnoni: With the Ampoliros debugger, you can examine each Ampoliros “instance.” First of all, you set the Ampoliros “state” to debug mode; for each Ampoliros instance, a process file is created and the graphical debugger lets the developer to see a number of aspects, including (1) various environment information; (2) SQL queries issued; (3) the opened libraries; (4) all PHP errors, warnings and even the notices; (5) database errors; (6) every logged event; and (7) the defined functions and classes. Ampoliros also has a profiler and a “bug report” feature available. The Ampoliros tutorials provide background and screenshots about the debugger.
OET: Do you have examples of where developers have used Ampoliros to solve a problem in their enterprise network?
Pagnoni: I run a business entirely based on Ampoliros technology — it’s called Solarix. We have an Ampoliros installation for our intranet, and an Ampoliros installation for the Solarix and Ampoliros sites. Then there are the various customers’ Ampoliros installations.
In the Solarix site, (which is entirely built on top of the Ampoliros-based Magellan content management system), there is a customers’ reserved area that shows, for each customer, its billing status, projects status, hosts status; in the customers server, there are the HostMan activator modules. For the intranet, we also have the work group, accountancy, project management modules (the XenIntranet modules) and the remote hosts configuration management modules (the HostMan modules).
OET: And how does it all work?
Pagnoni: So we have the following final situation: From the intranet we can control and maintain the customers’ hosts, and we can also manage custom projects, accountancy and billing. The customers can see the status of their hosts in the customers’ reserved area at the Solarix site, and they can see their billing status and can pay using a credit card. Customers can also see the status of their projects and can submit trouble tickets or new requests, which get sent to our Intranet.
Some of the customers have Ampoliros in their intranets, too. From there
they can administer their hosts through HostMan (create e-mail for their
customers, reboot the host, etc.) in the same way we can from our intranet. The changes are automatically reflected in the various HostMans. The focus of all this is using Ampoliros alongside web services.
OET: What is the current version of Ampoliros available for download?
Pagnoni: The current version of Ampoliros is 3.1.1, generation 3000. New Ampoliros versions get released very often, about once a week or two. Compatibility between the various versions is guaranteed because of how Ampoliros is designed. To give you an example, there are some old applications not updated since the beginning of 2001 that can still work in the last Ampoliros release — and these applications will always work.