FivePrime Discovers Performance with Mule
FivePrime Therapeutics, Inc. is a pre-clinical stage biotech company discovering and developing innovative protein and antibody therapeutics. FivePrime currently has products in development for cancer and diabetes and multiple leads in metabolic and immunologic diseases, oncology
and regenerative medicine. FivePrime Therapeutics is headquartered in
San Francisco.
“With the abstraction Mule provides, it’s easy for your application to fire an event, register listeners, and send data over any protocol you want. It’s a very natural programming model.”
Jonny Wray , Senior Architect , Five Prime Therapeutics
The Challenge – improving the performance of custom applications
 |
In the drug discovery industry, companies develop libraries of compounds which could be potential drugs and apply screens to test their potential efficacy to treat a particular disease. One popular screening method, known as “high-throughput screening” (HTS) combines a range of tests and sensors to run a very large volume of tests in a very short period of time. HTS has traditionally been applied to small molecule based discovery. What’s novel about FivePrime Therapeutics is that it’s applying the HTS method to protein therapeutic discovery.
At the same time, because FivePrime Therapeutics screens proteins —
rather than chemical compounds — the company was not able to use an off-the-shelf HTS system.
“We set up a screening platform based on the concepts of HTS, but changed it to accommodate for the protein side of it, which basically had to be created from scratch. Since the data tracking is so different, and there were no existing LIMS (laboratory information management systems) out there that were optimized for proteins, we decided to develop our own,” said Jonny Wray, Senior Architect with FivePrime.
Central to FivePrime’s protein LIMS design was the need to track data from the various stages of the screening pipeline. Data needed to be tracked and stored, and scientists needed to have the ability to view / search / manipulate that data on the fly. To achieve those ends, Wray originally constructed a LIMS as a standard web application using Spring and Hibernate, talking to an Oracle database with an HTML front end. But the needs of the users outgrew the HTML front-end.
“I started with the web-based client,” said Wray. “Then the scientists started asking for more interactivity, so I looked at FLEX and Laslo. This was before AJAX had gotten sexy, I suppose. I did some work with SVG for dynamic, data driven interactive graphics within a web browser, which the users loved, but they still wanted more. So in the end I went to a Swing client which has proved to be a very good decision, because I’d reached the limitations of trying to force a rich client into a browser base.”
In constructing the Swing application, Wray exposed the service layer that was in the web application over Spring’s HTTP invoker.
“That worked very well, but a problem arose when I started to notice that some of the things we were doing with this system were very computationally intensive,” said Wray. “Scientists needed the ability to launch various algorithms on data and then view and manipulate the results. A number of these algorithms were potentially computationally expensive, resulting in long request times.”
A typical example of the type of “computationally expensive” computing that Wray was seeing was in “sequence alignment” scenarios — where scientists needed to take a number of biological sequences and look at their similarity, or their similarity to the Human genome.
“In this scenario, the sort of naïve HTTP invoker type of approach basically just leaves a connection open from your Swing application to your server while the job finishes,” said Wray.
“It was a synchronous invocation approach that was becoming computationally less and less viable, and a move to asynchronous request-response invocation was needed.”
The Solution – decoupled services and enterprise backbone
Today Wray is using Mule, alongside ActiveMQ as his JMS system, as the infrastructure underlying a number of asynchronous request-response services for Swing applications.
He has also applied Mule to another requirement of the system: much of the data comes into the systems from machines in the lab, which spit out text files which need to be parsed and data inserted into the database. With Mule, Wray has created a service that — once data is collected in a certain format — it is dropped into a folder on the share drive. In the share drive, Mule picks up that file using the file transport, and then based on the content type dynamically routes it to the correct parser, which then sends it to the appropriate database.
“Mule is a very important part of our screening process,”
said Wray. “It’s basically the backbone of the solution to get sections of the data into the database.”
Moving forward, Wray intends to migrate more of the services used by the Swing application to a Mule-based backbone for asynchronous invocation. Wray is another great example of a developer who is leveraging the customization flexibility of Mule to attack a set of very specific integration requirements in his environment.
“I’ve found that with the Mule design, there’s nothing I’ve come across that I haven’t been able to work around,” said Wray. “With Mule you can always go down to the lowest level of code and make modifications. Very often with other approaches it’s very hard to do something beyond the imagination of the person that wrote it, but that’s not the case with Mule.”
