vADC Docs

Feature Brief: Java Extensions in Stingray Traffic Manager

by on ‎02-28-2013 02:38 AM - edited on ‎06-16-2015 10:06 AM by PaulWallace (3,638 Views)

In situations where TrafficScript does not provide the necessary functionality, you may wish to turn to a  general-purpose language.  In this case, TrafficScript can call out to a locally-installed JVM (Java Virtual Machine) and invoke a ‘Java Extension’ to perform the necessary processing:

 

java1.png

This allows you to run code written in a variety of languages (Python and Ruby can target the JVM as well as Java), and to use third-party libraries to provide functionality that would be difficult to code up in TrafficScript.

 

For example, you can use a Java Extension and the relevant class libraries to inspect image and pdf data ‘on-the-wire’ and apply watermarks or stenography to secure the data and trace unauthorized redistribution.  Java Extensions provide a means to interface with third-party systems that are not natively supported by TrafficScript, such as a MySQL or Oracle databases, or an XML-RPC server.  Finally, they make it easier to accumulate data outside of the regular request/response event model and act on that data asynchronously.

 

How do Java Extensions function?

 

Stingray Java Extensions use an extended version of the standard Java Servlet API that adds implementations of significant TrafficScript control functions and allows a chain of Java Extensions to process requests and responses. 

 

A Java Extension is loaded into the local JVM on demand (the first time java.run( 'ExtensionName' ) is invoked).  Stingray passes the basic request (and response) data to the extension and then invokes the servlet 'service' or 'doGet' method in the extension.  The extension runs to completion and then control is handed back to the TrafficScript rule that invoked it.

 

Java Extensions run in a dedicated Java Virtual Machine (JVM), on the same server system as the core Stingray traffic management software. The JVM isolates the Java Extensions from the Stingary kernel, so that extensions can safely perform operations such as database access without blocking or unduly interfering with the Stingray kernel.  The Java Extensions engine can run multiple extensions concurrently (subject to a global limit), and extensions can build up and store persistent data, spawn threads for background processing tasks and perform all manner of blocking operations, subject to configured connection timeouts. The engine supports remote debugging and hot code patching so that running extensions can be debugged and updated on-the-fly.

 

Java Extensions may be used against HTTP and non-HTTP traffic, and may also be used to implement additional functions that can be called from TrafficScript.  Extensions can be written in Java, Python or Ruby.

 

What can you do with Java Extensions?

 

Java Extensions let you draw on the capabilities of Java, the functionality of the JRE and the huge variety of supporting Java class libraries. You can perform detailed content inspection and modification, communicate with external databases, applications and services, and implement very sophisticated application delivery logic.

 

Possible applications include:

 

  • Content Watermarking - protect intellectual property by applying unique visible or hidden watermarks to outgoing documents or images;
  • Authentication, Authorization and Access Control - checking user credentials against an LDAP, Radius, TACACS+, Active Directory or other database and applying access control;
  • Proxying multiple applications behind a single-sign-on gateway, using Java Extensions to create the necessary the logic to broker, authenticate and translate requests between remote clients and the different back-end applications and services;
  • Application Mash-ups, built from multiple different sources. Java Extensions can even communicate with raw sockets to interface with proprietary applications;
  • XML Signature Verification and Generation - verify and strip signatures from incoming XML data, or replace signatures with locally generated ones to indicate that a document has passed initial checking at the gateway;
  • Transaction logging and alerting, logging key events to a remote database or raising an alert, reconfiguring Stingray via the Control API or performing other custom actions as appropriate;
  • Complex Request Routing based on location data, URL hash values or real-time information retrieved from an external database or service.

 

Examples

 

 

Read More

 

Contributors