Biomedical Engineering Reference
In-Depth Information
In this case the PHP MediaWiki plug-in was not doing the chemistry;
we actually utilised Python web services. We chose Python because our
toolkit of choice, OpenEye, has C++, Java or Python bindings [11].
Python made the most sense in this scenario, as it was straightforward to
add to Apache. There are, of course, other toolkits available with different
bindings for your language of choice. The web service would either depict
the provided SMILES string or perform a MySQL database lookup of the
AstraZeneca compound collection to retrieve and depict the relevant
SMILES. We wrote various web services - the wiki uses two, Smiles2Gif
and AZ2Gif. We have since updated them to write high-resolution PNG
images as opposed to the original low resolution GIF images. To achieve
this we use Qt, as this gives us additional control over the images, for
example the thickness of the bonds, via the pen controller [12].
Once the decision to write Design Tracker was taken we needed to pick
the platform to develop on. Given our previous success with Python, we
opted to use Django, one of many web frameworks available for Python
[13]. Using Python natively meant we could also use the OpenEye toolkits
from directly within the application. In terms of the deployment it is the
same model as MediaWiki: Apache and MySQL. The only difference is
using a Python-Apache link, opposed to PHP-Apache link. Again our
single server was able to handle this, but as the popularity of Design
Tracker spread across the company's global sites it became apparent that
a more robust solution was required. The existing system had no failover
or high availability component; redundant hardware would not protect
against MySQL crashing. Our system became locked at fi xed and dated
versions of all software which was hindering both development and
expandability. The decision was taken to invest in a new system to host
our numerous Django applications, Design Tracker being the biggest.
The platform needed to be robust, scalable, highly available and future-
proofed.
At the time Django was a web framework solution that was in its
infancy. When we began to start to write Design Tracker, Django version
0.96 was the latest version. What attracted us to Django was the fact that
it was open source and was clearly being developed by a relatively large
community. There was excellent up-to-date documentation and tutorials
online, a roadmap to version 1.0 was clearly defi ned, and a number of
Google groups were discussing Django and offering advice and tips.
Most importantly of all, Django is written in Python.
Django also makes the developer create code in a very structured way.
This was important as the code base would be written by computational
chemists and not dedicated software programmers. Our computational
Search WWH ::
Custom Search