Welcome!

Java Authors: Pat Romanski, Stephen Pierzchala, Elizabeth White, Jason Bloomberg, Sebastian Kruk

Blog Feed Post

Extending the Axway/Vordel API Server with third-party Java classes using scripting

One of the neat features of the Axway/Vordel API Server is the fact that you can extend it using Java. There are a number of ways of doing this, but a really neat way is to run your Java class through a Scripting Filter. Here is a guide to calling your own, or third-pary, Java classes from the Axway/Vordel API Server.

My use case is that I want to use OpenID for single-sign-on using a Google login. I found a nice implementation of OpenID called JOpenID and downloaded it as a jar file. I then placed the JOpenId-1.08.jar file into the /ext/lib folder of my API Server installation. I then placed this new class under /ext/lib on the API Server also, so that it will be picked up by the API Server runtime. Note that, for v7 onward, this must be placed under the /ext/lib instance you want to extend. You can find the correct instance by following the "groups" then "topologylinks" path under the API Server installation. This effectively puts it onto the classpath for that API Server instance.

JOpenID includes a class called OpenIdManager which has a method called getAuthenticationUrl that constructs the URL which directs the user to Google for SSO to a particular endpoint. I want to call that method from the API Server. However, from a Scripting Filter, I can only run a public static method of a class.

So, what I did was to make a class called "OpenIDEngine", and I gave it a public static method called "GetURL". In that method, I create an instance of OpenIdManager and I call OpenIdManager.getAuthenticationUrl to get the URL for me. This is what I will call from my Scripting Filter.

Here's the code I wrote:


package org.expressme.openid;

public class OpenIDEngine {

    public static void main(String[] args) throws Exception {
        System.out.println(GetURL("http://vordelapiserver/openId","http://vordelapiserver", "Google"));
    }
    
    public static String GetURL(String ReturnTo, String Realm, String Endpoint)
    {
        OpenIdManager manager = new OpenIdManager();
        manager.setReturnTo(ReturnTo);
        manager.setRealm(Realm);
        manager.setTimeOut(10000);
        Endpoint endpoint = manager.lookupEndpoint(Endpoint);
        Association association = manager.lookupAssociation(endpoint);
        String url = manager.getAuthenticationUrl(endpoint, association);
        return url;
    }
}

You can see I also added a main method to my class for testing purposes.

After compiling this, I then placed this new class under /ext/lib on the API Server also, so that it will be picked up by the API Server runtime. Note that, for v7 onward, this must be placed under the /ext/lib instance you want to extend. You can find the correct instance by following the "groups" then "topologylinks" path under the API Server installation. Ensure you jar it up, or put it into the correct folder structure so that it gets picked up.

The next step is to use a Scripting Filter to run the GetURL method of my class. Here's a screenshot of my Scripting Filter being used in my policy:


In case you can't see the contents of the script, here it is below. I'm putting in the Java package at the top (note the Rhino syntax) and then running my method. I'm placing the output (i.e. the URL) into an attribute (variable) called "OpenIDUrl". I'm then using a simple Set Message in the following filter to output this variable.

importPackage(Packages.org.expressme.openid);


function invoke(msg)        
 {           

 msg.put("OpenIDUrl",org.expressme.openid.OpenIDEngine.GetURL("http://APIServer/openId","http://APIServer", "Google"));
 return true;        

 }

Here's the Set Message filter which is outputting that URL:



Now, I wire this policy up to a path called "/GetURL", so that when a request comes into "/GetURL", it is run:


Now, when I call "/GetURL" on the API Server, I see my URL is generated for SSO through Google, and when I hover over the link I can take a look at the URL which is generated:



I hope this explains how to extend the Axway/Vordel API Server using your own (or third-party) Java classes, via the Scripting Filter. The advantage of this approach is that it's very simple to do. Also, you can place all your logic in the Java classes, and simply run it through a call from a Scripting Filter as show here. 

Read the original blog entry...

More Stories By Mark O'Neill

Mark O'Neill is Chief Technology Office of Vordel. Vordel connects applications to applications, businesses to other businesses, and SOA to Cloud Computing. A regular speaker at industry conferences and a contributor to SOA World Magazine and Cloud Computing Journal, Mark holds a degree in mathematics and psychology from Trinity College Dublin and graduate qualifications in neural network programming from Oxford University.