Mikhail Knyazev [
https://community.jboss.org/people/mknyazev] created the discussion
"Re: Integration of Human Task Service into Distributed Application"
To view the discussion, visit:
https://community.jboss.org/message/823038#823038
--------------------------------------------------------------
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-remo...
https://github.com/droolsjbpm/droolsjbpm-integration/tree/master/kie-remo...
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-1...
http://www.oracle.com/technetwork/articles/javaee/javaee6overview-part3-1...
)
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/docs/DOC-13311
https://community.jboss.org/wiki/TransactionalSupportForJAXRSBasedApplica...
- [part of specific system]
http://docs.marklogic.com/guide/rest-dev/transactions
http://docs.marklogic.com/guide/rest-dev/transactions
- [part of specific system]
https://wiki.duraspace.org/display/FF/Transaction+enabled+REST+API
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
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-r...
http://sberyozkin.blogspot.ru/2012/07/jms-transport-support-for-cxf-jax-r...
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-h...
https://github.com/Talend/tesb-rt-se/blob/master/examples/cxf/jaxrs-jms-h...
)
*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/
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
--------------------------------------------------------------
Reply to this message by going to Community
[
https://community.jboss.org/message/823038#823038]
Start a new discussion in jBPM Development at Community
[
https://community.jboss.org/choose-container!input.jspa?contentType=1&...]