Modular & Extensible

Joval's clean, modular design allows you to add your own plugins, adapters, and providers to expand or override test support, platform support, data collection mechanisms and more.

Joval’s Architecture

Designed for Innovation

Joval not only features market-leading support for the SCAP family of specifications, we have also proposed several new schemas and dozens of new object types that have been accepted into the OVAL language specification. How is it possible for a relative newcomer to this space to not just develop comprehensive support, but also innovate and expand platform coverage so prolifically? The answer is that Joval was designed from the very beginning with a modular, pluggable, performance-oriented architecture. This architecture makes it possible for our team to rapidly add high-performance support for new schema objects, and to rapidly roll out support for entirely new OVAL schemas, in both our host-based agent and remote-scanning product components.

An architecture with modularity across multiple dimensions at the code level is not something that can be bolted on to a tired, decade-old code base; it is something that must be planned, even before the foundation is being laid. Only Joval customers can leverage the advantages inherent to our product’s design, either by using our SDK directly, or indirectly through our end-user products.

Three Virtual Tiers

At its heart, Joval operates on three layers for managing the process of scanning target machines

  1. jSAF: connection to target & raw data collection

    At the bottom layer, there is a jSAF ISession that manages the connection to a target.

  2. Plugins & Adapters: test support

    On top of this, there is a Joval IPlugin that references the ISession, and maintains a registry of schema object IAdapter classes. These adapters are responsible for using the session to extract information from the target machine, and potentially also, caching that information for future use.

  3. SCAP Language Engines: core language feature & format support

    Finally at the top layer, there are engines for processing OVAL and SCAP Datastream XML documents (IOvalEngine and IXccdfEngine, respectively), which reference their own IPlugin instances.

This three-layer pluggable architecture makes it possible to create a single object adapter to support both host-based and remote collection. It also lets us isolate the collection logic for schema objects completely outside the core document processing engine. Since our engine is schema-driven, adding support for new schemas almost trivial. We simply generate a data model from the schema, write the object adapters, register the model objects with the engine and register the adapters with the plugin — at runtime.

Extensibility Points

Custom Joval Plugins

In some cases it is desirable to create a custom plug-in for Joval. For example, your application may store some information about target machines in a database, and you may want to retrieve that information if possible from the database instead of the target machine. In such cases, customers can create their own IPlugin implementations. Such implementations can inspect each object collection request made by the engine, and then either retrieve the information themselves, or delegate the collection to a wrapped Joval plugin instance.

Custom OVAL Schemas

Somtimes, customers want the ability to perform compliance assessments on information that is not exposed by any existing OVAL test. (Such has been the basis for the many tests we’ve proposed, which have been added to the OVAL language specification over the years!).

Since it can take (at worst) years before a new test is officially adopted by the OVAL community, we believe it’s important for our engine to be easily extended to support new types, and we’ve created a framework we support that makes it possible for customers to do this with our product.

View Extensions on GitHub

Custom jSAF Providers

Joval uses the abstract system interface defined by jSAF, to make it possible for an object adapter to function in multiple contexts (e.g., local, remote and offline scanning). In rare cases, a customer will want to define their own jSAF provider.

For example, in a simple case, if a customer has a database containing configuration data about routers and/or mobile devices, that customer might want to create their own ‘offline’ provider that would source information from that database. In a more complex example, a customer might already have their own native agent software distributed throughout the environment, and would want to leverage that as a mechanism for data collection. Both of these use-cases can be accommodated if the customer is willing to author their own provider implementation of the relevant jSAF interfaces.

3rd-Party Dependencies

Joval’s codebase is meticulously curated. We own the copyright for the majority of the code. All 3rd-party dependencies are redistributable using commercially-friendly terms (e.g., BSD, MIT and Apache licenses). Full documentation of 3rd-party dependencies and their associated licenses is available upon request.