Re: jBPM 4 limitations
by Tom Baeyens
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.
17 years
Re: jBPM 4 limitations
by Martin Putz
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".
>
17 years
Re: jBPM 4 limitations
by Tom Baeyens
>> it's also a matter of what we know: for tomcat i could get started
>> myself and get it done fairly quickly. for WAS and WLS i wouldn't
>> know where to start in terms of licenses, automatic installation and
>> things like that. again, i believe that is an area where
>> productization people can help.
> We can revisit this topic in 4+ months and simply say that the first
> iteration of jBPM4.0 will not be supported on anything other than EAP
> and the SOA-P JVMs/DBs.
SOA-P was and is our first target.
Relation between jBPM and EAP has been unclear. Only lately we realized this was
also a dependency. I always thought us being part of SOA-P and not of EAP, while
SEAM includes jBPM is strange.
This has lead to
- unsynchronized release dates
- originally not included pageflow in our planning (in the meantime we have planned
to implement all SEAM requirements in jBPM 4 in the current release)
That is something we need to fix. Either move us over to EAP or have another
mechanism in place so that our plannings are better streamlined.
In that same context you mentioned:
> Yes, I'm not sure how to correct that. I think it would be best if Seam
> did not ship jBPM's jars, just the integration layer but it would appear
> that the two are currently hardwired together.
That has been estimated by the SEAM people at 1.5 months of work.
regards, tom.
Burr Sutter wrote:
>
>
> Tom Baeyens wrote:
>> >>> 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.
>>
>> you mean that they're using it on e.g. tomcat, which won't be
>> supported in the future ?
>>
>> we'll have to prioritize what we want to support. for each target, we
>> can build out the qa. but it has to be prioritized and the qa
>> infrastructure has to be in place before we sell support on it.
> Agreed.
>>
>> we realized that jbpm 3 was basically not supportable when it was
>> being added to the platform. but we didn't have a choice. in
>> retrospective, it would have been good to limit the deployment and dbs
>> instead of just supporting every client's need/wish.
> Absolutely, based on the current proposed strategy of how to include
> jBPM 4 in a support stream, I think we can safely "remove" capabilities
> (e.g. Tomcat, BEA, DB/2, JMS Jobexecutor).
>>
>> > However, we can increase our "platform" support in
>> > future months based on specific user feedback.
>>
>> exactly. prioritize, build qa infrastructure and then its done. it's
>> for this type of tasks that productization people could give us a
>> hand. this work is not very involved into the codebase. it just
>> requires a bit of discussion on how we're going to deploy on tomcat
>> and how the test suite needs to be configured.
>>
>> currently all this work boils down to the core developers and i hope
>> that we'll be able to find some hands that can help us with that.
>> especially since this is work that previously was done as part of the
>> productization cycle. and now we're incorporating that into the
>> project as we now know that we'll be the ones that have to use that qa
>> infrastructure to handle the difficult support cases.
>>
>> > 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.
>>
>> it's also a matter of what we know: for tomcat i could get started
>> myself and get it done fairly quickly. for WAS and WLS i wouldn't
>> know where to start in terms of licenses, automatic installation and
>> things like that. again, i believe that is an area where
>> productization people can help.
> We can revisit this topic in 4+ months and simply say that the first
> iteration of jBPM4.0 will not be supported on anything other than EAP
> and the SOA-P JVMs/DBs.
>>
>> > OK, I'm assuming that you'll work closely with Kevin whenever the
>> > integration task comes up in the future.
>>
>> Our current integration is based on what Kevin did. Heiko build it
>> and did a good job. We already had Kevin review and it was indeed
>> like he expected/wanted.
>>
>> >> 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.
>>
>> The project/product hierarchy that has been set up in this company has
>> not been helping in this respect. We were focussed on SOA-P. We knew
>> that SEAM includes jBPM but the current organisation structure doesn't
>> establish that. The current organisation on jBPM/SEAM/EAP/SOA-P
>> seems a bit broken to me. I can understand the commercial reasons and
>> positioning, but we need to fix the practical organisation part.
>> We're currently doing that ad hoc after the facts.
> Yes, I'm not sure how to correct that. I think it would be best if Seam
> did not ship jBPM's jars, just the integration layer but it would appear
> that the two are currently hardwired together.
>>
>> >>>>> * 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.
>>
>> first thing we need is qa infrastructure so that we can debug every
>> customer problem with the job executor. then we can zoom in and fix
>> every issue if it pops up. then the only other downside could be
>> performance, which is never critical. and performance of the job
>> executor won't be bad either.
>>
>> i'm confident that with the new job executor and the QA we have in
>> place for it, the current problems will go away. if that turns out to
>> be a false assumption, then we can still add JMS support fairly
>> quickly. we have all the components in place. only the
>> configurability and QA needs to be set up for it.
>>
>> >> 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.
>>
>> from the engine point of view, we have a clear separation. but i
>> start to realize that some sanetizations might have a big impact on
>> the designer and console tooling. so for each sanetization we have to
>> consider that impact.
>>
>> but that is not a problem for now. we focus on building out the
>> product features first. so there is no sanetization needed for jbpm 4
>> at this stage.
> Thanks!
>>
>> regards, tom.
>>
>>
>>
>>
>> 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.
17 years
[Design of JBoss jBPM] - Re: super-state, scope or something else
by brittm
I found "super-state" to be a poor term initially, as Ronald described.
Using 'scope' opens up a myriad of issues in my mind, since really everything has a scope. I would tend to start looking for how the same scope info was being applied in the data model to all levels of the process hierarchy.
"Group" would be confusing to me as well (but only because I already use that term in all my assignment handler configurations)--never the less, I think Ronald is right--and just because a particular language uses a term doesn't mean jpdl/jbpm has to, or should, avoid it. If it's the right word, then it's the right word.
In the end, I tend to go with naming things what they are, even if it's a little inconvenient initially--everyone seems to be happier in the long term. I would love to be able to use the terms 'wait' and 'group' for 'state' and 'super-state'.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4231403#4231403
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4231403
17 years