The simplest way to communicate with the KIE Workbench is through the REST interface. A group of REST service classes expose a series of URLs to access different runtime engines inside the KIE Workbench. The following table shows some of the URLs:

The most important URL exposed is probably the "execute" URL: /rest/runtime/{deployment-id}/execute. Through this URL, using the command pattern, every single function in the KIE session and the task service can be implemented using the same API. This is the one used by the implementation at the kie-services-client dependency to expose the RemoteRuntimeEngine class. The following code snippet shows how to build a REST remote runtime engine:

RuntimeEngine engine = RemoteRestRuntimeEngineFactoryBuilderImpl.
    newBuilder().addUrl(new URL("http://localhost:8080/kie-wb")).
    addDeploymentId("org.jbpm:HR:1.0").addUserName("mariano").
    addPassword("mypass").build().newRuntimeEngine();

You can see that we are passing four elements to the RemoteRestRuntimeEngineFactoryBuidlerImpl class: a URL for the KIE Workbench, a release ID for identifying a runtime manager, and a username and a password to log in to the application and pass credentials to what I will do on top of the created RuntimeEngine.

Once the RuntimeEngine object is created, we can use it as any other RuntimeEngine we built in our local environment. Internally, it will create commands for every method invoked in the KIE session and task service, serialize them into XML, and send them through the execute URL.

You can find an example in the remote-invocations project, in the SignalEventAppREST class. You can run it directly from the remote-invocations path by typing the following command:

mvn -Prest

Another way of accessing the KIE Workbench runtime engines is through the JMS implementations. It uses a set of queues to send serialized versions of the command objects for task service and KIE session method executions. These commands, whether they are sent to the task service or the KIE session, are sent through two different queues: jms/queue/KIE.TASK or jms/queue/KIE.SESSION queues, respectively. Responses are handled through the jms/queue/KIE.RESPONSE queue.

These are the default configurations in the KIE Workbench application, but they can be changed in the bpms-jms.xml file under the WEB-INF/ folder of the KIE Workbench.

There is another queue we haven't mentioned because, for the moment, it is not managed by the RemoteRuntimeEngine interface. This queue is the audit queue. It manages requests for the AuditLogService interface, to access the history logs from outside applications.

In order to create code that could manage messages for the first three queues in a standard way, we must create the runtime engine through the provided API, as shown in the following code snippet:

InitialContext ctx = new InitialContext();
QueueConnectionFactory connFactory = (QueueConnectionFactory) 
    ctx.lookup("jms/RemoteConnectionFactory");
Connection conn = connFactory.createConnection(
    "mariano", "mypass");
Session session = conn.createSession(true, 
    Session.AUTO_ACKNOWLEDGE);
Queue ksQueue = (Queue) ctx.lookup("jms/queue/KIE.SESSION");
Queue taskQueue = (Queue) ctx.lookup("jms/queue/KIE.TASK");
Queue respQueue = (Queue) ctx.lookup("jms/queue/KIE.RESPONSE");
RuntimeEngine engine = RemoteJmsRuntimeEngineFactoryBuilderImpl.
    newBuilder().addDeploymentId("org.jbpm:HR:1.0").
    addConnectionFactory(connFactory).addKieSessionQueue(ksQueue).
    addTaskServiceQueue(taskQueue).addResponseQueue(respQueue).
    addUserName("mariano").addPassword("mypass").
    build().newRuntimeEngine();

The preceding code snippet does a lot more configuration, mainly to access all the JMS components needed. We first need to connect to an initial context to gain access to our JMS ConnectionFactory and Queues, and then we pass those to the factory along with a release ID, a username, and a password.

There is an example provided in the SignalEventAppJMS class of the remote-invocations project. You can run it directly from the remote-invocations path by typing the following command:

mvn –Pjms