Hi Mauricio,
Thank you for comments and kind words. Please see additional questions / proposals below.
Replies
>> As far as I understood for your email you want to deploy your app in Tomcat...
Actually, our ultimate target is Java EE Web Profile compatible Resin 4 server - I had mentioned Tomcat as an example.
>> I guess that we can find a way to remove the dependency to MDBs if that's what you need, but you will need to solve in some other ways the features provided by such components.
Yes, would be great to have such a dependency either removed or optional.
In terms of using the "KIE Remote Services :: Client" (...\droolsjbpm-integration\kie-remote\kie-services-client\pom.xml).
To use the full Human Task Service API (HTS API) we currently need to use "org.kie.services.client.serialization.jaxb.JaxbCommandsRequest" as a medium to transfer Human Tasks related commands in field "org.kie.services.client.serialization.jaxb.JaxbCommandsRequest#commands". Even if we use the REST API, we end up calling "org.kie.services.remote.rest.TaskResource#execute" with its "JaxbCommandsRequest" parameter.
Yes, there are convenience, "light" RESTful methods in "org.kie.services.remote.rest.TaskResource", namely
- query(...)
- getTaskInstanceInfo(...)
- doTaskOperation(...)
However, they do not cover the full HTS API. Thus, at our client side we need all dependencies of the commands. The amount of dependencies is really huge - by and large, this should be ok for the case when jBPM core modules are clients of HTS, but in our integration case or cases when one say wants to implement an alternative "managing" component for HTS, the dependencies look really excessive.
When one wants to remotely send such an "HTS command", say "org.jbpm.services.task.commands.AddTaskCommand", he needs all dependencies of corresponding "execute()" method (for example take a look at "org.jbpm.services.task.commands.AddTaskCommand#execute()"), which, frankly speaking, looks completely redundant at client side.
As an experiment, we have tried to "manually" extract all classes / interfaces needed solely for a JaxbCommandsRequest-based client jar (artifact), copy&pasting all subclasses of "org.jbpm.services.task.commands.TaskCommand" with replaced as following "execute()" method body:
public Void execute(...) {
throw new UnsupportedOperationException("Client VO implementation.");
}
This led to two relatively light JARs:
- extracted-kie-services-client-1.0-SNAPSHOT.jar (147 KB)
- hibernate-jpa-2.0-api-1.0.1.Final.jar (101 KB)
which can be conveniently used at client sides other than other jBPM modules. You are welcome to find the "extracted-kie-services-client" Maven project attached.
https://dl.dropboxusercontent.com/u/32989899/extracted-kie-services-client.zip
Taking the above information into account, can you please answer following questions?
1) Are we right that service "org.kie.services.remote.rest.TaskResource" is designed to be auto-deployable via CDI (@RequestScoped) and RESTeasy's JAX RS annotations?
That is, for NO-EJB deployment cases we do not need an analogue of jBPM_5_4's "org.jbpm.task.servlet.HumanTaskServiceServlet" ?
2) Do you think our general approach to using "kie-services-client" is good or bad? Probably we miss something? Ideally we would like to have the jBPM HTS Client development guidelines or even participate in their writing.
Clearly, the hierarchy of server-side-targeted subclasses of "org.jbpm.services.task.commands.TaskCommand" can be complemented with appropriate "lightened" client side VO-counter parts.
In addition, with remoting in mind as a nutural feature of jBPM / HTS, say the following code:
- org.drools.core**
- org.jbpm.services.task**
- org.kie**
can be redesigned to become packagable (via Maven) into following multiple artifacts (3 per 1 logical component) for simplified remoting:
- *server_only_dependencies.jar
- *shared_dependencies.jar
- *client_only_dependencies.jar
Please let us know what you think.
Looking forward to your comments,
Mikhail