Friday Apr 11, 2014

Friday Spotlight: Writing a Broker for Oracle Secure Global Desktop

We talked about the dynamic launch feature in Oracle Secure Global Desktop earlier and pointed out that the code providing the functionality is implemented in a broker.  Here, we'll look at the fundamentals of writing a broker before working through a scenario where a bespoke broker would simplify operations.

Broker Basics

The interfaces and classes you need to write a broker are in the com.tarantella.tta.webservices.vsbim package in the sgd-webservices.jar archive. 

IVirtualServerBroker is the key interface and all Secure Global Desktop brokers must implement it.  These are the methods where a broker writer would typically add logic.

void initialise(Map initParams) This method is called once when the broker is loaded by the Secure Global Desktop workspace.  It gives the broker a map of the key/value pairs configured on the dynamic application server object using the broker.  Typical parameters would be the name and port of a source of real or virtual application servers.
Map getCandidateServers(Map params) Secure Global Desktop calls this method to obtain a list of servers available to a particular user.  The broker receives a map of parameters, including the identity of the user, and the broker returns a list of candidate servers.  The broker writer is free to decide how to populate that list and whether to return one candidate or several.  For example, the broker could contact a database to reserve a single server.  Alternatively, it could use APIs or web services to contact a VM provider and get a list of available virtual machines.
ICandidateServer prepareCandidate(String type, ICandidateServer candidate) This method is called after getCandidateServers returns a single option or the user has selected one from several.  This is the place for any code needed to set-up the chosen server or virtual machine.
void destroy() This is where the broker would tidy-up, freeing any resources it had used, like sessions and connections.

A Sample Broker

Let's look at a scenario where writing a broker could simplify operations.  You are an administrator of a Secure Global Desktop deployment where users periodically need to access a key application.  Only a single instance of the application can run on any one server and you have a limited number of licenses.  When a user requires access to the application, they submit a service request to reserve one.  The traditional, broker-less approach in Secure Global Desktop would be to create an application object, configure it to run on the reserved application server and then assign it to the user who reserved it.  Time-consuming if you have to do this repeatedly and on a regular basis.

However, if we can access the reservation database, we can do it dynamically in a broker.  The operation now becomes:

  • Once only, the administrator assigns the application a dynamic application server configured with a custom broker

Then,

  • User submits a service request and reserves a server
  • User logs into Secure Global Desktop and clicks the link to launch the application
  • The broker queries the database, gets the server that the user has reserved and launches the application on it

For the administrator, there is no need to create, modify or destroy objects in the Secure Global Desktop datastore every time a user submits a service request.

Skipping many details, defensive coding and exception handling, the broker code would look something like this:

package com.mycompany.mypackage;

import com.tarantella.tta.webservices.vsbim.*;
import java.sql.*;
import java.util.*;

public class DbBroker implements IVirtualServerBroker {

    static private final String TYPE = "A Description";
    private Connection dbConn;

