Proposed Thredds Architecture Changes for OSGI/JigSaw

This post provides some preliminary ideas on the consequences of moving TDS to use OSGI or JigSaw


  1. OSGI and Jigsaw will be sufficiently similar so that this proposal with work with either with some tweeks.
  2. Initial target is Thredds server
  3. We will want to dynamically load at least the following kinds of things on the server.
    • OSPs (e.g. netcdf4, grib, etc)
    • RAFs (e.g. S3 and HDFS)
    • Services (e.g. DAP4) I will refer to these all generically as "bundles" (OSGI terminology)

The loading process could be either:

  1. lazy - load only when actually requested
  2. eager- load at startup to provide a specifically configured TDS starting with a skeleton TDS.

For the eager case, we can assume that some config file (e.g. ThreddsConfig.xml) contains the information needed to dynamically extend the tds to make various bundles available.

For the lazy case, it must be possible to create a "signal" that some bundle is needed and must be preloaded. I can see two obvious ways to do this.

  1. Stubs -- we provide stub classes for all the bundles so that calling the stub API the first time causes the bundle to be loaded and then used from then on.
  2. Explicit -- any user of a bundle must explicitly invoke some code to load the required bundle.

My current inclination is to use the eager approach since it is simpler and still allows us to keep a small footprint .war file.

Another question is: where are the bundles stored? I assume they are not kept in the .war file since that would defeat one of the purposes of using dynamic loading. I presume there would be some default repository(s) plus a configurable set of additional repositories from which bundles can be pulled. It may be that NEXUS is usable for this purpose.

A note on IOSPs. Currently the IOSP to use is determined by calling a method that looks at a RAF wrapping a file. This method decides if itcan process that associated file. If we were to use lazy loading, it is probable that for IOSP's we would need to divide the IOSP into two parts: one for testing applicability and one for processing. This is an argument for using eager loading.

New TDS Cloud Architectures: Proposal 1

The Thredds Data server (TDS) was designed to operate in a client-server architecture. Recently, Unidata has moved TDS into the cloud using its existing architecture.

There seems to be agreement inside Unidata that we need to begin rethinking that architecture to adapt to the realities of the cloud.

[Read More]

Upload and Download Support for TDS

For version 5.0.0, it is possible to configure TDS to support the uploading and downloading of files into the local file system using the "/thredds/download" url path. This is primarily intended to support local File materialization for server-side computing. The idea is that a component such asJupyter can materialize files from TDS to make them available to code being run in Jupyter. Additionally, any final output from the code execution can be uploaded to a specific location in the TDS catalog to make it available externally.

[Read More]

THREDDS and Java 8 plans

THREDDS development is now switching to version 5.0 which will require Java 8. Version 5 is a major upgrade and some of the APIs will change. Deprecated classes will be moved to a legacy jar and will not be supported. If you are a developer, you will need to test the new version against your code. We expect to have an alpha release out by July for that purpose.
[Read More]

A Mobile App for Radar Data

During my internship last year with Unidata, I developed an Android version of a netCDF Subset Service form. Coming back this year, I wanted to expand my endeavors in mobile development by writing an application that works on all mobile platforms. To do this, I decided to use Apache Cordova because it takes a JavaScript/HTML file and packages it as a native application for any mobile platform. The product of choice this year was Unidata's radar data as it seemed to be a product well suited for mobile users.

[Read More]
Unidata Developer's Blog
A weblog about software development by Unidata developers*
Unidata Developer's Blog
A weblog about software development by Unidata developers*



News@Unidata blog

Take a poll!

What if we had an ongoing user poll in here?

Browse By Topic
  • feed AWIPS II (13)
Browse by Topic
« May 2017