Light Work

A brief celebratory posting, something worked seamlessly and I now need to go away and think about the implications.

The context is that IBM recently acquired Worklight, a vendor of software addressing mobile platforms. As my team works in in the mobile space we’re all very interested to see the capabilities of the newly acquired portfolio. Worklight addresses development, infrastructure and the management of mobile applications. The capabilities here complement those of IBM’s existing mobile product set. The development features fit with technologies we currently use: PhoneGap for cross-device portability is key component in the Worklight stack and the dojo JavaScript framework is supported.

Programming model

I started by looking at one aspect of Worklight’s server-side programming model. This allows us to create “Adapters” which are effectively RESTful wrappers of enterprise data, producing JSON data ready for consumption in the client. Out of the box there are adapters for JDBC database access and HTTP services.

The creation of an adapter is remarkably simple. The details are all described in the online tutorials, but I want to give a flavour of the degree of efforts so I’ll summarise here.

First, there is some initial configuration of the server to connect to the data source, in my case that’s a database. So I adjusted the server definition with a few lines of configuration

training-jndi-name=${custom-db.1.jndi-name}
custom-db.1.relative-jndi-name=jdbc/wl_training
custom-db.1.driver=com.mysql.jdbc.Driver
custom-db.1.url=jdbc:mysql://localhost:3306/wl_training
custom-db.1.username=aname
custom-db.1.password=apassword

Then a definition of the adapter in an XML file

<displayName>AccountTransactions</displayName>
    <description>AccountTransactions</description>
    <connectivity>
        <connectionPolicy xsi:type="sql:SQLConnectionPolicy">
            <dataSourceJNDIName>${training-jndi-name}</dataSourceJNDIName>
        </connectionPolicy>
        <loadConstraints maxConcurrentConnectionsPerNode="5" />
    </connectivity>  <procedure name="getAccountTransactions1"/>

And finally the implementation, which comprises the SQL to be executed and a JavaScript wrapper.

var getAccountsTransactionsStatement = WL.Server.createSQLStatement(
    "SELECT transactionId, fromAccount, toAccount, transactionDate, transactionAmount, transactionType " +
    "FROM accounttransactions " +
    "WHERE accounttransactions.fromAccount = ? OR accounttransactions.toAccount = ? " +
    "ORDER BY transactionDate DESC " +
    "LIMIT 20;"
);

//Invoke prepared SQL query and return invocation result   
function getAccountTransactions1(accountId){
    return WL.Server.invokeSQLStatement({
        preparedStatement : getAccountsTransactionsStatement,
        parameters : [accountId, accountId]
    });
}

Just Work

Then I just select

Run As –> Invoke Worklight Procedure

and my code is deployed to the server and invoked. There’s negliable build or deployment time and I see a JSON string displayed.

{
  "isSuccessful": true,
  "resultSet": [
    {
      "fromAccount": "12345",
      "toAccount": "54321",
      "transactionAmount": 180,
      "transactionDate": "2009-03-11T11:08:39.000Z",
      "transactionId": "W06091500863",
      "transactionType": "Funds Transfer"
    },
    {
      "fromAccount": "12345",
      "toAccount": null,
      "transactionAmount": 130,
      "transactionDate": "2009-03-07T11:09:39.000Z",
      "transactionId": "W214122/5337",
      "transactionType": "ATM Withdrawal"
    }, etc.

Now that whole development process took maybe 30 mins, of which at least half was spent stumbling over Windows 7s security controls preventing me from updating the server configuration. I reckon the next query will take no more than 10 minutes to implement.

Conclusions and Open Questions

My previous articles have talked about using JAX/RS and JPA to achieve pretty much the same end result: a RESTful serviice obtaining some data from a database. I was pretty pleased with how easy that was to do, a couple of of hours initially and probably 30 mins for each additional query. Clearly the Worklight story offers significant effort savings. I will be using Worklight for rapid prototyping in future.

Two areas I want to investigate further:

1. How efficient is the programming model? We’re executing JavaScript on the server. Are the overheads significant?
2. What do we do when we are not just reading? Suppose we need transactional updates to different tables or even databases. For sure we can use stored procedures, but I’m uneasy about pushing business logic down to the database layer. Probably I need to use enterprise quality services perhaps implemented as an EJB, but in which case I can trivially expose those using JAX/RS. Do I need Worklight in those transactional scenarios?

So definitely another tool for the toolbox, I just need to figure out its optimal uses, and what other options there may be. Next, onwards to look at other Worklight features such as security and application management.