5 Replies Latest reply: Aug 2, 2013 5:47 AM by Alexander Herwix RSS

Integration of Human Task Service into Distributed Application

mknyazev Newbie

Dear JBPM experts,

 

 

Could you please suggest which of below plans of "Human Task Service" integration is best according with strategic JBPM development plans? A brief overview of our context:

 

In our backoffice system (with Resin 4 / Oracle DB at server side) we have an Ext GWT based "Work Issues" GUI which is backed by very simple "open / closed" task model.

We currently need such advanced features of jBPM WS-HumanTask realization as reassignments, managed deadlines, group task assignment, etc.

In 1-2 months, we only want to replace our human task model with jBPM 6 "Human task service" implementation and make only basic changes to our existing GUI.

Strategically, in 5-8 months, we are likely to make use of "jBPM Console NG" with its beautiful GUI and probably start adapting jBPM Business Process management implementation. At the moment, we have an imposed by our primary customer design constrain: our Java deployments must either use Resin 4 server (Java EE 6 Web Profile compatible) or be Java SE applications.

 

So, after thorough investigation of the older "jBPM 5.4 + BPM Console 2.3.8" bundle and the latest "jBPM 6 + jBPM Console NG" we have come up with following options.

 

 

(1) Deploy "Human Task Service" from jBPM 6 package on Resin 4 (it should work as the service can be deployed into e.g. Tomcat).

We need the Java-based backend of our system to deal with "Human Task Service", so, to minimize compile time dependencies for it, we are going to implement a "RESTful access facade" to the service via "JAX-RS with JAXB". We consider using existing classes from package "org.jbpm.services.task.impl.model.xml".

Some of them depend on jBPM original "Impl" model classes, so we will need to make more "plain JAXB implementations" of the model interfaces - to not introduce a dependency of our system from internal classes of "Human Task Service".

 

The "RESTful access facade" is going to be deployed in the same web application as "Human Task Service" - we will "wrap" an existing standard realization of interface "org.kie.internal.task.api.InternalTaskService" - same as it does server side of "jBPM Console NG" right now.

 

 

(2) Instead of development of our own "RESTful access facade", use one of following approaches:

 

 

2.a. Borrow and extend "org.jboss.bpm.console.server.TaskMgmtFacade" from BPM Console 2.3.8. and integrate it into "jBPM Console NG".

Use example "HT RESTful access" client code from this post for the older Console version: "Example JBPM Console Rest Client (plus example maven SpringMVC webapp)" ( https://community.jboss.org/thread/197164 )

 

 

2.b. Make use of "jBPM Console NG" server side. Deploy "org.jbpm.console.ng.ht.backend.server.TaskServiceEntryPointImpl" locally with "Human Task Service" and make our system dependent on package "org.jbpm.console.ng.ht.model". We are NOT sure it is technically possible because we want to access the Errai-based TaskServiceEntryPointImpl NOT from GWT - we needed our Java backend to act as a client for "org.jbpm.console.ng.ht.service.TaskServiceEntryPoint".

We know that Errai Bus uses RESTEasy to marshall / unmarshall entities, so if we cannot use Errai Bus directly, we may probably "re-annotate" TaskServiceEntryPointImpl and model classes from package "org.jbpm.console.ng.ht.model" to become JAX-RS-accessible at client side. Or are they already JAX-RS-accessible WITHOUT GWT?

 

 

Any comments would be highly appreciated.

 

Thank you very much in advance,

     Mikhail

  • 1. Re: Integration of Human Task Service into Distributed Application
    Mauricio Salatino Master

    HI Mikhail,

    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.

     

    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

     

    Take a look at that and if you have feedback we can improve that as well, There is no need to re invent the wheel, we should all collaborate to get these kind of things to work for everyone.

     

     

    Cheers

  • 2. Re: Integration of Human Task Service into Distributed Application
    mknyazev Newbie

    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 count 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

  • 3. Re: Integration of Human Task Service into Distributed Application
    Mauricio Salatino Master

    HI Mikhail,

    This is a great time for you to get involved in evolving what we have. As far as I know due time limitations we will not be able to provide the features that you want for 6.0, maybe for 6.1.

    We should be able, with the help of community members like you to evolve what is being provided out of the box in jbpm6 to provide more advanced features.

    As far as I understood for your email you want to deploy your app in Tomcat, and at the same time you wanted to have all the features provided by a EE container such as JBoss which is ready for more enterprise things like handling XA resources and transaction components such as MDBs. Nowadays JBoss is extremelily modular, so you can enable the web profile plus all the other components that you need and disable all the ones that you don't. I will always recommed to go with JMS if transactions are heavly involved in your scenario.

     

    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.

     

    Cheers

  • 4. Re: Integration of Human Task Service into Distributed Application
    mknyazev Newbie

    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

  • 5. Re: Integration of Human Task Service into Distributed Application
    Alexander Herwix Newbie

    Just bumping this thread, as these questions are interesting for me as well. An answer would be greatly appreciated