    public void initialise(Map<String, String> parameters)
            throws VirtualServerBrokerException {
        // Connect to reservation database.  End-point and credentials are
        // supplied in the parameters from the dynamic application server
        dbConn = DriverManager.getConnection(params.get("URL"), params.get("USER", params.get("PASS"));
    }

    public Map<String, List<ICandidateServer>> getCandidateServers(
            Map<String, String> parameters)
            throws VirtualServerBrokerAuthException,
                   VirtualServerBrokerException {
        Map<String, List<ICandidateServer>> launchCandidates =
                new HashMap<String, List<ICandidateServer>>();

        // Get the user identity
        String identity = parameters.get(SGD_IDENTITY);

        // Lookup the application server for that user from the database
        Statement statement = dbConn.createStatement();
        String query = createQuery(identity);
        ResultSet results = statement.executeQuery(query);
        // Parse results;
        String appServerName = parseResults(results);

        if (appServerName != null) {
            // Create the assigned server.
            CandidateServer lc = new CandidateServer(appServerName);
            lc.setType(TYPE);

            List<ICandidateServer> lcList = new ArrayList<ICandidateServer>();
            lcList.add(lc);
            launchCandidates.put(TYPE, lcList);
        }

        return launchCandidates;
    }

    public ICandidateServer prepareCandidate(String type,
            ICandidateServer candidate)
            throws VirtualServerBrokerException {
        // Nothing to do
        return candidate;
    }


    public void destroy() {
        // Close the connection to the database
        dbConn.close();
    }

    // And the other methods
    public boolean isAuthenticationRequired() {
        // No user authentication needed
        return false;
    }

    public Scope getScope() {
        // Scope at the application level for all users.
        return Scope.APPLICATION;
    }
}

In summary, dynamic launch and custom brokers can simplify an administrator's life when operating in a dynamic environment.  The broker can get its data from any source with a suitable interface: a database, a web server or VM providers with open APIs.  Next time, we'll illustrate that with a broker connecting to Virtual Box.


Friday Apr 04, 2014

Dynamic Launch in Oracle Secure Global Desktop

In an earlier entry, Oracle Secure Global Desktop and Oracle VDI, we mentioned the dynamic launch feature in Secure Global Desktop and described how we used that feature to connect the two products.  Here's a summary of that integration:

SGD and VDI

Now is a good time to dig a bit deeper into dynamic launch.

Dynamic Launch

There are three parts to it:

  • Dynamic Applications
  • Dynamic Application Servers
  • Brokers

Dynamic Applications

A dynamic application is a type of object in Secure Global Desktop that maps to one or more other applications and offers a user a choice between those applications.  Normally, you would map related applications, like a workflow, or alternatives, where you would expect a user to run only one of the applications at any one time.  'My Desktop' is an example of the latter: it is a dynamic application that maps to a Unix desktop and a Windows desktop, the thinking being that most users would run one or the other, but not both simultaneously.

Dynamic Application Servers

A dynamic application server is an object that tells Secure Global Desktop to execute some code to determine where an application should run.  It can be assigned to an application object just like other application servers and the code is executed when the application is launched.  The code is delivered as a broker.

Brokers

A broker is a Java class that implements a simple interface and is a property of a dynamic application server.  Currently, Secure Global Desktop ships with three brokers:

  • SGD Broker: when this is assigned to an application object, it grabs all the other (real) application servers assigned to the application and presents the user with a choice
  • User-defined SGD Broker: an extension of the SGD Broker that adds the option for a user to enter a host name
  • VDI Broker: this is used to provision hosts through VDI

Together, they provide a structured, flexible and extensible system: a single dynamic application in a user's workspace can open up a wealth of choices.  Let's consider a scenario where a user needs to run a range of web applications that require different browser types and versions.  One solution in Secure Global Desktop would be to create separate items for each type of browser and publish them to the workspace.  Alternatively, you could create a dynamic application that maps to the different types of browser and logically group them together.  And this can be taken a step further: by assigning a dynamic application server to an application, that browser could be run on a server dynamically provisioned through VDI or whatever hypervisor the broker has been written to handle.

Dynamic Launch

So, three key components make up dynamic launch.  Two of them, dynamic applications and dynamic application servers, are part of the Secure Global Desktop infrastructure and plumb the feature into the datastore, workspace and launch process.  They belong in the administrator's realm.  The third component, the broker, provides extensibility.  Secure Global Desktop ships with a broker to deliver VMs provisioned through Oracle VDI, but the open interfaces mean it does not have to stop there. To go further, we must enter the developer's world and write a little code.  Next time...


About

Get the latest scoop on products, strategy, events, news, and more, from Oracle's virtualization experts

Twitter

Facebook

Search

Archives
« April 2014 »
SunMonTueWedThuFriSat
  
1
5
6
7
8
9
10
12
13
14
15
16
17
19
20
21
22
23
26
27
30
   
       
Today