As scientists increasingly rely on big data to drive their research, a new set of software tools is emerging. Two of these new tools, developed by Microsoft’s External Research division, were launched on Monday at the Microsoft Research Faculty Summit in Redmond, Wash. They include the Project Trident workbench and the Dryad/DryadLINQ programming environment.

Project Trident was originally aimed at oceanographic applications (hence the name). The work began as a collaboration between Microsoft External Research, the University of Washington and the Monterey Bay Aquarium to provide a high-level workflow tool for oceanographers. Oceanography, like many scientific domains today, is being inundated with a deluge of data that researchers are struggling to manage.

Once the proof-of-concept stage for Project Trident was completed, Microsoft realized it could be used as a general-purpose platform for other areas, such as astronomy, environmental science, medicine or essentially any type of research that is dominated by workflow issues. The data is coming from a growing number of inexpensive sensors that collect information in real time as well as an ever-expanding collection of scientific databases being stored on the Internet or in private repositories. In many cases, both data rates and data volumes are growing beyond the capabilities of traditional software environments.

Unlike the commercial world, the science community tends to freely pass its data around. But turning the raw information into useful knowledge often requires weeks, months or even years of software development involving customized scripts and applications. The whole idea behind Trident is to enable workflow applications to be developed by scientists, rather than programmers, by structuring the process into modular steps.

“Why lock your knowledge up into scripts or programs when you could actually write it in a tool that other people stand a chance of reusing,” asks Roger Barga, who is leading Microsoft’s development of Project Trident. According to him, researchers are recognizing that the model of customized workflow development is not sustainable. Even if software maintenance were less expensive, scientists are looking for the kind of speed and flexibility that a code rewrite does not allow.

The Trident workbench is being used today by oceanographers at the University of Washington for seafloor-based research that uses thousands of ocean sensors and by researchers at the Monterey Bay Aquarium Research Institute to study Typhoon intensification.  The workbench is also being employed by astronomers at Johns Hopkins University to support the Panoramic Survey Telescope and Rapid Response System (Pan-STARRS) project, which is looking for objects in the solar system that could pose a threat to Earth. In this case the data being ingested comes from an array of 1.4 gigapixels digital cameras that capture images of the night sky.

In a nutshell, the Trident workbench tool provides a visual framework for managing and developing workflows. At startup, the user sees a library of existing workflows and activities (or workflow steps). In the GUI, one can add or delete steps from the pipeline by simply dragging and dropping. The idea is that domain experts with no programming knowledge can go in and mix and match existing workflow components to author new experiments and run them on the fly.

A typical workflow would start with reading in the raw data — data files and/or sensor devices. The next step would be to convert the various data sources into a common format. An analysis pipeline — filtering and conditioning algorithms — would come next. Typically the last step is to produce a visual representation of the result.

It’s not all just shuffling objects around a GUI, however. The individual activities, such as reading the raw data, analyzing it, and creating visualizations have to be developed in the first place, as you would any other piece of software. But once developed, the activities can be bound to any user-generated workflows. According to Barga, their experience has been that once you get more than a dozen or so workflows constructed, the users find they’re no longer writing much new code.

One of the important strengths of Trident is that it can utilize HPC clusters. Scientific analysis at scale often requires a high performance computing platform for reasonable performance. By default Trident assumes a single node execution, but users can schedule a job across multiple cluster nodes by creating a workflow application that communicates with the HPC job scheduler.

As one might have guessed, the assumed clustering environment here is Microsoft’s Windows HPC Server, but Trident does allow you to plug in your own scheduler too. This enables researchers to run on a Linux cluster, which remains a much more common platform today for high performance computing. Barga says plugging into a non-Windows scheduler is just one of the different ways Trident has been designed for extensibility, noting that even the tool’s GUI can be replaced should users wish to have a customized look and feel. One dependency that cannot be jettisoned, however, is the Windows .NET framework. The .NET environment contains the Windows Workflow, which is the foundation of the Trident workbench.

The other tools Microsoft released on Monday — Dryad and DryadLINQ — are aimed at developers rather than end users. Dryad itself is a general-purpose data parallel programming runtime designed to run distributed applications on Windows clusters. The runtime is responsible for scheduling resources, handling hardware and software failures, and distributing data and code across the cluster as needed. DryadLINQ is an abstraction layer that runs LINQ (Language Integrated Query) operations on top of Dryad, the idea being to be able to execute data queries that automatically get parallelized via the Dryad runtime.

Unlike MPI, Dryad is not for latency sensitive computation. It is aimed at applications that can increase data throughput via loosely-coupled parallelization. Microsoft Research itself uses Dryad internally for search engine and machine learning research. Barga says they have scaled such applications up to 3,000 nodes on a Windows HPC Server cluster, noting that some of these jobs run for dozens of hours. “The beauty of the Dryad runtime is that if an individual node drops out or there’s a failure in one of the jobs, Dryad automatically recovers, moving the computation off the failed node and reproducing inputs that node was responsible for,” says Barga.

Microsoft is really offering Trident and Dryad/DryadLINQ as two separate solutions, but with interoperability. Trident includes a pre-defined custom activity that invokes Dryad/DryadLINQ, allowing the programmer to pass it LINQ queries. But the real intention seems to be to encourage users to develop their own Dryad/DryadLINQ components to hook into the Trident workbench or use them in standalone applications.

Trident and Dryad/DryadLINQ will be released under the MSR-LA license (Microsoft Research License Agreement) and, as such, is for non-commercial academic use only. Barga says Microsoft is considering some sort of license arrangement for commercial users, but without any requirement for royalty paybacks. The bottom line here is that Microsoft is not looking to generate revenue directly from these tools, but rather to expand the Windows ecosystem for researchers and encourage use of the Windows HPC Server platform.

Barga couldn’t talk about any future interoperability between these tools and Microsoft’s Azure cloud computing platform, but it’s reasonable to assume that all these technologies are heading toward convergence. “Science is moving to the cloud and we want to make sure that all of the tools that we offer, including things like Dryad and Trident … will work on the cloud for scientists who want to do really big data challenges,” says Barga.