[jbpm-dev] Re: jBPM 4 limitations

Tom Baeyens tbaeyens at redhat.com
Mon May 18 04:01:17 EDT 2009


Burr Sutter wrote:
> Hey Martin,
> 
> It would be IDEAL is for you to craft what you think you have heard into 
> this Jira.  

please use the jbpm 4 userguide as a reference.  if there is something left unclear 
in terms of supported vs unsupported, then raising a jira issue for that particular 
item is appropriate.

> You have the best experience with current jBPM3 
> users/customers and you can write these items down in a way that really 
> communicates best with the jBPM3 customerbase.    You are the best 
> qualified to get this language right.
> 
> Pretty please? :-)
> 
> We are looking at jBPM3 and jBPM4 side-by-side (in the same 
> container/JVM, in the same DB).
> We are NOT looking at migration tools at this time, in previous 
> discussions it was determined that any migration tools that are crafted 
> would be incomplete at best and take up a substantial amount of time 
> that nobody has right now.  Therefore, the side-by-side becomes a lot 
> more important since current users will have current processes/instances 
> in jBPM3 but deploy another application (new project) based on jBPM4.
> So at this moment, we are not looking to help people migrate, jBPM4 
> (especially in light of its newly documented limitations) is for new 
> projects - rebuild your JPDL, re-write your jBPM action handlers, 
> re-write all uses of jBPM APIs, re-write your custom queries against the 
> Hibernate schema and database.
> 
> This position could change after July 1st and jBPM4.0 (without the 
> letters GA) hitting jboss.org.

just for my verification: you are saying that we might still change our opinion and 
decide to build full DB migration at that point if customer demand mandates it, right ?

> Tom, did I state this correctly? Please feel free to jump on me if 
> necessary.

yes. very well :-)

regards, tom.

