|
| Copyright © 1997 - 2024 Science Tools Corporation All rights reserved | |
     |
|
|
About
Science Tools Corporation
History
| Mission | Philosophy
| Viewpoints Introducing Science Tools Corporation
Meet the Science Tools Principals. Contacting Us:
Our History: Science Tools Corporation was founded at customer request in 1997 when the Deputy Director of the Langley Research Center's Data Active Archive Center (the LaRC DAAC) asked Richard Troy to commercialize the results of his NASA funded research he had been performing at the University of California. The BigSur ProjectWhen the NASA "Mission to Planet Earth" was first being developed, the scientific community was up in arms over (prime contractor) Hughes Aerospace's plan to manage the resulting scientific data - they were planning to ship boxes of CDs. From the ruckus the user community created, NASA funded several "EOS-DIS Alternative Architecture Studies." One of those was known as Sequoia 2000, headed by Professor Michael Stonebraker at UC Berkeley. The Sequoia 2000 project was a blue-ribbon group which struggled to discover just what the community of users of data from the Mission To Planet Earth wanted and needed in an information management system. It was decided that the earth science community needed a fully distributed, "end-to-end" solution as a single system that would handle data from satellite down link ("ingestion") through a many varied, polydisciplinary, processing workflow to end visualization tools. The end result was a report that outlined the thinking at the time. (Please see EOSDIS Alternative Architecture Technical Report 95/61, April 1995, Sequoia 2000 Technical Report, 617 Soda Hall, Berkeley CA 94720, 510-642-4662.) NASA liked the report and decided to fund the creation of the system so described. The leadership position for the new project had to be someone with substantial commercial market background because academics typically don't have the right background to create sophisticated, production-ready computing systems. The leader must have top technical skills, a track record of success, and possess good people skills to be able to manage a team which numbered over 40 people. Prof. Stonebraker performed a fairly extensive search and in early 1995 brought in Richard Troy from the database industry to lead the team. One of Mr. Troy's first acts as team leader was to replace the informal name, "Son of Sequoia" with "Big Sur", as California's national parks were the naming scheme de jour in the UCB Electronics Research Laboratory at the time. (The two words "Big Sur" were later merged into the single word, "BigSur" for the practical reason that spaces in computer work sometimes mess things up - and the concatenated form stuck.) The team Mr. Troy led included prestigious members such as Turing-Award winner Jim Gray, professors (climate modeler) Roberto Mechoso, (terrestrial scientist) Jeff Dozier, (remote sensing expert) Bill Emery, (computer scientist) Dick Muntz, and a good handful of other technologists. The system the team was to create had to be capable of managing all of the earth science data from EOS-DIS from end-to-end and to specifically address the needs of five explicit earth science disciplines. Among Mr. Troy's key technical contributions were the insights that became foundational for the system's architectural goals: It had to be inherently fully distributed with the ability to automate nearly everything related to both interconnectivity and processing. The system had to include a built-in workflow system and it had to include a robust distributed processing system - what we today call a "computing grid" (or simply, "grid computing"). Richard asserted that it was vital the system NOT embed the researcher's standards but rather absorb them, so that the system wouldn't immediately become stale as new standards are devised and adopted. The system had to learn the ways of each researcher because every researcher has their own ideas and "they're right" no mater what their community may think. That learning had to be easy. The system had to track everything it did to preserve "scientific defensibility". The system had to interconnect researchers in a deep way so they could discover each other's work easily, and make use of each other's algorithms and data sets without involving that other researcher whenever possible. The system had to be highly performant, very resource efficient, and scale to the largest possible scales. And, the system needed to know how to launch visualization tools on an as appropriate basis. As Professor Stonebraker was the creator of Ingres, and later Postgres, which was a then-current project at UC Berkeley, the BigSur team based BigSur's implementation on the Postgres Object-Relational Database System (later PostgreSQL) and built key BigSur components directly into the Postgres server engine. CommercializationOf all the EOS-DIS Alternative Architecture Studies that were funded, only The BigSur Project retained all of the original goals, and only The BigSur Project was successful at meeting its goals. In fact, the group succeeded in meeting its primary goals in less than one year and proceeded on to stretch goals, which it also met, and then created yet more new goals and then followed through with those. In the spring of 1997, Richard McGinnis, Deputy Director of the Langley DAAC contacted Mr. Troy and asked him to commercialize his BigSur Project research and create a production system for Langley. Mr. McGinnis required that the system be implemented in Java (which was at version 1.1 at the time), and be designed to work with the Informix database system (instead of Postgres). Funding was arranged, an agreement made, and thus Science Tools was born. Through the summer of 1997, Mr. Troy completely rewrote the entire BigSur System in Java, utilizing Informix on an IRIX based Origin 2000 node supercomputer, and wrote the application-level code that encapsulated the scientific processing that LaRC required. A new naming nomenclature was begun. The earlier code was dubbed "University BigSur", and the commercial release was dubbed The BigSur System™ and BigSur 1.0 went into production, on schedule, on September 1st, 1997 where it has remained in "24 X 7" production ever since. Early Commercial ServiceIn the years that have passed since The BigSur System™ went into production (1997), Langley has continued to use our products in daily production service. BigSur is the core of their system and manages all of their production of scientific data-products - LaRC refers to these as PGEs. Remaining LaRC staff member Donald Regan reported to us as recently as August, 2009 that they have upgraded the computing hardware several times, but The BigSur System™ is still in production 24X7 service, has never even once experienced a bug, and has never had a moment of down-time due to any issues pertaining to BigSur. LaRC is a good reference as to the quality of our work and we can provide contact information. After Langley, Science Tools continued to develop and enhance our product suite addressing the needs of the broader scientific enterprise. Once a commercial version was available, word-of-mouth advertising brought many inquiries and after Richard McGinnis' quote, "It does everything Richard said it would do," the company was very busy. One high-visibility example was the implementation of The BigSur System™ at the Jet Propulsion Laboratory in Pasadena, California. By the time this project began, there had been three further 1.x versions, and during our work with JPL, in January, 2000, we released version 2.0, which supported Solaris, Irix, NT (in limited form), Informix IUS and UDO, and Java versions 1.0, or 1.1, but which also had a greatly expanded, much easier to use API. In fact, we renamed the main library "DESDB", the leading D standing for Distributed because the library now contained all the "distribution" functions (which were formerly in the DPS Daemons). We are sensitive to the needs of our clients and have continuously added significant, sophisticated enhancements. For example, we added a very sophisticated, highly granular security, privilege and permission system specifically at the request of the Alaska Satellite Facility, Geophysical Institute's Synthetic Aperature Radar Data Center (ASF SDC). They indicated that by contract with some of the satellite owners whose data streams they manage, they could not legally trust their computer operators, so they requested we make this easier for them. In response, we added a robust, extensible security system in which individuals can be granted or revoked rights to perform any action against any object / component, complete with defaults and sensible, easy to understand controls. While we were busy making changes at customer request, we also worked to relieve as many dependencies as possible. Version 2.0 was a second complete rewrite as a new architecture was needed to make the product more versatile. The biggest differences introduced in version 2 included a substantial update to the database design - no newer version would be backwards compatible, hence the new major version number. Changing Markets and Continuing DevelopmentAt the time of the founding of the company, Earth Science was reasonably well funded and Science Tools did rather well, but as a new administration entered in 2000, Earth Science funding dropped dramatically. We saw the handwriting on the wall with Bush's first budget request, and reacted by updating our products toward medical-related applications as it's clearly a great fit. February,
2001, saw the advent of Version 2.1, which introduced a protective
program called "STJC" that strongly enhances security by
preventing any calls to the Java API that don't happen from a completely
secured environment. It also included support for Windows platforms,
a unified configuration file, remote management of distributed processes,
global (distributed processing system wide) variables, a unified logging
system, and the beginnings of complete removal of database vendor
dependencies. We made a deal with Scopeland to build ScienceMaster,
a BigSur management application as the earlier "Visionary"
product was withdrawn from the market and no longer available to us.
We changed the API's name from "ESDB" - Earth Science DataBase
to the more generic, "STDB" - Science Tools DataBase. More important than these product developments, we began to add features to address the life-sciences market. In 2000 we began adding support for "MedDb" - a medical database option for BigSur - and support for dicom images (medical images) to be handled "natively." However, as we were progressing with our transition away from earth science, the "Tech Bubble" burst. One might not expect that it would affect earth science business, but it did, especially after September, 2001 which happened a bit later. Pressing forward, BigSur version 3.0 was first released in late September, 2001, while the nation was still in shock. We decided on a new major version number because of another significant change to the database design which also coincided with a large number of new features. As just one important example, V 3.0 introduced full database independence (initially supporting both Informix and Sybase, and later including Oracle, DB2, Postgres, and most any other RDBMS). This was accomplished by the implementation of an SQL dialect translator as an integral part of BigSur. With it you can pass any valid SQL written in any supported dialect to any other supported database type and expect it to work without error - the only things that fail are calls to vendor-unique features. June, 2003 saw the advent of ScienceMaster as a Java application that we own following the failure of Scopeland. Leading up to this release, the API exploded in size and sophistication, growing by well over 300%. This was largely due to the clean nature of the architecture and how a critical mass had been attained in the underlying functions (methods), enabling very fast development yet retaining high quality. The system now supported local cache management for objects, full remote daemon control and a very large number of sophisticated features, such as "publishing". Also included is robust database error handling so that no application code has to worry about a lost database connection, or any form of re-try as that's all now automated in BigSur. At this point the company was now 6 years old and our customers and prospects weren't shy about asking for specific features. In following our Road-Map for the BigSur product, the time came to make the last major change in preparation for the shift to a client-server architecture - this moment came on the day before Christmas, 2006. This marked the end of development of 3.0 (with 3.0.42) and the beginning of 3.1, which was completed and entered testing on July 8, 2007, (a handful of days after Science Tools' tenth birthday), and with first customer ship on September 21. This was a very significant change because it required an update to all extant applications in order to perform an upgrade; that requirement shall (hopefully) never happen again. The End of an Era and New BeginningsFrom the last year of Clinton to the last year of Bush, including the devaluation of the US dollar, Earth Science suffered almost exactly a 50% drop in funding from the US Federal Government - by far the largest funder of Earth Science in the world. And with that drop, Science Tools fortunes dropped too. With the tech sector severely wounded after 2000, and the earth science market shrinking to half its former size, as a small player in a market dominated by very large (mostly military-related) corporations, Science Tools revenue dropped precariously. Some drug discovery companies found Science Tools but in large part because none of these companies would agree to a public relationship, Science Tools was unable to make a clean transition to this new market, and without the capital necessary to advertise properly in this market niche, in 2008 the company folded. The assets were sold for debt relief; the new holders of the assets created a new Science Tools Corporation and worked out an arrangement to retain the former company's founder, Chief Scientist and lead programmer: Richard Troy. The company has a new focus, The Life Sciences, and had been working mostly in the area of moving medical research to clinical settings. Continuing ForwardIn the summer of 2008, Science Tools found a partner (licensee) which in September secured $20M in venture financing to go after a medical science based marketplace, but in the following few weeks, the financial markets around the world collapsed and along with it, the partner's capital. The new Science Tools organization retains an interest in investing in product development, so the primary product, The BigSur System™ has enjoyed continued development. Release 3.2 came out on January 1, 2009, only about 6 months following the transition of ownership. We are committed to keeping to the original RoadMap. To help expand application opportunities for The BigSur System™, a new effort adding many tens of thousands of lines of code was initiated in the first half of 2012 oriented toward creating an interface for non-Java-based web-based applications to access the BigSur Java API™ in a more efficient manner than just using stand-alone calls to Java (as would typically be done by applications such as PHP). This effort is on-going and will preceed a subsequent push for a full-blown client-server implementation in upcoming release 4.0. Our Mission:
Our Philosophy:
Some Viewpoints:
|
|||||
| Feedback |
website contact: Webmistress |