Recently I’ve been digging into the Watson Conversation APIs. With Java being my language of choice, the natural starting point was the Watson Brewery demo which integrates with Watson Workspace. This in itself was a learning experience as I finally stepped beyond the world of Eclipse to use IntellJ IDEA, as mentioned in the ReadMe. It can run in Eclipse, although there are different steps for adding Project Lombok to Eclipse. But as I didn’t know anything about Project Lombok at the time, the easiest approach was following the steps exactly – and they do need to be followed exactly. IntelliJ is certainly different to Eclipse and there are various blog posts explaining why you might choose one vs the other. On more than one occasion I found myself watching video introductions to get to grips with the basics. Project Lombok is very powerful as a development tool for coding without getters and setters and letting Project Lombok generate the require class files for you. In ODA we’ve been working with Tinkerpop for a while and between the version we’re using and the next version, Frames were removed. Frames allow you to write interfaces without getter or setter code. I never understood why you would drop that and require much more verbosity and coding setup, but Project Lombok would remove that need, so it finally makes sense. It’s probably a bit late for us to use that for the Watson Work Services Java SDK, but Project Lombok is definitely something I will consider for future Java projects and something work looking at.
I had to make a tweak to get the code working. It looked like there was an error in WatsonWorkController 87. The code looking to prompt a search for breweries returned “Local_Breweries” as the payload.actionId(), I couldn’t see that it could ever match the payload.getTargetDialogId(). Once I made the change it worked.
That covered Watson Conversation integrating with Watson Workspace, but what about XPages? First step, XPages is Java, look at integrating just with Java. This blog post covers using a “car dashboard” sample conversation which is a demo workspace (within Watson Conversation, nothing to do with Watson Workspace the product) you can add to a new Conversation service. The blog post runs from your IDE, but shows the ability to interact with the Watson Conversation service.
The next step was to crerate my own Conversation service workspace and connect to that. The code for that Java application is taking input, posting to Watson Conversation, then outputting the responses. Within the MessageResponse object, it has access to the context, a Map of key/value pairs that persist for the session of the conversation. This context gets passed to Watson with the MessageRequest. After spending some time working with REST services, the whole concept of Request and Response is very straightforward, the basic underpinning of any HTTP communication. The context is how our Java application can know when it needs to interact with a database or how our Java application can pass data from our database to the Watson Conversation service to be integrated into a response or trigger a particular conversation node. We now have the basics for how to integrate an application and the Watson Conversation service.
We also have the core Java code needed in the business logic of an XPages application. We just need two things: the relevant jar files which are incorporated into the Java application by the beautiful simplicity (outside of OSGi, that is!) of Maven or gradle; and any relevant changes to the Java security policy. Wouldn’t it be great to just have that somewhere?
At the same time there were announcements from developerWorks of a SalesForce SDK for the Watson Developer Cloud. Knowing a little about SalesForce, this isn’t just a case of dropping jar files because SalesForce’s backend language is Apex, albeit similar to Java. We’In the Domino world we’ve suffered for many years with criticism of the quirky proprietariness of LotusScript. XPages brought standardisation, and the ability to use Java in XPages code means incorporating third-party libraries is very easy. In a few hours (I struggled to make the classes visible initially, not sure what I was doing wrong, but it was obviously something basic!) I had a Mavenized XPages library built from the OpenNTF Domino API Starter Servlet which pulled down the Watson Developer Cloud jar files and all dependencies, added them to the build path and classpath and packages everything up in an update site. Automatically. New version of Watson Developer Cloud? All I’ll need to do is increment versions in pom.xml, choose any new Java classes to be exported, add any new Java packages to automatically package them within the plugin, and it’s good to go.
There are some amendments required to the Java security policy – I expected that to be the case. But those are documented. And the good news is this is not just the Watson Conversation service. It’s all of the Watson Developer Cloud Java SDK. And it’s now on OpenNTF. Obviously I’m not in a position to have tested all parts of the SDK, so there might be additional tweaks to make to the Java security policy. But those would be minor and if you come across any, let me know so I can update the documentation.
In terms of samples, I would point people towards the Java samples on developerWorks, like the Watson Conversation blog post I mentioned before. There’s nothing specific in the XPages Library. And if you’re looking to start integrating with third-party stuff beyond Domino from XPages, I believe it’s really time to start trying Java and move beyond SSJS.
