Hi Mauricio,
>> Nice plans, if you are looking forward to use the jbpm console ng it would be nice if you share your thoughts and
>> ideas about which requirements do you currently have or expect from it. So we can make sure to implement what is expected.
Thank you for the invitation - I'll certainly get back to it on the next iteration, I mean after the "Human Task Service" model integration into our distributed system. Please see further comments below.
>> About the two plans..
>> The plan 1 sounds more appropriate to me, you don't need to mess with the console if you are not using it.
>> The services which are inside the console backend are console specific, if you use the HT module alone you can tweak it for your special use case.
>> You should take a look at our rest integration: https://github.com/droolsjbpm/droolsjbpm-integration/tree/master/kie-remote/kie-services-remote
I've investigated the code. It is really great that we have such an integration layer out-of-the-box. Some related considerations:
(I) The above-mentioned latest "jBPM 6 + jBPM Console NG" bundle is deployable to Tomcat 7 - it handles persistence via org.hibernate.ejb.HibernatePersistence. In the same time, "org.kie.services.remote.jms.RequestMessageBean" from "droolsjbpm-integration" introduces dependency on "javax.ejb.MessageDrivenContext", which makes bundle <<"jBPM 6 + jBPM Console NG" + "kie-remote">> impossible to deploy on a generic "Java EE 6 Web Profile"-compatible system because it supports only "EJB 3.1 Lite" by specification, while MDB-s are not supported by "EJB 3.1 Lite" ( http://www.oracle.com/technetwork/articles/javaee/javaee6overview-part3-139660.html#ejblite )
Wouldn't be it more portable/flexible to provide the JMS version of the API (we are mostly interested in the "Tasks" part) via "bare JMS", i.e. without MDB(-s) ?
(II) It is common to expect XA / distributed transactions support from components in enterprise environments, which are targeted by jBPM. The components should nearly always integrate with existing / upcoming other subsystems, which makes interoperability one of their key qualities. At the moment, strictly speaking, "kie-remote" is either transactional (the JMS API) or highly interoperable out-of-the-box (the "JAX RS over HTTP" API).
Our initial intention was using the JAX RS version as it should be generally easier. However it is not transactional out-of-the-box. Here are some approaches to overcome this vital in enterprise environment limitation:
a. Client-side-managed transactions for JAX-RS
- [general purpose; prototype realization] https://community.jboss.org/wiki/TransactionalSupportForJAXRSBasedApplications
- [part of specific system] http://docs.marklogic.com/guide/rest-dev/transactions
- [part of specific system] https://wiki.duraspace.org/display/FF/Transaction+enabled+REST+API
b. Required by Java EE JAX-RS does not require HTTP as the transport. Here are descriptions for CXF realization of XA-transactional JAX-RS over JMS:
[fully featured documented example] https://github.com/Talend/tesb-rt-se/tree/master/examples/cxf/jaxrs-jms-http
[related article] http://sberyozkin.blogspot.ru/2012/07/jms-transport-support-for-cxf-jax-rs.html
Option (a) seems not production ready, plus we already cound on XA transactions in our distributed architecture to support various active resources participation in one distributed transaction.
Option (b) looks generally good for us (we already use CXF), but we probably do not want to use it because client-side code loses "lightness" of JAX RS (take a look at say "postGetMessage" method implementation here: https://github.com/Talend/tesb-rt-se/blob/master/examples/cxf/jaxrs-jms-http/client/src/main/java/client/JMSHttpClient.java )
So, I'd like to ask whether you are going to evolve both the "JMS" and "REST" versions of the API-s to cover same eventual functionality, first of all for Human Tasks? If yes, then we probably choose the "explicit JMS" integration option.
By the way, likely, JAX-WS in conjunction with WS-AtomicTransaction and WS-Coordination should have highest interoperability and be transactional in the same time. (see e.g. http://www.ibm.com/developerworks/library/ws-transjta/ )
Didn't you consider this combination as an API for "kie-remote" to expose?
Best regards,
Mikhail