[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