> 
> Burr
> 
> Martin Putz wrote:
>> I really appreciate this initiative. When it's time for the supported 
>> jBPM 4 version, we need to make this clear to customers as well, 
>> either by removing the unsupported elements, or by having a clear 
>> statement in the docs. Has this list made it into a JIRA (docs) issue 
>> already?
>>
>> The limitations make sense to me. It's not going to make all our 
>> existing jBPM 3 customers happy, but our current model of half-baked 
>> support for some features or configurations is not satisfying either.
>>
>> Another aspect that has been discussed already, but for which I'm not 
>> sure what the outcome was, are our 'migration' plans. I reckon we can 
>> have jBPM 3 & 4 side-by-side, but are we going to offer some further 
>> help to move from jBPM 3 to 4? Not thinking about full DB migration, 
>> but conversion tools for processes including how-to docs?
>>
>> Martin
>>
>>
>> Burr Sutter wrote:
>>>
>>>
>>> Tom Baeyens wrote:
>>>>
>>>>
>>>> Burr Sutter wrote:
>>>>>
>>>>>
>>>>> Tom Baeyens wrote:
>>>>>> 2 more
>>>>>>
>>>>>> * no user provided hibernate sessions
>>>>>> * no user provided jdbc connections
>>>>>>
>>>>> Would our jBPM3 customers think these are "losses"?
>>>>
>>>> in my estimation, I think that less then 1% of our users uses this 
>>>> feature.
>>> Very good, I think you, Alejandro and Martin would have the best 
>>> insight into what features are used or not.
>>>>
>>>>>> regards, tom.
>>>>>>
>>>>>>
>>>>>> Tom Baeyens wrote:
>>>>>>> Burr,
>>>>>>>
>>>>>>> In jBPM 4 one of the main goals is to improve the 
>>>>>>> supportability.  Therefor we are seriously expanding the QA 
>>>>>>> capabilities in the project.
>>>>>>>
>>>>>>> Another part of that is clearly indicate what environments and 
>>>>>>> configurations we support and which not.
>>>>>>>
>>>>>>> Here are a couple of limitations that I'ld like to start with 
>>>>>>> from a product perspective:
>>>>>>>
>>>>>>> * only one jBPM instance on a jboss server
>>>>> Can I have several .wars or .ears that all use that jBPM instance? 
>>>>
>>>> yes
>>>>
>>> Excellent, I think that is pretty critical, at least for smaller 
>>> shops & developers.  Large IT shops may only have a single 
>>> application running on a single instance of AS but I don't think that 
>>> is the norm.
>>>>>>> * only installation and configuration of jbpm as in the soa platform
>>>>> What does this statement mean?
>>>>
>>>> configuration of transaction related stuff:
>>>>  - jbpm configured to bind to JTA
>>>>  - jbpm command interceptor with JTA required semantics
>>>>  - jbpm configured to use hibernate's current session
>>>>  - jbpm configured to not create hibernate transactions
>>>>  - hibernate configured with a xa datasource
>>>>  - job executor configured as in the soa platform
>>>>
>>>> we create a set of configurations for jBPM, app server and hibernate 
>>>> so that it works.  users have to stick with the configuration we 
>>>> provide and for which we have QA set up.
>>>>
>>>> we saw in jbpm 3 that a lot of users burned their fingers if they 
>>>> start messing with these transactional settings.  e.g. let spring 
>>>> manage the transaction.
>>>>
>>>> jbpm 4 has improved conofigurability.  but we must only support 
>>>> those configuration sets for which we have QA running.
>>> Solid strategy.
>>>>
>>>>>>>  - distribution ships with an ant based installer that installs 
>>>>>>> jbpm into jboss
>>>>> Do we limit the support of jBPM to just JBoss EAP & SOA-P?  
>>>>> Historically, we've supported BEA, IBM, Tomcat, J2SE, etc.
>>>>
>>>> Yes.  Unless we have QA set of for it in the project.
>>> I have always felt this was an unnecessary risk and had asked for 
>>> this limitation before now and it will be a problem for several jBPM 
>>> 3 users/customers.  However, we can increase our "platform" support 
>>> in future months based on specific user feedback.
>>>>
>>>> With the infrastructure we have in place now, it should be pretty 
>>>> straightforward to add such a container like e.g. Tomcat.  But it 
>>>> takes work that has lower priority then embedding jBPM 4 into SOA-P 5.
>>>>
>>>> This is just a resource issue.  In the project, next target (after 
>>>> SOA-P 5) would be Tomcat.  I don't know know when we'll be able to 
>>>> deliver on that as SOA-P 5 takes precedence.
>>> WAS, WLS, EWS (supported Tomcat) would be higher priorities in my 
>>> book but I understand the project's need to be seen as Tomcat 
>>> friendly in order to increase adoption.
>>>>
>>>>>>>  - jbpm is installed in jbpm as a service archive
>>>>> jBPM is already be pre-installed inside of SOA-P, is there anything 
>>>>> in jBPM4 that requires it to be in a .sar?
>>>>
>>>> jBPM 4 installation is a combination of a sar, libs, configs and 
>>>> some ejbs.
>>>>
>>>> the sar part is necessary to publish the central jbpm ProcessEngine 
>>>> object into JNDI when JBoss boots.
>>> OK, I'm assuming that you'll work closely with Kevin whenever the 
>>> integration task comes up in the future.
>>>>
>>>>>>>  - jbpm ProcessEngine is published in JNDI
>>>>> Sounds good
>>>>>>>  - hibernate session factory configuration as part of the jbpm 
>>>>>>> installation
>>>>> Does this mean that a user can't "hijack" the hibernate session and 
>>>>> "work around" jBPM's use?
>>>>
>>>> They can but we should not support those scenarios until we have QA 
>>>> set up for these.
>>> Makes sense to me.
>>>>
>>>>>>>  - jta transaction integration
>>>>> excellent
>>>>>>>  - timer and async message run through our JobExecutor
>>>>>>> * only jboss idm identity component integration
>>>>> Will the JBoss Identity component ship with EAP5? Or is this a 
>>>>> component that jBPM will include in its own jars?
>>>>
>>>> It is targetted to ship with SOA-P 5.  They seem to be on track as 
>>>> well.
>>> But what about EAP/AS users?  We'll need to support that as a 
>>> platform with the identity component.
>>>>
>>>>>>> * no async messaging through JMS
>>>>> That will make some jBPM3 users unhappy. NTT feels this will add 
>>>>> scalability, especially in a cluster.
>>>>
>>>> Same here.  We have all functional components in place, but except 
>>>> for QA.  Setting that up requires productization resources which we 
>>>> don't have.  So that work is now serialized and will have to be 
>>>> prioritized after GA.
>>> This one feels a bit "high priority" to me only because some high 
>>> profile customer made such a big deal out of it.   With that said, 
>>> I'm not sure if the jBPM4 architecture without JMS is vastly better 
>>> than jBPM3 therefore the need for JMS just goes away.  Only you can 
>>> make that call.
>>>>
>>>>>>> * no timer support through EJB Timer
>>>>>>> * no spring transaction integration.
>>>>>>>
>>>>>>> We might be offering those to the community in order to get 
>>>>>>> feedback and flesh these out.  But until those extra features get 
>>>>>>> stable and we have the necessary QA build out, I would like not 
>>>>>>> to introduce those into the product.  This focus will help us to 
>>>>>>> deliver in time.
>>>>>>>
>>>>>>> Do these seem reasonable limitations to you ?
>>>>> Will these items ship in the .jars/.zips that we send to customers?
>>>>
>>>> Good question.  We're building the userguide docs so that those can 
>>>> be shipped as-is to customers.
>>>>
>>>> But in terms of disabling actual features as part of the 
>>>> sanetization process, i didn't give that much thought yet.
>>> OK, either we need to be able to "cut" the feature out of the product 
>>> zip OR we need to make it really easy in the docs to see that it is 
>>> "technology preview".   Ideally it would just get removed.  We did 
>>> this recently with Drools->BRMS, several files from the .org version 
>>> were removed as they were too experimental.
>>>>
>>>>>>> Do you see other jBPM aspects that need clarification if they are 
>>>>>>> supported or not ?
>>>>> Martin P would be one of the best resources to ask what should be 
>>>>> "in" vs "out".
>>>>
>>> I've copied Martin, I guess I should have from the "get go".
>>>

-- 
regards, tom.




More information about the jbpm-dev mailing list