February 17, 2012
A brief celebratory posting, something worked seamlessly and I now need to go away and think about the implications.
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
Then a definition of the adapter in an XML file
<loadConstraints maxConcurrentConnectionsPerNode="5" />
</connectivity> <procedure name="getAccountTransactions1"/>
var getAccountsTransactionsStatement = WL.Server.createSQLStatement(
"SELECT transactionId, fromAccount, toAccount, transactionDate, transactionAmount, transactionType " +
"FROM accounttransactions " +
"WHERE accounttransactions.fromAccount = ? OR accounttransactions.toAccount = ? " +
"ORDER BY transactionDate DESC " +
//Invoke prepared SQL query and return invocation result
preparedStatement : getAccountsTransactionsStatement,
parameters : [accountId, accountId]
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.
"transactionType": "Funds Transfer"
"transactionType": "ATM Withdrawal"
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:
- 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.