We want to port the samples to the new .esb deployment right? Divide an conquer here? We each take a few?

TODO: aggregator business_service fun_cbr webservice_war1 jbpm_simple1 more_action simple_cbr static_router DONE: helloworld helloworld_action helloworld_db_registration helloworld_file_action helloworld_ftp_action helloworld_sql_action (I'm currently working on this one) scripting_groovy Bill Burke wrote: > We want to port the samples to the new .esb deployment right? Divide > an conquer here? We each take a few? > _______________________________________________ esb-dev mailing list esb-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/esb-dev

OK I think we should leave aggregator alone, as it has no real deployment now. I'm starting on fun_cbr. TODO: business_service webservice_war1 jbpm_simple1 more_action Kurt T Stam wrote: > The work that needs be done is building an .esb archive much like the > custom-action.jar but in addition it need to contain > a jboss-esb.xml in META-INF, and then changing the deployToSAR task to > deploy, which should deploy this archive to the > server/default/deploy directory. If the sample contains queue > definitions you may add this to the root of the .esb archive. > > For most samples I'm leaving the "ant run" task to start esb through > the bootstrapper. > > I'm taking static_router and simple_cbr right now. > > Cheers, > > --Kurt > > Kurt T Stam wrote: >> TODO: >> aggregator >> business_service >> fun_cbr >> webservice_war1 >> jbpm_simple1 >> more_action >> simple_cbr >> static_router >> >> DONE: >> helloworld >> helloworld_action >> helloworld_db_registration >> helloworld_file_action >> helloworld_ftp_action >> helloworld_sql_action (I'm currently working on this one) >> scripting_groovy >> >> >> >> Bill Burke wrote: >> >>> We want to port the samples to the new .esb deployment right? Divide >>> an conquer here? We each take a few? >>> >> >> _______________________________________________ >> esb-dev mailing list >> esb-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/esb-dev >> ------------------------------------------------------------------------ _______________________________________________ esb-dev mailing list esb-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/esb-dev

I thought we decided on today's SILC meeting to postpone the jBPM demo because of lack of time? Mark. On 21 Mar 2007, at 18:44, Kurt T Stam wrote: > OK I think we should leave aggregator alone, as it has no real deployment now. I'm starting on fun_cbr. > > TODO: > > business_service > webservice_war1 > jbpm_simple1 > more_action > > Kurt T Stam wrote: >> The work that needs be done is building an .esb archive much like >> the custom-action.jar but in addition it need to contain >> a jboss-esb.xml in META-INF, and then changing the deployToSAR task >> to deploy, which should deploy this archive to the >> server/default/deploy directory. If the sample contains queue >> definitions you may add this to the root of the .esb archive. >> >> For most samples I'm leaving the "ant run" task to start esb through >> the bootstrapper. >> >> I'm taking static_router and simple_cbr right now. >> >> Cheers, >> >> --Kurt >> >> Kurt T Stam wrote: >>> TODO: >>> aggregator >>> business_service >>> fun_cbr >>> webservice_war1 >>> jbpm_simple1 >>> more_action >>> simple_cbr >>> static_router >>> >>> DONE: >>> helloworld >>> helloworld_action >>> helloworld_db_registration >>> helloworld_file_action >>> helloworld_ftp_action >>> helloworld_sql_action (I'm currently working on this one) >>> scripting_groovy >>> >>> >>> >>> Bill Burke wrote: >>> >>>> We want to port the samples to the new .esb deployment right? Divide >>>> an conquer here? We each take a few? >>>> >>> _______________________________________________ >>> esb-dev mailing list >>> esb-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/esb-dev >>> > _______________________________________________ > esb-dev mailing list > esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/esb-dev

I thought we decided on today's SILC meeting to postpone the jBPM demo because of lack of time? Mark. On 21 Mar 2007, at 18:44, Kurt T Stam wrote: > OK I think we should leave aggregator alone, as it has no real deployment now. I'm starting on fun_cbr. > > TODO: > > business_service > webservice_war1 > jbpm_simple1 > more_action > > Kurt T Stam wrote: >> The work that needs be done is building an .esb archive much like >> the custom-action.jar but in addition it need to contain >> a jboss-esb.xml in META-INF, and then changing the deployToSAR task >> to deploy, which should deploy this archive to the >> server/default/deploy directory. If the sample contains queue >> definitions you may add this to the root of the .esb archive. >> >> For most samples I'm leaving the "ant run" task to start esb through >> the bootstrapper. >> >> I'm taking static_router and simple_cbr right now. >> >> Cheers, >> >> --Kurt >> >> Kurt T Stam wrote: >>> TODO: >>> aggregator >>> business_service >>> fun_cbr >>> webservice_war1 >>> jbpm_simple1 >>> more_action >>> simple_cbr >>> static_router >>> >>> DONE: >>> helloworld >>> helloworld_action >>> helloworld_db_registration >>> helloworld_file_action >>> helloworld_ftp_action >>> helloworld_sql_action (I'm currently working on this one) >>> scripting_groovy >>> >>> >>> >>> Bill Burke wrote: >>> >>>> We want to port the samples to the new .esb deployment right? Divide >>>> an conquer here? We each take a few? >>>> >>> _______________________________________________ >>> esb-dev mailing list >>> esb-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/esb-dev >>> > _______________________________________________ > esb-dev mailing list > esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/esb-dev

Do we want to add EJB3 for busines_service? Probably add another 4meg to the distro. But we would have Hibernate too. Eventually somebody will write the Hibernate/JPA actions that Burr suggested during the meeting in Westford. Kurt T Stam wrote: > Starting work on more_action > > TODO > > business_service (this is ejb3, and will require deploying to the > appserver) > webservice_war1 (this requires a WS stack, which also requires the > appserver). > > > > > Mark Little wrote: >> I thought we decided on today's SILC meeting to postpone the jBPM >> demo because of lack of time? >> >> Mark. >> >> >> On 21 Mar 2007, at 18:44, Kurt T Stam wrote: >> >>> OK I think we should leave aggregator alone, as it has no real >>> deployment now. I'm starting on fun_cbr. >>> >>> TODO: >>> >>> business_service >>> webservice_war1 >>> jbpm_simple1 >>> more_action >>> >>> Kurt T Stam wrote: >>>> The work that needs be done is building an .esb archive much like >>>> the custom-action.jar but in addition it need to contain >>>> a jboss-esb.xml in META-INF, and then changing the deployToSAR >>>> task to deploy, which should deploy this archive to the >>>> server/default/deploy directory. If the sample contains queue >>>> definitions you may add this to the root of the .esb archive. >>>> >>>> For most samples I'm leaving the "ant run" task to start esb >>>> through the bootstrapper. >>>> >>>> I'm taking static_router and simple_cbr right now. >>>> >>>> Cheers, >>>> >>>> --Kurt >>>> >>>> Kurt T Stam wrote: >>>>> TODO: >>>>> aggregator >>>>> business_service >>>>> fun_cbr >>>>> webservice_war1 >>>>> jbpm_simple1 >>>>> more_action >>>>> simple_cbr >>>>> static_router >>>>> >>>>> DONE: >>>>> helloworld >>>>> helloworld_action >>>>> helloworld_db_registration >>>>> helloworld_file_action >>>>> helloworld_ftp_action >>>>> helloworld_sql_action (I'm currently working on this one) >>>>> scripting_groovy >>>>> >>>>> >>>>> >>>>> Bill Burke wrote: >>>>> >>>>>> We want to port the samples to the new .esb deployment right? >>>>>> Divide >>>>>> an conquer here? We each take a few? >>>>>> >>>>> _______________________________________________ >>>>> esb-dev mailing list >>>>> esb-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>> >>> _______________________________________________ >>> esb-dev mailing list >>> esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/esb-dev >> > > ------------------------------------------------------------------------ > > _______________________________________________ > esb-dev mailing list > esb-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/esb-dev

+1 On 21 Mar 2007, at 22:03, Kurt T Stam wrote: > Good question. And we will have this discussion for JBESB-5.0: "Even > when everything is pluggable, What comes standard in it?". My feeling is > that is should not come with JBESB by default as it is not core to > SOA/ESB, but if we really should have some installer functionality we > could make it easy to add them in, just like adding the ftp server, > email server etc. I looked into using the izPack thing before, which > looks pretty nice. We some customized version in JBossAS, which allows > remote installs etc. I think that may be the way to go (after MP1). > > Bill Burke wrote: >> Do we want to add EJB3 for busines_service? Probably add another >> 4meg to the distro. But we would have Hibernate too. Eventually >> somebody will write the Hibernate/JPA actions that Burr suggested >> during the meeting in Westford. >> >> Kurt T Stam wrote: >>> Starting work on more_action >>> >>> TODO >>> >>> business_service (this is ejb3, and will require deploying to the >>> appserver) >>> webservice_war1 (this requires a WS stack, which also requires the >>> appserver). >>> >>> >>> >>> >>> Mark Little wrote: >>>> I thought we decided on today's SILC meeting to postpone the jBPM >>>> demo because of lack of time? >>>> >>>> Mark. >>>> >>>> >>>> On 21 Mar 2007, at 18:44, Kurt T Stam wrote: >>>> >>>>> OK I think we should leave aggregator alone, as it has no real >>>>> deployment now. I'm starting on fun_cbr. >>>>> >>>>> TODO: >>>>> >>>>> business_service >>>>> webservice_war1 >>>>> jbpm_simple1 >>>>> more_action >>>>> >>>>> Kurt T Stam wrote: >>>>>> The work that needs be done is building an .esb archive much like >>>>>> the custom-action.jar but in addition it need to contain >>>>>> a jboss-esb.xml in META-INF, and then changing the deployToSAR >>>>>> task to deploy, which should deploy this archive to the >>>>>> server/default/deploy directory. If the sample contains queue >>>>>> definitions you may add this to the root of the .esb archive. >>>>>> >>>>>> For most samples I'm leaving the "ant run" task to start esb >>>>>> through the bootstrapper. >>>>>> >>>>>> I'm taking static_router and simple_cbr right now. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> --Kurt >>>>>> >>>>>> Kurt T Stam wrote: >>>>>>> TODO: >>>>>>> aggregator >>>>>>> business_service >>>>>>> fun_cbr >>>>>>> webservice_war1 >>>>>>> jbpm_simple1 >>>>>>> more_action >>>>>>> simple_cbr >>>>>>> static_router >>>>>>> >>>>>>> DONE: >>>>>>> helloworld >>>>>>> helloworld_action >>>>>>> helloworld_db_registration >>>>>>> helloworld_file_action >>>>>>> helloworld_ftp_action >>>>>>> helloworld_sql_action (I'm currently working on this one) >>>>>>> scripting_groovy >>>>>>> >>>>>>> >>>>>>> >>>>>>> Bill Burke wrote: >>>>>>> >>>>>>>> We want to port the samples to the new .esb deployment right? >>>>>>>> Divide >>>>>>>> an conquer here? We each take a few? >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> esb-dev mailing list >>>>>>> esb-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>> >>>>> _______________________________________________ >>>>> esb-dev mailing list >>>>> esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> esb-dev mailing list >>> esb-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/esb-dev >> > _______________________________________________ esb-dev mailing list esb-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/esb-dev

We're OK for this release. We need to re-examine the TB anyway after MP goes out. But as you know, having everything run and work out-of-the-box with zero config effort is what we've been striving for for a while. I think we're not too bad. Mark. On 22 Mar 2007, at 10:16, Tom Fennelly wrote: > The TB and the console currently require EJB3. Therefore, for this > release we require the user to run both of these on a full AS install. > For the TB, this means running against JBossMQ instead of JBM. > Otherwise, the user has to install JBM on their AS, which is not > something we should be requiring them to do. Additionally, it's a > pain in the ass to do because it requires them to have Ant 1.7 > installed on their system. It's probably something they'd not want > to do anyway - "I'm not screwing with my AS install just to get a > sample working" :-) > > Getting the TB to work against both MQ and JBM is no big deal - I > tested it with one of the quickstarts. > > So, my point is... while from a purest standpoint it might be "nicer" > to not ship EJB3 (or whatever) as part of the esb-server, it > certainly seems as though it might make life easier in a lot of > situations - both for us and the user. Once we have a fancy > installer we can make things optional. Just my opinion. > > T. > > > Mark Little wrote: >> +1 >> >> >> On 21 Mar 2007, at 22:03, Kurt T Stam wrote: >> >>> Good question. And we will have this discussion for JBESB-5.0: "Even >>> when everything is pluggable, What comes standard in it?". My >>> feeling is >>> that is should not come with JBESB by default as it is not core to >>> SOA/ESB, but if we really should have some installer functionality we >>> could make it easy to add them in, just like adding the ftp server, >>> email server etc. I looked into using the izPack thing before, which >>> looks pretty nice. We some customized version in JBossAS, which allows >>> remote installs etc. I think that may be the way to go (after MP1). >>> >>> Bill Burke wrote: >>>> Do we want to add EJB3 for busines_service? Probably add another >>>> 4meg to the distro. But we would have Hibernate too. Eventually >>>> somebody will write the Hibernate/JPA actions that Burr suggested >>>> during the meeting in Westford. >>>> >>>> Kurt T Stam wrote: >>>>> Starting work on more_action >>>>> >>>>> TODO >>>>> >>>>> business_service (this is ejb3, and will require deploying to the >>>>> appserver) >>>>> webservice_war1 (this requires a WS stack, which also requires the >>>>> appserver). >>>>> >>>>> >>>>> >>>>> >>>>> Mark Little wrote: >>>>>> I thought we decided on today's SILC meeting to postpone the jBPM >>>>>> demo because of lack of time? >>>>>> >>>>>> Mark. >>>>>> >>>>>> >>>>>> On 21 Mar 2007, at 18:44, Kurt T Stam wrote: >>>>>> >>>>>>> OK I think we should leave aggregator alone, as it has no real >>>>>>> deployment now. I'm starting on fun_cbr. >>>>>>> >>>>>>> TODO: >>>>>>> >>>>>>> business_service >>>>>>> webservice_war1 >>>>>>> jbpm_simple1 >>>>>>> more_action >>>>>>> >>>>>>> Kurt T Stam wrote: >>>>>>>> The work that needs be done is building an .esb archive much like >>>>>>>> the custom-action.jar but in addition it need to contain >>>>>>>> a jboss-esb.xml in META-INF, and then changing the deployToSAR >>>>>>>> task to deploy, which should deploy this archive to the >>>>>>>> server/default/deploy directory. If the sample contains queue >>>>>>>> definitions you may add this to the root of the .esb archive. >>>>>>>> >>>>>>>> For most samples I'm leaving the "ant run" task to start esb >>>>>>>> through the bootstrapper. >>>>>>>> >>>>>>>> I'm taking static_router and simple_cbr right now. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> --Kurt >>>>>>>> >>>>>>>> Kurt T Stam wrote: >>>>>>>>> TODO: >>>>>>>>> aggregator >>>>>>>>> business_service >>>>>>>>> fun_cbr >>>>>>>>> webservice_war1 >>>>>>>>> jbpm_simple1 >>>>>>>>> more_action >>>>>>>>> simple_cbr >>>>>>>>> static_router >>>>>>>>> >>>>>>>>> DONE: >>>>>>>>> helloworld >>>>>>>>> helloworld_action >>>>>>>>> helloworld_db_registration >>>>>>>>> helloworld_file_action >>>>>>>>> helloworld_ftp_action >>>>>>>>> helloworld_sql_action (I'm currently working on this one) >>>>>>>>> scripting_groovy >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Bill Burke wrote: >>>>>>>>> >>>>>>>>>> We want to port the samples to the new .esb deployment right? >>>>>>>>>> Divide >>>>>>>>>> an conquer here? We each take a few? >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> esb-dev mailing list >>>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>> >>>>>>> _______________________________________________ >>>>>>> esb-dev mailing list >>>>>>> esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> >>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> _______________________________________________ >>>>> esb-dev mailing list >>>>> esb-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>> >>> >> >> _______________________________________________ >> esb-dev mailing list >> esb-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/esb-dev

OK, well I'm going to get it sorted for running on the AS for now, and will loop back on adding the WS stuff to the server after (if it's not sorted by then). Just wanna make sure we ha

The TB really only needs WS (annotations, jsr 181). This should actually be core to ESB! It is not in the standalone right now to make it light, and b/c we don't fully suppoer WS yet. But maybe we should do some investigation to add this in for this release?

I think the TB readme says you need the "ejb3" profile, but I think that had to do with the annotation support. Bill, we should be able to get WS + annotation support without EJB3 stuff right? It's be nice to get the TB running out of the box. --Kurt Mark Little wrote: > We're OK for this release. We need to re-examine the TB anyway after > MP goes out. But as you know, having everything run and work > out-of-the-box with zero config effort is what we've been striving > for > for a while. I think we're not too bad. > > Mark. > > > On 22 Mar 2007, at 10:16, Tom Fennelly wrote: > >> The TB and the console currently require EJB3. Therefore, for this >> release we require the user to run both of these on a full AS >> install. >> For the TB, this means running against JBossMQ instead of JBM. >> Otherwise, the user has to install JBM on their AS, which is not >> something we should be requiring them to do. Additionally, it's a >> pain in the ass to do because it requires them to have Ant 1.7 >> installed on their system. It's probably something they'd not want >> to do anyway - "I'm not screwing with my AS install just to get a >> sample working" :-) >> >> Getting the TB to work against both MQ and JBM is no big deal - I >> tested it with one of the quickstarts. >> >> So, my point is... while from a purest standpoint it might be >> "nicer" >> to not ship EJB3 (or whatever) as part of the esb-server, it >> certainly seems as though it might make life easier in a lot of >> situations - both for us and the user. Once we have a fancy >> installer we can make things optional. Just my opinion. >> >> T. >> >> >> Mark Little wrote: >>> +1 >>> >>> >>> On 21 Mar 2007, at 22:03, Kurt T Stam wrote: >>> >>>> Good question. And we will have this discussion for JBESB-5.0: >>>> "Even >>>> when everything is pluggable, What comes standard in it?". My >>>> feeling is >>>> that is should not come with JBESB by default as it is not core to >>>> SOA/ESB, but if we really should have some installer >>>> functionality we >>>> could make it easy to add them in, just like adding the ftp >>>> server, >>>> email server etc. I looked into using the izPack thing before, >>>> which >>>> looks pretty nice. We some customized version in JBossAS, which >>>> allows >>>> remote installs etc. I think that may be the way to go (after >>>> MP1). >>>> >>>> Bill Burke wrote: >>>>> Do we want to add EJB3 for busines_service? Probably add >>>>> another >>>>> 4meg to the distro. But we would have Hibernate too. Eventually >>>>> somebody will write the Hibernate/JPA actions that Burr suggested >>>>> during the meeting in Westford. >>>>> >>>>> Kurt T Stam wrote: >>>>>> Starting work on more_action >>>>>> >>>>>> TODO >>>>>> >>>>>> business_service (this is ejb3, and will require deploying to >>>>>> the >>>>>> appserver) >>>>>> webservice_war1 (this requires a WS stack, which also >>>>>> requires the >>>>>> appserver). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Mark Little wrote: >>>>>>> I thought we decided on today's SILC meeting to postpone the >>>>>>> jBPM >>>>>>> demo because of lack of time? >>>>>>> >>>>>>> Mark. >>>>>>> >>>>>>> >>>>>>> On 21 Mar 2007, at 18:44, Kurt T Stam wrote: >>>>>>> >>>>>>>> OK I think we should leave aggregator alone, as it has no real >>>>>>>> deployment now. I'm starting on fun_cbr. >>>>>>>> >>>>>>>> TODO: >>>>>>>> >>>>>>>> business_service >>>>>>>> webservice_war1 >>>>>>>> jbpm_simple1 >>>>>>>> more_action >>>>>>>> >>>>>>>> Kurt T Stam wrote: >>>>>>>>> The work that needs be done is building an .esb archive >>>>>>>>> much like >>>>>>>>> the custom-action.jar but in addition it need to contain >>>>>>>>> a jboss-esb.xml in META-INF, and then changing the >>>>>>>>> deployToSAR >>>>>>>>> task to deploy, which should deploy this archive to the >>>>>>>>> server/default/deploy directory. If the sample contains queue >>>>>>>>> definitions you may add this to the root of the .esb archive. >>>>>>>>> >>>>>>>>> For most samples I'm leaving the "ant run" task to start esb >>>>>>>>> through the bootstrapper. >>>>>>>>> >>>>>>>>> I'm taking static_router and simple_cbr right now. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> --Kurt >>>>>>>>> >>>>>>>>> Kurt T Stam wrote: >>>>>>>>>> TODO: >>>>>>>>>> aggregator >>>>>>>>>> business_service >>>>>>>>>> fun_cbr >>>>>>>>>> webservice_war1 >>>>>>>>>> jbpm_simple1 >>>>>>>>>> more_action >>>>>>>>>> simple_cbr >>>>>>>>>> static_router >>>>>>>>>> >>>>>>>>>> DONE: >>>>>>>>>> helloworld >>>>>>>>>> helloworld_action >>>>>>>>>> helloworld_db_registration >>>>>>>>>> helloworld_file_action >>>>>>>>>> helloworld_ftp_action >>>>>>>>>> helloworld_sql_action (I'm currently working on this one) >>>>>>>>>> scripting_groovy >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Bill Burke wrote: >>>>>>>>>> >>>>>>>>>>> We want to port the samples to the new .esb deployment >>>>>>>>>>> right? >>>>>>>>>>> Divide >>>>>>>>>>> an conquer here? We each take a few? >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> esb-dev mailing list >>>>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> esb-dev mailing list >>>>>>>> esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> >>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>> >>>>>> >>>>>> ---------------------------------------------------------------- >>>>>> -------- >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> esb-dev mailing list >>>>>> esb-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>> >>>> >>> >>> _______________________________________________ >>> esb-dev mailing list >>> esb-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/esb-dev >

For now, I'm working on getting it working via the AS. If we get a chance to try out adding WS to the standalone, great, otherwise we should still have it working via the AS. T. Mark Little wrote: > > On 22 Mar 2007, at 12:36, Kurt T Stam wrote: > >> The TB really only needs WS (annotations, jsr 181). This should >> actually >> be core to ESB! It is not in the standalone right now to make it >> light, >> and b/c we don't fully suppoer WS yet. But maybe we should do some >> investigation to add this in for this release? > > > There's a task that was assigned to Daniel for this for post MP. > However, I'm uncomfortable about adding this at this stage, so > let's leave it until later. > > Mark. > > > >> >> I think the TB readme says you need the "ejb3" profile, but I >> think that >> had to do with the annotation support. Bill, we should be able to >> get WS >> + annotation support without EJB3 stuff right? It's be nice to >> get the >> TB running out of the box. >> >> --Kurt >> >> Mark Little wrote: >>> We're OK for this release. We need to re-examine the TB anyway >>> after >>> MP goes out. But as you know, having everything run and work >>> out-of-the-box with zero config effort is what we've been >>> striving for >>> for a while. I think we're not too bad. >>> >>> Mark. >>> >>> >>> On 22 Mar 2007, at 10:16, Tom Fennelly wrote: >>> >>>> The TB and the console currently require EJB3. Therefore, for >>>> this >>>> release we require the user to run both of these on a full AS >>>> install. >>>> For the TB, this means running against JBossMQ instead of JBM. >>>> Otherwise, the user has to install JBM on their AS, which is not >>>> something we should be requiring them to do. Additionally, it's a >>>> pain in the ass to do because it requires them to have Ant 1.7 >>>> installed on their system. It's probably something they'd not >>>> want >>>> to do anyway - "I'm not screwing with my AS install just to get a >>>> sample working" :-) >>>> >>>> Getting the TB to work against both MQ and JBM is no big deal - I >>>> tested it with one of the quickstarts. >>>> >>>> So, my point is... while from a purest standpoint it might be >>>> "nicer" >>>> to not ship EJB3 (or whatever) as part of the esb-server, it >>>> certainly seems as though it might make life easier in a lot of >>>> situations - both for us and the user. Once we have a fancy >>>> installer we can make things optional. Just my opinion. >>>> >>>> T. >>>> >>>> >>>> Mark Little wrote: >>>>> +1 >>>>> >>>>> >>>>> On 21 Mar 2007, at 22:03, Kurt T Stam wrote: >>>>> >>>>>> Good question. And we will have this discussion for >>>>>> JBESB-5.0: "Even >>>>>> when everything is pluggable, What comes standard in it?". My >>>>>> feeling is >>>>>> that is should not come with JBESB by default as it is not >>>>>> core to >>>>>> SOA/ESB, but if we really should have some installer >>>>>> functionality we >>>>>> could make it easy to add them in, just like adding the ftp >>>>>> server, >>>>>> email server etc. I looked into using the izPack thing >>>>>> before, which >>>>>> looks pretty nice. We some customized version in JBossAS, >>>>>> which allows >>>>>> remote installs etc. I think that may be the way to go (after >>>>>> MP1). >>>>>> >>>>>> Bill Burke wrote: >>>>>>> Do we want to add EJB3 for busines_service? Probably add >>>>>>> another >>>>>>> 4meg to the distro. But we would have Hibernate too. >>>>>>> Eventually >>>>>>> somebody will write the Hibernate/JPA actions that Burr >>>>>>> suggested >>>>>>> during the meeting in Westford. >>>>>>> >>>>>>> Kurt T Stam wrote: >>>>>>>> Starting work on more_action >>>>>>>> >>>>>>>> TODO >>>>>>>> >>>>>>>> business_service (this is ejb3, and will require deploying >>>>>>>> to the >>>>>>>> appserver) >>>>>>>> webservice_war1 (this requires a WS stack, which also >>>>>>>> requires the >>>>>>>> appserver). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Mark Little wrote: >>>>>>>>> I thought we decided on today's SILC meeting to postpone >>>>>>>>> the jBPM >>>>>>>>> demo because of lack of time? >>>>>>>>> >>>>>>>>> Mark. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 21 Mar 2007, at 18:44, Kurt T Stam wrote: >>>>>>>>> >>>>>>>>>> OK I think we should leave aggregator alone, as it has no >>>>>>>>>> real >>>>>>>>>> deployment now. I'm starting on fun_cbr. >>>>>>>>>> >>>>>>>>>> TODO: >>>>>>>>>> >>>>>>>>>> business_service >>>>>>>>>> webservice_war1 >>>>>>>>>> jbpm_simple1 >>>>>>>>>> more_action >>>>>>>>>> >>>>>>>>>> Kurt T Stam wrote: >>>>>>>>>>> The work that needs be done is building an .esb archive >>>>>>>>>>> much like >>>>>>>>>>> the custom-action.jar but in addition it need to contain >>>>>>>>>>> a jboss-esb.xml in META-INF, and then changing the >>>>>>>>>>> deployToSAR >>>>>>>>>>> task to deploy, which should deploy this archive to the >>>>>>>>>>> server/default/deploy directory. If the sample contains >>>>>>>>>>> queue >>>>>>>>>>> definitions you may add this to the root of the .esb >>>>>>>>>>> archive. >>>>>>>>>>> >>>>>>>>>>> For most samples I'm leaving the "ant run" task to start >>>>>>>>>>> esb >>>>>>>>>>> through the bootstrapper. >>>>>>>>>>> >>>>>>>>>>> I'm taking static_router and simple_cbr right now. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> >>>>>>>>>>> --Kurt >>>>>>>>>>> >>>>>>>>>>> Kurt T Stam wrote: >>>>>>>>>>>> TODO: >>>>>>>>>>>> aggregator >>>>>>>>>>>> business_service >>>>>>>>>>>> fun_cbr >>>>>>>>>>>> webservice_war1 >>>>>>>>>>>> jbpm_simple1 >>>>>>>>>>>> more_action >>>>>>>>>>>> simple_cbr >>>>>>>>>>>> static_router >>>>>>>>>>>> >>>>>>>>>>>> DONE: >>>>>>>>>>>> helloworld >>>>>>>>>>>> helloworld_action >>>>>>>>>>>> helloworld_db_registration >>>>>>>>>>>> helloworld_file_action >>>>>>>>>>>> helloworld_ftp_action >>>>>>>>>>>> helloworld_sql_action (I'm currently working on this one) >>>>>>>>>>>> scripting_groovy >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Bill Burke wrote: >>>>>>>>>>>> >>>>>>>>>>>>> We want to port the samples to the new .esb deployment >>>>>>>>>>>>> right? >>>>>>>>>>>>> Divide >>>>>>>>>>>>> an conquer here? We each take a few? >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> esb-dev mailing list >>>>>>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> esb-dev mailing list >>>>>>>>>> esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>> >>>>>>>> >>>>>>>> -------------------------------------------------------------- >>>>>>>> ---------- >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> esb-dev mailing list >>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> esb-dev mailing list >>>>> esb-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>> >> >

+1000000 I've been burned too many times by that last minute "easy" fix/ feature :-) Mark Little wrote: > Given past experience, let's not try to shoe-horn in anything that > seems easy at the last minute ;-) > > Mark. > > > On 22 Mar 2007, at 15:21, Tom Fennelly wrote: > >> For now, I'm working on getting it working via the AS. If we get >> a chance to try out adding WS to the standalone, great, otherwise >> we should still have it working via the AS. >> >> T. >> >> >> Mark Little wrote: >>> >>> On 22 Mar 2007, at 12:36, Kurt T Stam wrote: >>> >>>> The TB really only needs WS (annotations, jsr 181). This should >>>> actually >>>> be core to ESB! It is not in the standalone right now to make >>>> it light, >>>> and b/c we don't fully suppoer WS yet. But maybe we should do some >>>> investigation to add this in for this release? >>> >>> >>> There's a task that was assigned to Daniel for this for post MP. >>> However, I'm uncomfortable about adding this at this stage, so >>> let's leave it until later. >>> >>> Mark. >>> >>> >>> >>>> >>>> I think the TB readme says you need the "ejb3" profile, but I >>>> think that >>>> had to do with the annotation support. Bill, we should be able >>>> to get WS >>>> + annotation support without EJB3 stuff right? It's be nice to >>>> get the >>>> TB running out of the box. >>>> >>>> --Kurt >>>> >>>> Mark Little wrote: >>>>> We're OK for this release. We need to re-examine the TB anyway >>>>> after >>>>> MP goes out. But as you know, having everything run and work >>>>> out-of-the-box with zero config effort is what we've been >>>>> striving for >>>>> for a while. I think we're not too bad. >>>>> >>>>> Mark. >>>>> >>>>> >>>>> On 22 Mar 2007, at 10:16, Tom Fennelly wrote: >>>>> >>>>>> The TB and the console currently require EJB3. Therefore, >>>>>> for this >>>>>> release we require the user to run both of these on a full AS >>>>>> install. >>>>>> For the TB, this means running against JBossMQ instead of JBM. >>>>>> Otherwise, the user has to install JBM on their AS, which is not >>>>>> something we should be requiring them to do. Additionally, >>>>>> it's a >>>>>> pain in the ass to do because it requires them to have Ant 1.7 >>>>>> installed on their system. It's probably something they'd >>>>>> not want >>>>>> to do anyway - "I'm not screwing with my AS install just to >>>>>> get a >>>>>> sample working" :-) >>>>>> >>>>>> Getting the TB to work against both MQ and JBM is no big deal >>>>>> - I >>>>>> tested it with one of the quickstarts. >>>>>> >>>>>> So, my point is... while from a purest standpoint it might be >>>>>> "nicer" >>>>>> to not ship EJB3 (or whatever) as part of the esb-server, it >>>>>> certainly seems as though it might make life easier in a lot of >>>>>> situations - both for us and the user. Once we have a fancy >>>>>> installer we can make things optional. Just my opinion. >>>>>> >>>>>> T. >>>>>> >>>>>> >>>>>> Mark Little wrote: >>>>>>> +1 >>>>>>> >>>>>>> >>>>>>> On 21 Mar 2007, at 22:03, Kurt T Stam wrote: >>>>>>> >>>>>>>> Good question. And we will have this discussion for >>>>>>>> JBESB-5.0: "Even >>>>>>>> when everything is pluggable, What comes standard in it?". My >>>>>>>> feeling is >>>>>>>> that is should not come with JBESB by default as it is not >>>>>>>> core to >>>>>>>> SOA/ESB, but if we really should have some installer >>>>>>>> functionality we >>>>>>>> could make it easy to add them in, just like adding the ftp >>>>>>>> server, >>>>>>>> email server etc. I looked into using the izPack thing >>>>>>>> before, which >>>>>>>> looks pretty nice. We some customized version in JBossAS, >>>>>>>> which allows >>>>>>>> remote installs etc. I think that may be the way to go >>>>>>>> (after MP1). >>>>>>>> >>>>>>>> Bill Burke wrote: >>>>>>>>> Do we want to add EJB3 for busines_service? Probably add >>>>>>>>> another >>>>>>>>> 4meg to the distro. But we would have Hibernate too. >>>>>>>>> Eventually >>>>>>>>> somebody will write the Hibernate/JPA actions that Burr >>>>>>>>> suggested >>>>>>>>> during the meeting in Westford. >>>>>>>>> >>>>>>>>> Kurt T Stam wrote: >>>>>>>>>> Starting work on more_action >>>>>>>>>> >>>>>>>>>> TODO >>>>>>>>>> >>>>>>>>>> business_service (this is ejb3, and will require >>>>>>>>>> deploying to the >>>>>>>>>> appserver) >>>>>>>>>> webservice_war1 (this requires a WS stack, which also >>>>>>>>>> requires the >>>>>>>>>> appserver). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Mark Little wrote: >>>>>>>>>>> I thought we decided on today's SILC meeting to postpone >>>>>>>>>>> the jBPM >>>>>>>>>>> demo because of lack of time? >>>>>>>>>>> >>>>>>>>>>> Mark. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 21 Mar 2007, at 18:44, Kurt T Stam wrote: >>>>>>>>>>> >>>>>>>>>>>> OK I think we should leave aggregator alone, as it has >>>>>>>>>>>> no real >>>>>>>>>>>> deployment now. I'm starting on fun_cbr. >>>>>>>>>>>> >>>>>>>>>>>> TODO: >>>>>>>>>>>> >>>>>>>>>>>> business_service >>>>>>>>>>>> webservice_war1 >>>>>>>>>>>> jbpm_simple1 >>>>>>>>>>>> more_action >>>>>>>>>>>> >>>>>>>>>>>> Kurt T Stam wrote: >>>>>>>>>>>>> The work that needs be done is building an .esb >>>>>>>>>>>>> archive much like >>>>>>>>>>>>> the custom-action.jar but in addition it need to contain >>>>>>>>>>>>> a jboss-esb.xml in META-INF, and then changing the >>>>>>>>>>>>> deployToSAR >>>>>>>>>>>>> task to deploy, which should deploy this archive to the >>>>>>>>>>>>> server/default/deploy directory. If the sample >>>>>>>>>>>>> contains queue >>>>>>>>>>>>> definitions you may add this to the root of the .esb >>>>>>>>>>>>> archive. >>>>>>>>>>>>> >>>>>>>>>>>>> For most samples I'm leaving the "ant run" task to >>>>>>>>>>>>> start esb >>>>>>>>>>>>> through the bootstrapper. >>>>>>>>>>>>> >>>>>>>>>>>>> I'm taking static_router and simple_cbr right now. >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> >>>>>>>>>>>>> --Kurt >>>>>>>>>>>>> >>>>>>>>>>>>> Kurt T Stam wrote: >>>>>>>>>>>>>> TODO: >>>>>>>>>>>>>> aggregator >>>>>>>>>>>>>> business_service >>>>>>>>>>>>>> fun_cbr >>>>>>>>>>>>>> webservice_war1 >>>>>>>>>>>>>> jbpm_simple1 >>>>>>>>>>>>>> more_action >>>>>>>>>>>>>> simple_cbr >>>>>>>>>>>>>> static_router >>>>>>>>>>>>>> >>>>>>>>>>>>>> DONE: >>>>>>>>>>>>>> helloworld >>>>>>>>>>>>>> helloworld_action >>>>>>>>>>>>>> helloworld_db_registration >>>>>>>>>>>>>> helloworld_file_action >>>>>>>>>>>>>> helloworld_ftp_action >>>>>>>>>>>>>> helloworld_sql_action (I'm currently working on this >>>>>>>>>>>>>> one) >>>>>>>>>>>>>> scripting_groovy >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Bill Burke wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> We want to port the samples to the new .esb >>>>>>>>>>>>>>> deployment right? >>>>>>>>>>>>>>> Divide >>>>>>>>>>>>>>> an conquer here? We each take a few? >>>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> esb-dev mailing list >>>>>>>>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> esb-dev mailing list >>>>>>>>>>>> esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------ >>>>>>>>>> ------------ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> esb-dev mailing list >>>>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> esb-dev mailing list >>>>>>> esb-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>> >>>> >>> >

The TB and the console currently require EJB3. Therefore, for this release we require the user to run both of these on a full AS install. For the TB, this means running against JBossMQ instead of JBM. Otherwise, the user has to install JBM on their AS, which is not something we should be requiring them to do. Additionally, it's a pain in the ass to do because it requires them to have Ant 1.7 installed on their system. It's probably something they'd not want to do anyway - "I'm not screwing with my AS install just to get a sample working" :-) Getting the TB to work against both MQ and JBM is no big deal - I tested it with one of the quickstarts. So, my point is... while from a purest standpoint it might be "nicer" to not ship EJB3 (or whatever) as part of the esb-server, it certainly seems as though it might make life easier in a lot of situations - both for us and the user. Once we have a fancy installer we can make things optional. Just my opinion. T. Mark Little wrote: > +1 > > > On 21 Mar 2007, at 22:03, Kurt T Stam wrote: > >> Good question. And we will have this discussion for JBESB-5.0: "Even >> when everything is pluggable, What comes standard in it?". My >> feeling is >> that is should not come with JBESB by default as it is not core to >> SOA/ESB, but if we really should have some installer functionality we >> could make it easy to add them in, just like adding the ftp server, >> email server etc. I looked into using the izPack thing before, which >> looks pretty nice. We some customized version in JBossAS, which allows >> remote installs etc. I think that may be the way to go (after MP1). >> >> Bill Burke wrote: >>> Do we want to add EJB3 for busines_service? Probably add another >>> 4meg to the distro. But we would have Hibernate too. Eventually >>> somebody will write the Hibernate/JPA actions that Burr suggested >>> during the meeting in Westford. >>> >>> Kurt T Stam wrote: >>>> Starting work on more_action >>>> >>>> TODO >>>> >>>> business_service (this is ejb3, and will require deploying to the >>>> appserver) >>>> webservice_war1 (this requires a WS stack, which also requires the >>>> appserver). >>>> >>>> >>>> >>>> >>>> Mark Little wrote: >>>>> I thought we decided on today's SILC meeting to postpone the jBPM >>>>> demo because of lack of time? >>>>> >>>>> Mark. >>>>> >>>>> >>>>> On 21 Mar 2007, at 18:44, Kurt T Stam wrote: >>>>> >>>>>> OK I think we should leave aggregator alone, as it has no real >>>>>> deployment now. I'm starting on fun_cbr. >>>>>> >>>>>> TODO: >>>>>> >>>>>> business_service >>>>>> webservice_war1 >>>>>> jbpm_simple1 >>>>>> more_action >>>>>> >>>>>> Kurt T Stam wrote: >>>>>>> The work that needs be done is building an .esb archive much like >>>>>>> the custom-action.jar but in addition it need to contain >>>>>>> a jboss-esb.xml in META-INF, and then changing the deployToSAR >>>>>>> task to deploy, which should deploy this archive to the >>>>>>> server/default/deploy directory. If the sample contains queue >>>>>>> definitions you may add this to the root of the .esb archive. >>>>>>> >>>>>>> For most samples I'm leaving the "ant run" task to start esb >>>>>>> through the bootstrapper. >>>>>>> >>>>>>> I'm taking static_router and simple_cbr right now. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> --Kurt >>>>>>> >>>>>>> Kurt T Stam wrote: >>>>>>>> TODO: >>>>>>>> aggregator >>>>>>>> business_service >>>>>>>> fun_cbr >>>>>>>> webservice_war1 >>>>>>>> jbpm_simple1 >>>>>>>> more_action >>>>>>>> simple_cbr >>>>>>>> static_router >>>>>>>> >>>>>>>> DONE: >>>>>>>> helloworld >>>>>>>> helloworld_action >>>>>>>> helloworld_db_registration >>>>>>>> helloworld_file_action >>>>>>>> helloworld_ftp_action >>>>>>>> helloworld_sql_action (I'm currently working on this one) >>>>>>>> scripting_groovy >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Bill Burke wrote: >>>>>>>> >>>>>>>>> We want to port the samples to the new .esb deployment right? >>>>>>>>> Divide >>>>>>>>> an conquer here? We each take a few? >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> esb-dev mailing list >>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>> >>>>>> _______________________________________________ >>>>>> esb-dev mailing list >>>>>> esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> >>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> esb-dev mailing list >>>> esb-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>> >> > > _______________________________________________ > esb-dev mailing list > esb-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/esb-dev _______________________________________________ esb-dev mailing list esb-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/esb-dev

Good question. And we will have this discussion for JBESB-5.0: "Even when everything is pluggable, What comes standard in it?". My feeling is that is should not come with JBESB by default as it is not core to SOA/ESB, but if we really should have some installer functionality we could make it easy to add them in, just like adding the ftp server, email server etc. I looked into using the izPack thing before, which looks pretty nice. We some customized version in JBossAS, which allows remote installs etc. I think that may be the way to go (after MP1). Bill Burke wrote: > Do we want to add EJB3 for busines_service? Probably add another > 4meg to the distro. But we would have Hibernate too. Eventually > somebody will write the Hibernate/JPA actions that Burr suggested > during the meeting in Westford. > > Kurt T Stam wrote: > >> Starting work on more_action >> >> TODO >> >> business_service (this is ejb3, and will require deploying to the >> appserver) >> webservice_war1 (this requires a WS stack, which also requires the >> appserver). >> >> >> >> >> Mark Little wrote: >> >>> I thought we decided on today's SILC meeting to postpone the jBPM >>> demo because of lack of time? >>> >>> Mark. >>> >>> >>> On 21 Mar 2007, at 18:44, Kurt T Stam wrote: >>> >>> >>>> OK I think we should leave aggregator alone, as it has no real >>>> deployment now. I'm starting on fun_cbr. >>>> >>>> TODO: >>>> >>>> business_service >>>> webservice_war1 >>>> jbpm_simple1 >>>> more_action >>>> >>>> Kurt T Stam wrote: >>>> >>>>> The work that needs be done is building an .esb archive much like >>>>> the custom-action.jar but in addition it need to contain >>>>> a jboss-esb.xml in META-INF, and then changing the deployToSAR >>>>> task to deploy, which should deploy this archive to the >>>>> server/default/deploy directory. If the sample contains queue >>>>> definitions you may add this to the root of the .esb archive. >>>>> >>>>> For most samples I'm leaving the "ant run" task to start esb >>>>> through the bootstrapper. >>>>> >>>>> I'm taking static_router and simple_cbr right now. >>>>> >>>>> Cheers, >>>>> >>>>> --Kurt >>>>> >>>>> Kurt T Stam wrote: >>>>> >>>>>> TODO: >>>>>> aggregator >>>>>> business_service >>>>>> fun_cbr >>>>>> webservice_war1 >>>>>> jbpm_simple1 >>>>>> more_action >>>>>> simple_cbr >>>>>> static_router >>>>>> >>>>>> DONE: >>>>>> helloworld >>>>>> helloworld_action >>>>>> helloworld_db_registration >>>>>> helloworld_file_action >>>>>> helloworld_ftp_action >>>>>> helloworld_sql_action (I'm currently working on this one) >>>>>> scripting_groovy >>>>>> >>>>>> >>>>>> >>>>>> Bill Burke wrote: >>>>>> >>>>>> >>>>>>> We want to port the samples to the new .esb deployment right? >>>>>>> Divide >>>>>>> an conquer here? We each take a few? >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> esb-dev mailing list >>>>>> esb-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>> >>>>>> >>>> _______________________________________________ >>>> esb-dev mailing list >>>> esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> esb-dev mailing list >> esb-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/esb-dev >> _______________________________________________ esb-dev mailing list esb-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/esb-dev

+1 to Burr. Everything should run out of the box. All the examples, etc. I disagree on not having business logic in actions. Users will want an integrated experience, one-stop shop for where they do things, IMO. If business logic is implemented as an annotated EJB its not such a big deal, as in JBOss 5 we'll be able to have a .jar that deploys both ESB and EJB at the same time instead of keeping them separate like in JBoss 4.x. But for other component architectures, like Spring, we'll want to inline them in ESB XML configuration. Bill Burr Sutter wrote: > We did talk about having a "hibernate listener" and we'll > eventually want web services as well in the default "ESB server". > So that begins to pull in a lot of other components. I'm less > worried about the size and more focused on the "out-of-the-box- > experience". The average end-user will want to use the WS > capabilities immediately upon installation. Perhaps 30%+ on the > hibernate feature. > In any case, I'm always trying to make the point that you need to > think differently about your technical mediation services vs your > business services. Your business logic should NOT be in ESB > custom actions. Custom actions are there to build custom > mediation "interceptors" but business logic should live where it > currently lives in EJBs, WSs, Spring beans, POJOs, Struts actions, > etc. So in the case of the business_service quickstart we need to > change the documentation so it tells the user how to run both > engines simultaneously. The webservice_war1 should be deployable > completely on the ESB server without the App Server. > Kurt T Stam wrote: >> Good question. And we will have this discussion for JBESB-5.0: "Even >> when everything is pluggable, What comes standard in it?". My >> feeling is >> that is should not come with JBESB by default as it is not core to >> SOA/ESB, but if we really should have some installer >> functionality we >> could make it easy to add them in, just like adding the ftp server, >> email server etc. I looked into using the izPack thing before, which >> looks pretty nice. We some customized version in JBossAS, which >> allows >> remote installs etc. I think that may be the way to go (after MP1). >> >> Bill Burke wrote: >> >>> Do we want to add EJB3 for busines_service? Probably add another >>> 4meg to the distro. But we would have Hibernate too. Eventually >>> somebody will write the Hibernate/JPA actions that Burr suggested >>> during the meeting in Westford. >>> >>> Kurt T Stam wrote: >>> >>>> Starting work on more_action >>>> >>>> TODO >>>> >>>> business_service (this is ejb3, and will require deploying to the >>>> appserver) >>>> webservice_war1 (this requires a WS stack, which also requires >>>> the >>>> appserver). >>>> >>>> >>>> >>>> >>>> Mark Little wrote: >>>> >>>>> I thought we decided on today's SILC meeting to postpone the jBPM >>>>> demo because of lack of time? >>>>> >>>>> Mark. >>>>> >>>>> >>>>> On 21 Mar 2007, at 18:44, Kurt T Stam wrote: >>>>> >>>>> >>>>>> OK I think we should leave aggregator alone, as it has no real >>>>>> deployment now. I'm starting on fun_cbr. >>>>>> >>>>>> TODO: >>>>>> >>>>>> business_service >>>>>> webservice_war1 >>>>>> jbpm_simple1 >>>>>> more_action >>>>>> >>>>>> Kurt T Stam wrote: >>>>>> >>>>>>> The work that needs be done is building an .esb archive much >>>>>>> like >>>>>>> the custom-action.jar but in addition it need to contain >>>>>>> a jboss-esb.xml in META-INF, and then changing the deployToSAR >>>>>>> task to deploy, which should deploy this archive to the >>>>>>> server/default/deploy directory. If the sample contains queue >>>>>>> definitions you may add this to the root of the .esb archive. >>>>>>> >>>>>>> For most samples I'm leaving the "ant run" task to start esb >>>>>>> through the bootstrapper. >>>>>>> >>>>>>> I'm taking static_router and simple_cbr right now. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> --Kurt >>>>>>> >>>>>>> Kurt T Stam wrote: >>>>>>> >>>>>>>> TODO: >>>>>>>> aggregator >>>>>>>> business_service >>>>>>>> fun_cbr >>>>>>>> webservice_war1 >>>>>>>> jbpm_simple1 >>>>>>>> more_action >>>>>>>> simple_cbr >>>>>>>> static_router >>>>>>>> >>>>>>>> DONE: >>>>>>>> helloworld >>>>>>>> helloworld_action >>>>>>>> helloworld_db_registration >>>>>>>> helloworld_file_action >>>>>>>> helloworld_ftp_action >>>>>>>> helloworld_sql_action (I'm currently working on this one) >>>>>>>> scripting_groovy >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Bill Burke wrote: >>>>>>>> >>>>>>>>> We want to port the samples to the new .esb deployment >>>>>>>>> right? Divide >>>>>>>>> an conquer here? We each take a few? >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> esb-dev mailing list >>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>> >>>>>> _______________________________________________ >>>>>> esb-dev mailing list >>>>>> esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> >>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>> >>>> ------------------------------------------------------------------ >>>> ------ >>>> >>>> _______________________________________________ >>>> esb-dev mailing list >>>> esb-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>> >> >> _______________________________________________ >> esb-dev mailing list >> esb-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/esb-dev >> -- Bill Burke JBoss, a division of Red Hat Inc. _______________________________________________ esb-dev mailing list esb-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/esb-dev

Whether or not it shouldn't be done, people will want it. XDoclet/ annotations are a prime example of how people want their metadata in one place. Servicemix also mixes business logic with message flow/service definition. jBPM is even more interesting in this regard. The IoC information, I believe, is part of the process definition metadata. What's interesting is that if you make the message flow definition tag along with the message, even configuration information can be propagated. So "smart messages" could not only know how to route themselves, they know how to configure the actions that travel along with them. Bill Mark Little wrote: > I think the problem we have at the moment is that the actions are > the closest thing we have to "service definitions", when in fact > they aren't really (or shouldn't be IMO). > Mark. > On 22 Mar 2007, at 12:12, Bill Burke wrote: >> +1 to Burr. Everything should run out of the box. All the >> examples, etc. >> >> I disagree on not having business logic in actions. Users will >> want an integrated experience, one-stop shop for where they do >> things, IMO. If business logic is implemented as an annotated >> EJB its not such a big deal, as in JBOss 5 we'll be able to have >> a .jar that deploys both ESB and EJB at the same time instead of >> keeping them separate like in JBoss 4.x. But for other component >> architectures, like Spring, we'll want to inline them in ESB XML >> configuration. >> >> Bill >> >> Burr Sutter wrote: >>> We did talk about having a "hibernate listener" and we'll >>> eventually want web services as well in the default "ESB >>> server". So that begins to pull in a lot of other components. >>> I'm less worried about the size and more focused on the "out-of- >>> the-box-experience". The average end-user will want to use the >>> WS capabilities immediately upon installation. Perhaps 30%+ on >>> the hibernate feature. >>> In any case, I'm always trying to make the point that you need >>> to think differently about your technical mediation services vs >>> your business services. Your business logic should NOT be in >>> ESB custom actions. Custom actions are there to build custom >>> mediation "interceptors" but business logic should live where it >>> currently lives in EJBs, WSs, Spring beans, POJOs, Struts >>> actions, etc. So in the case of the business_service quickstart >>> we need to change the documentation so it tells the user how to >>> run both engines simultaneously. The webservice_war1 should be >>> deployable completely on the ESB server without the App Server. >>> Kurt T Stam wrote: >>>> Good question. And we will have this discussion for JBESB-5.0: >>>> "Even >>>> when everything is pluggable, What comes standard in it?". My >>>> feeling is >>>> that is should not come with JBESB by default as it is not core to >>>> SOA/ESB, but if we really should have some installer >>>> functionality we >>>> could make it easy to add them in, just like adding the ftp >>>> server, >>>> email server etc. I looked into using the izPack thing before, >>>> which >>>> looks pretty nice. We some customized version in JBossAS, which >>>> allows >>>> remote installs etc. I think that may be the way to go (after >>>> MP1). >>>> >>>> Bill Burke wrote: >>>> >>>>> Do we want to add EJB3 for busines_service? Probably add >>>>> another >>>>> 4meg to the distro. But we would have Hibernate too. Eventually >>>>> somebody will write the Hibernate/JPA actions that Burr suggested >>>>> during the meeting in Westford. >>>>> >>>>> Kurt T Stam wrote: >>>>> >>>>>> Starting work on more_action >>>>>> >>>>>> TODO >>>>>> >>>>>> business_service (this is ejb3, and will require deploying to >>>>>> the >>>>>> appserver) >>>>>> webservice_war1 (this requires a WS stack, which also >>>>>> requires the >>>>>> appserver). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Mark Little wrote: >>>>>> >>>>>>> I thought we decided on today's SILC meeting to postpone the >>>>>>> jBPM >>>>>>> demo because of lack of time? >>>>>>> >>>>>>> Mark. >>>>>>> >>>>>>> >>>>>>> On 21 Mar 2007, at 18:44, Kurt T Stam wrote: >>>>>>> >>>>>>> >>>>>>>> OK I think we should leave aggregator alone, as it has no real >>>>>>>> deployment now. I'm starting on fun_cbr. >>>>>>>> >>>>>>>> TODO: >>>>>>>> >>>>>>>> business_service >>>>>>>> webservice_war1 >>>>>>>> jbpm_simple1 >>>>>>>> more_action >>>>>>>> >>>>>>>> Kurt T Stam wrote: >>>>>>>> >>>>>>>>> The work that needs be done is building an .esb archive >>>>>>>>> much like >>>>>>>>> the custom-action.jar but in addition it need to contain >>>>>>>>> a jboss-esb.xml in META-INF, and then changing the >>>>>>>>> deployToSAR >>>>>>>>> task to deploy, which should deploy this archive to the >>>>>>>>> server/default/deploy directory. If the sample contains queue >>>>>>>>> definitions you may add this to the root of the .esb archive. >>>>>>>>> >>>>>>>>> For most samples I'm leaving the "ant run" task to start esb >>>>>>>>> through the bootstrapper. >>>>>>>>> >>>>>>>>> I'm taking static_router and simple_cbr right now. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> --Kurt >>>>>>>>> >>>>>>>>> Kurt T Stam wrote: >>>>>>>>> >>>>>>>>>> TODO: >>>>>>>>>> aggregator >>>>>>>>>> business_service >>>>>>>>>> fun_cbr >>>>>>>>>> webservice_war1 >>>>>>>>>> jbpm_simple1 >>>>>>>>>> more_action >>>>>>>>>> simple_cbr >>>>>>>>>> static_router >>>>>>>>>> >>>>>>>>>> DONE: >>>>>>>>>> helloworld >>>>>>>>>> helloworld_action >>>>>>>>>> helloworld_db_registration >>>>>>>>>> helloworld_file_action >>>>>>>>>> helloworld_ftp_action >>>>>>>>>> helloworld_sql_action (I'm currently working on this one) >>>>>>>>>> scripting_groovy >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Bill Burke wrote: >>>>>>>>>> >>>>>>>>>>> We want to port the samples to the new .esb deployment >>>>>>>>>>> right? Divide >>>>>>>>>>> an conquer here? We each take a few? >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> esb-dev mailing list >>>>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> esb-dev mailing list >>>>>>>> esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> >>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>> >>>>>> ---------------------------------------------------------------- >>>>>> -------- >>>>>> >>>>>> _______________________________________________ >>>>>> esb-dev mailing list >>>>>> esb-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>> >>>> >>>> _______________________________________________ >>>> esb-dev mailing list >>>> esb-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>> >> >> --Bill Burke >> JBoss, a division of Red Hat Inc. >> _______________________________________________ >> esb-dev mailing list >> esb-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/esb-dev -- Bill Burke JBoss, a division of Red Hat Inc.

On this subject, I remember a long time back Tom and I were talking about flowing the entire Action chaining information (or portions of it) along with messages, so you can dynamically build up the chain at the receiver as the message is processed. Combining that with Rules would give you some interesting dynamic reconfiguration options for the server-side processing. Mark. On 22 Mar 2007, at 15:59, Mark Little wrote: > Smart messages are something we've been talking about for a while. > Tagging rules onto messages is one way that I've been talking with > Proctor about since last year. The idea of distributing new > configuration information is interesting and I think we touched on it > in Boston. Though I think at that time the topic was about global ESB > management and configuration updates, rather than just the actions. > > Mark. > > > On 22 Mar 2007, at 15:54, Bill Burke wrote: > >> Whether or not it shouldn't be done, people will want it. >> XDoclet/annotations are a prime example of how people want their >> metadata in one place. Servicemix also mixes business logic with >> message flow/service definition. >> >> jBPM is even more interesting in this regard. The IoC information, >> I believe, is part of the process definition metadata. What's >> interesting is that if you make the message flow definition tag >> along with the message, even configuration information can be >> propagated. So "smart messages" could not only know how to route >> themselves, they know how to configure the actions that travel along >> with them. >> >> Bill >> >> Mark Little wrote: >>> I think the problem we have at the moment is that the actions are >>> the closest thing we have to "service definitions", when in fact >>> they aren't really (or shouldn't be IMO). >>> Mark. >>> On 22 Mar 2007, at 12:12, Bill Burke wrote: >>>> +1 to Burr. Everything should run out of the box. All the >>>> examples, etc. >>>> >>>> I disagree on not having business logic in actions. Users will >>>> want an integrated experience, one-stop shop for where they do >>>> things, IMO. If business logic is implemented as an annotated EJB >>>> its not such a big deal, as in JBOss 5 we'll be able to have a >>>> .jar that deploys both ESB and EJB at the same time instead of >>>> keeping them separate like in JBoss 4.x. But for other component >>>> architectures, like Spring, we'll want to inline them in ESB XML >>>> configuration. >>>> >>>> Bill >>>> >>>> Burr Sutter wrote: >>>>> We did talk about having a "hibernate listener" and we'll >>>>> eventually want web services as well in the default "ESB >>>>> server". So that begins to pull in a lot of other components. >>>>> I'm less worried about the size and more focused on the >>>>> "out-of-the-box-experience". The average end-user will want to >>>>> use the WS capabilities immediately upon installation. Perhaps >>>>> 30%+ on the hibernate feature. >>>>> In any case, I'm always trying to make the point that you need to >>>>> think differently about your technical mediation services vs your >>>>> business services. Your business logic should NOT be in ESB >>>>> custom actions. Custom actions are there to build custom >>>>> mediation "interceptors" but business logic should live where it >>>>> currently lives in EJBs, WSs, Spring beans, POJOs, Struts >>>>> actions, etc. So in the case of the business_service quickstart >>>>> we need to change the documentation so it tells the user how to >>>>> run both engines simultaneously. The webservice_war1 should be >>>>> deployable completely on the ESB server without the App Server. >>>>> Kurt T Stam wrote: >>>>>> Good question. And we will have this discussion for JBESB-5.0: >>>>>> "Even >>>>>> when everything is pluggable, What comes standard in it?". My >>>>>> feeling is >>>>>> that is should not come with JBESB by default as it is not core to >>>>>> SOA/ESB, but if we really should have some installer >>>>>> functionality we >>>>>> could make it easy to add them in, just like adding the ftp server, >>>>>> email server etc. I looked into using the izPack thing before, >>>>>> which >>>>>> looks pretty nice. We some customized version in JBossAS, which >>>>>> allows >>>>>> remote installs etc. I think that may be the way to go (after MP1). >>>>>> >>>>>> Bill Burke wrote: >>>>>> >>>>>>> Do we want to add EJB3 for busines_service? Probably add another >>>>>>> 4meg to the distro. But we would have Hibernate too. Eventually >>>>>>> somebody will write the Hibernate/JPA actions that Burr suggested >>>>>>> during the meeting in Westford. >>>>>>> >>>>>>> Kurt T Stam wrote: >>>>>>> >>>>>>>> Starting work on more_action >>>>>>>> >>>>>>>> TODO >>>>>>>> >>>>>>>> business_service (this is ejb3, and will require deploying to the >>>>>>>> appserver) >>>>>>>> webservice_war1 (this requires a WS stack, which also >>>>>>>> requires the >>>>>>>> appserver). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Mark Little wrote: >>>>>>>> >>>>>>>>> I thought we decided on today's SILC meeting to postpone the >>>>>>>>> jBPM >>>>>>>>> demo because of lack of time? >>>>>>>>> >>>>>>>>> Mark. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 21 Mar 2007, at 18:44, Kurt T Stam wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> OK I think we should leave aggregator alone, as it has no real >>>>>>>>>> deployment now. I'm starting on fun_cbr. >>>>>>>>>> >>>>>>>>>> TODO: >>>>>>>>>> >>>>>>>>>> business_service >>>>>>>>>> webservice_war1 >>>>>>>>>> jbpm_simple1 >>>>>>>>>> more_action >>>>>>>>>> >>>>>>>>>> Kurt T Stam wrote: >>>>>>>>>> >>>>>>>>>>> The work that needs be done is building an .esb archive >>>>>>>>>>> much like >>>>>>>>>>> the custom-action.jar but in addition it need to contain >>>>>>>>>>> a jboss-esb.xml in META-INF, and then changing the deployToSAR >>>>>>>>>>> task to deploy, which should deploy this archive to the >>>>>>>>>>> server/default/deploy directory. If the sample contains queue >>>>>>>>>>> definitions you may add this to the root of the .esb archive. >>>>>>>>>>> >>>>>>>>>>> For most samples I'm leaving the "ant run" task to start esb >>>>>>>>>>> through the bootstrapper. >>>>>>>>>>> >>>>>>>>>>> I'm taking static_router and simple_cbr right now. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> >>>>>>>>>>> --Kurt >>>>>>>>>>> >>>>>>>>>>> Kurt T Stam wrote: >>>>>>>>>>> >>>>>>>>>>>> TODO: >>>>>>>>>>>> aggregator >>>>>>>>>>>> business_service >>>>>>>>>>>> fun_cbr >>>>>>>>>>>> webservice_war1 >>>>>>>>>>>> jbpm_simple1 >>>>>>>>>>>> more_action >>>>>>>>>>>> simple_cbr >>>>>>>>>>>> static_router >>>>>>>>>>>> >>>>>>>>>>>> DONE: >>>>>>>>>>>> helloworld >>>>>>>>>>>> helloworld_action >>>>>>>>>>>> helloworld_db_registration >>>>>>>>>>>> helloworld_file_action >>>>>>>>>>>> helloworld_ftp_action >>>>>>>>>>>> helloworld_sql_action (I'm currently working on this one) >>>>>>>>>>>> scripting_groovy >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Bill Burke wrote: >>>>>>>>>>>> >>>>>>>>>>>>> We want to port the samples to the new .esb deployment >>>>>>>>>>>>> right? Divide >>>>>>>>>>>>> an conquer here? We each take a few? >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> esb-dev mailing list >>>>>>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> esb-dev mailing list >>>>>>>>>> esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> esb-dev mailing list >>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> esb-dev mailing list >>>>>> esb-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>> >>>> >>>> --Bill Burke >>>> JBoss, a division of Red Hat Inc. >>>> _______________________________________________ >>>> esb-dev mailing list >>>> esb-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/esb-dev >> >> --Bill Burke >> JBoss, a division of Red Hat Inc. > > _______________________________________________ > esb-dev mailing list > esb-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/esb-dev _______________________________________________ esb-dev mailing list esb-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/esb-dev

I'd like to have a conference call on this particular topic. It is tough to discuss via email. It is important that we clearly articulate how people build ESB-based applications and "actions" where not intended as the business logic-based endpoints. WS, EJB, etc were supposed to be those endpoints. In the future SCA endpoints will be the business logic elements. ServiceMix team recommends 181 WS or Spring beans Mule recommends Spring beans Bill Burke wrote: > Whether or not it shouldn't be done, people will want it. XDoclet/ > annotations are a prime example of how people want their metadata > in one place. Servicemix also mixes business logic with message > flow/service definition. > > jBPM is even more interesting in this regard. The IoC > information, I believe, is part of the process definition > metadata. What's interesting is that if you make the message flow > definition tag along with the message, even configuration > information can be propagated. So "smart messages" could not only > know how to route themselves, they know how to configure the > actions that travel along with them. > > Bill > > Mark Little wrote: >> I think the problem we have at the moment is that the actions are >> the closest thing we have to "service definitions", when in fact >> they aren't really (or shouldn't be IMO). >> >> Mark. >> >> >> >> On 22 Mar 2007, at 12:12, Bill Burke wrote: >> >>> +1 to Burr. Everything should run out of the box. All the >>> examples, etc. >>> >>> I disagree on not having business logic in actions. Users will >>> want an integrated experience, one-stop shop for where they do >>> things, IMO. If business logic is implemented as an annotated >>> EJB its not such a big deal, as in JBOss 5 we'll be able to have >>> a .jar that deploys both ESB and EJB at the same time instead of >>> keeping them separate like in JBoss 4.x. But for other >>> component architectures, like Spring, we'll want to inline them >>> in ESB XML configuration. >>> >>> Bill >>> >>> Burr Sutter wrote: >>>> We did talk about having a "hibernate listener" and we'll >>>> eventually want web services as well in the default "ESB >>>> server". So that begins to pull in a lot of other >>>> components. I'm less worried about the size and more focused >>>> on the "out-of-the-box-experience". The average end-user will >>>> want to use the WS capabilities immediately upon installation. >>>> Perhaps 30%+ on the hibernate feature. >>>> In any case, I'm always trying to make the point that you need >>>> to think differently about your technical mediation services vs >>>> your business services. Your business logic should NOT be in >>>> ESB custom actions. Custom actions are there to build custom >>>> mediation "interceptors" but business logic should live where >>>> it currently lives in EJBs, WSs, Spring beans, POJOs, Struts >>>> actions, etc. So in the case of the business_service >>>> quickstart we need to change the documentation so it tells the >>>> user how to run both engines simultaneously. The >>>> webservice_war1 should be deployable completely on the ESB >>>> server without the App Server. >>>> Kurt T Stam wrote: >>>>> Good question. And we will have this discussion for JBESB-5.0: >>>>> "Even >>>>> when everything is pluggable, What comes standard in it?". My >>>>> feeling is >>>>> that is should not come with JBESB by default as it is not >>>>> core to >>>>> SOA/ESB, but if we really should have some installer >>>>> functionality we >>>>> could make it easy to add them in, just like adding the ftp >>>>> server, >>>>> email server etc. I looked into using the izPack thing before, >>>>> which >>>>> looks pretty nice. We some customized version in JBossAS, >>>>> which allows >>>>> remote installs etc. I think that may be the way to go (after >>>>> MP1). >>>>> >>>>> Bill Burke wrote: >>>>> >>>>>> Do we want to add EJB3 for busines_service? Probably add >>>>>> another >>>>>> 4meg to the distro. But we would have Hibernate too. >>>>>> Eventually >>>>>> somebody will write the Hibernate/JPA actions that Burr >>>>>> suggested >>>>>> during the meeting in Westford. >>>>>> >>>>>> Kurt T Stam wrote: >>>>>> >>>>>>> Starting work on more_action >>>>>>> >>>>>>> TODO >>>>>>> >>>>>>> business_service (this is ejb3, and will require deploying >>>>>>> to the >>>>>>> appserver) >>>>>>> webservice_war1 (this requires a WS stack, which also >>>>>>> requires the >>>>>>> appserver). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Mark Little wrote: >>>>>>> >>>>>>>> I thought we decided on today's SILC meeting to postpone >>>>>>>> the jBPM >>>>>>>> demo because of lack of time? >>>>>>>> >>>>>>>> Mark. >>>>>>>> >>>>>>>> >>>>>>>> On 21 Mar 2007, at 18:44, Kurt T Stam wrote: >>>>>>>> >>>>>>>> >>>>>>>>> OK I think we should leave aggregator alone, as it has no >>>>>>>>> real >>>>>>>>> deployment now. I'm starting on fun_cbr. >>>>>>>>> >>>>>>>>> TODO: >>>>>>>>> >>>>>>>>> business_service >>>>>>>>> webservice_war1 >>>>>>>>> jbpm_simple1 >>>>>>>>> more_action >>>>>>>>> >>>>>>>>> Kurt T Stam wrote: >>>>>>>>> >>>>>>>>>> The work that needs be done is building an .esb archive >>>>>>>>>> much like >>>>>>>>>> the custom-action.jar but in addition it need to contain >>>>>>>>>> a jboss-esb.xml in META-INF, and then changing the >>>>>>>>>> deployToSAR >>>>>>>>>> task to deploy, which should deploy this archive to the >>>>>>>>>> server/default/deploy directory. If the sample contains >>>>>>>>>> queue >>>>>>>>>> definitions you may add this to the root of the .esb >>>>>>>>>> archive. >>>>>>>>>> >>>>>>>>>> For most samples I'm leaving the "ant run" task to start esb >>>>>>>>>> through the bootstrapper. >>>>>>>>>> >>>>>>>>>> I'm taking static_router and simple_cbr right now. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> >>>>>>>>>> --Kurt >>>>>>>>>> >>>>>>>>>> Kurt T Stam wrote: >>>>>>>>>> >>>>>>>>>>> TODO: >>>>>>>>>>> aggregator >>>>>>>>>>> business_service >>>>>>>>>>> fun_cbr >>>>>>>>>>> webservice_war1 >>>>>>>>>>> jbpm_simple1 >>>>>>>>>>> more_action >>>>>>>>>>> simple_cbr >>>>>>>>>>> static_router >>>>>>>>>>> >>>>>>>>>>> DONE: >>>>>>>>>>> helloworld >>>>>>>>>>> helloworld_action >>>>>>>>>>> helloworld_db_registration >>>>>>>>>>> helloworld_file_action >>>>>>>>>>> helloworld_ftp_action >>>>>>>>>>> helloworld_sql_action (I'm currently working on this one) >>>>>>>>>>> scripting_groovy >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Bill Burke wrote: >>>>>>>>>>> >>>>>>>>>>>> We want to port the samples to the new .esb deployment >>>>>>>>>>>> right? Divide >>>>>>>>>>>> an conquer here? We each take a few? >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> esb-dev mailing list >>>>>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> esb-dev mailing list >>>>>>>>> esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> >>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>> >>>>>>> --------------------------------------------------------------- >>>>>>> --------- >>>>>>> >>>>>>> _______________________________________________ >>>>>>> esb-dev mailing list >>>>>>> esb-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>> >>>>> >>>>> _______________________________________________ >>>>> esb-dev mailing list >>>>> esb-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>> >>> >>> --Bill Burke >>> JBoss, a division of Red Hat Inc. >>> _______________________________________________ >>> esb-dev mailing list >>> esb-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/esb-dev >> >

Ideally we would recommend Seam components but Seam isn't yet ready for this sort of use case. However, I also like 181 WS as the business logic services. Mark Little wrote: > We can have a call, but it'll have to be next week. BTW, I don't > think we'll be recommending Spring beans ;-) > > Mark. > > > On 22 Mar 2007, at 17:59, Burr Sutter wrote: > >> I'd like to have a conference call on this particular topic. It >> is tough to discuss via email. It is important that we clearly >> articulate how people build ESB-based applications and "actions" >> where not intended as the business logic-based endpoints. WS, >> EJB, etc were supposed to be those endpoints. In the future SCA >> endpoints will be the business logic elements. >> >> ServiceMix team recommends 181 WS or Spring beans >> Mule recommends Spring beans >> >> >> Bill Burke wrote: >>> Whether or not it shouldn't be done, people will want it. >>> XDoclet/annotations are a prime example of how people want their >>> metadata in one place. Servicemix also mixes business logic >>> with message flow/service definition. >>> >>> jBPM is even more interesting in this regard. The IoC >>> information, I believe, is part of the process definition >>> metadata. What's interesting is that if you make the message >>> flow definition tag along with the message, even configuration >>> information can be propagated. So "smart messages" could not >>> only know how to route themselves, they know how to configure >>> the actions that travel along with them. >>> >>> Bill >>> >>> Mark Little wrote: >>>> I think the problem we have at the moment is that the actions >>>> are the closest thing we have to "service definitions", when in >>>> fact they aren't really (or shouldn't be IMO). >>>> >>>> Mark. >>>> >>>> >>>> >>>> On 22 Mar 2007, at 12:12, Bill Burke wrote: >>>> >>>>> +1 to Burr. Everything should run out of the box. All the >>>>> examples, etc. >>>>> >>>>> I disagree on not having business logic in actions. Users >>>>> will want an integrated experience, one-stop shop for where >>>>> they do things, IMO. If business logic is implemented as an >>>>> annotated EJB its not such a big deal, as in JBOss 5 we'll be >>>>> able to have a .jar that deploys both ESB and EJB at the same >>>>> time instead of keeping them separate like in JBoss 4.x. But >>>>> for other component architectures, like Spring, we'll want to >>>>> inline them in ESB XML configuration. >>>>> >>>>> Bill >>>>> >>>>> Burr Sutter wrote: >>>>>> We did talk about having a "hibernate listener" and we'll >>>>>> eventually want web services as well in the default "ESB >>>>>> server". So that begins to pull in a lot of other >>>>>> components. I'm less worried about the size and more >>>>>> focused on the "out-of-the-box-experience". The average end- >>>>>> user will want to use the WS capabilities immediately upon >>>>>> installation. Perhaps 30%+ on the hibernate feature. >>>>>> In any case, I'm always trying to make the point that you >>>>>> need to think differently about your technical mediation >>>>>> services vs your business services. Your business logic >>>>>> should NOT be in ESB custom actions. Custom actions are >>>>>> there to build custom mediation "interceptors" but business >>>>>> logic should live where it currently lives in EJBs, WSs, >>>>>> Spring beans, POJOs, Struts actions, etc. So in the case of >>>>>> the business_service quickstart we need to change the >>>>>> documentation so it tells the user how to run both engines >>>>>> simultaneously. The webservice_war1 should be deployable >>>>>> completely on the ESB server without the App Server. >>>>>> Kurt T Stam wrote: >>>>>>> Good question. And we will have this discussion for >>>>>>> JBESB-5.0: "Even >>>>>>> when everything is pluggable, What comes standard in it?". >>>>>>> My feeling is >>>>>>> that is should not come with JBESB by default as it is not >>>>>>> core to >>>>>>> SOA/ESB, but if we really should have some installer >>>>>>> functionality we >>>>>>> could make it easy to add them in, just like adding the ftp >>>>>>> server, >>>>>>> email server etc. I looked into using the izPack thing >>>>>>> before, which >>>>>>> looks pretty nice. We some customized version in JBossAS, >>>>>>> which allows >>>>>>> remote installs etc. I think that may be the way to go >>>>>>> (after MP1). >>>>>>> >>>>>>> Bill Burke wrote: >>>>>>> >>>>>>>> Do we want to add EJB3 for busines_service? Probably add >>>>>>>> another >>>>>>>> 4meg to the distro. But we would have Hibernate too. >>>>>>>> Eventually >>>>>>>> somebody will write the Hibernate/JPA actions that Burr >>>>>>>> suggested >>>>>>>> during the meeting in Westford. >>>>>>>> >>>>>>>> Kurt T Stam wrote: >>>>>>>> >>>>>>>>> Starting work on more_action >>>>>>>>> >>>>>>>>> TODO >>>>>>>>> >>>>>>>>> business_service (this is ejb3, and will require deploying >>>>>>>>> to the >>>>>>>>> appserver) >>>>>>>>> webservice_war1 (this requires a WS stack, which also >>>>>>>>> requires the >>>>>>>>> appserver). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Mark Little wrote: >>>>>>>>> >>>>>>>>>> I thought we decided on today's SILC meeting to postpone >>>>>>>>>> the jBPM >>>>>>>>>> demo because of lack of time? >>>>>>>>>> >>>>>>>>>> Mark. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 21 Mar 2007, at 18:44, Kurt T Stam wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> OK I think we should leave aggregator alone, as it has >>>>>>>>>>> no real >>>>>>>>>>> deployment now. I'm starting on fun_cbr. >>>>>>>>>>> >>>>>>>>>>> TODO: >>>>>>>>>>> >>>>>>>>>>> business_service >>>>>>>>>>> webservice_war1 >>>>>>>>>>> jbpm_simple1 >>>>>>>>>>> more_action >>>>>>>>>>> >>>>>>>>>>> Kurt T Stam wrote: >>>>>>>>>>> >>>>>>>>>>>> The work that needs be done is building an .esb archive >>>>>>>>>>>> much like >>>>>>>>>>>> the custom-action.jar but in addition it need to contain >>>>>>>>>>>> a jboss-esb.xml in META-INF, and then changing the >>>>>>>>>>>> deployToSAR >>>>>>>>>>>> task to deploy, which should deploy this archive to the >>>>>>>>>>>> server/default/deploy directory. If the sample contains >>>>>>>>>>>> queue >>>>>>>>>>>> definitions you may add this to the root of the .esb >>>>>>>>>>>> archive. >>>>>>>>>>>> >>>>>>>>>>>> For most samples I'm leaving the "ant run" task to >>>>>>>>>>>> start esb >>>>>>>>>>>> through the bootstrapper. >>>>>>>>>>>> >>>>>>>>>>>> I'm taking static_router and simple_cbr right now. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> >>>>>>>>>>>> --Kurt >>>>>>>>>>>> >>>>>>>>>>>> Kurt T Stam wrote: >>>>>>>>>>>> >>>>>>>>>>>>> TODO: >>>>>>>>>>>>> aggregator >>>>>>>>>>>>> business_service >>>>>>>>>>>>> fun_cbr >>>>>>>>>>>>> webservice_war1 >>>>>>>>>>>>> jbpm_simple1 >>>>>>>>>>>>> more_action >>>>>>>>>>>>> simple_cbr >>>>>>>>>>>>> static_router >>>>>>>>>>>>> >>>>>>>>>>>>> DONE: >>>>>>>>>>>>> helloworld >>>>>>>>>>>>> helloworld_action >>>>>>>>>>>>> helloworld_db_registration >>>>>>>>>>>>> helloworld_file_action >>>>>>>>>>>>> helloworld_ftp_action >>>>>>>>>>>>> helloworld_sql_action (I'm currently working on this one) >>>>>>>>>>>>> scripting_groovy >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Bill Burke wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> We want to port the samples to the new .esb >>>>>>>>>>>>>> deployment right? Divide >>>>>>>>>>>>>> an conquer here? We each take a few? >>>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> esb-dev mailing list >>>>>>>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> esb-dev mailing list >>>>>>>>>>> esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>>>> >>>>>>>>> ------------------------------------------------------------- >>>>>>>>> ----------- >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> esb-dev mailing list >>>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> esb-dev mailing list >>>>>>> esb-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>> >>>>> >>>>> --Bill Burke >>>>> JBoss, a division of Red Hat Inc. >>>>> _______________________________________________ >>>>> esb-dev mailing list >>>>> esb-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>> >>> >

Good point. JBI 2.0 should specify the end-user's component development model even if they just leverage the work done in the SCA project. Mark Little wrote: > 181 makes sense in a Web Services environment. I'm sure we've talked > about this last year, but what I'd like to see is something similar > defined in JBI 2.0. > > Mark. > > > On 22 Mar 2007, at 18:36, Burr Sutter wrote: > >> Ideally we would recommend Seam components but Seam isn't yet ready >> for this sort of use case. However, I also like 181 WS as the >> business logic services. >> >> >> Mark Little wrote: >>> We can have a call, but it'll have to be next week. BTW, I don't >>> think we'll be recommending Spring beans ;-) >>> >>> Mark. >>> >>> >>> On 22 Mar 2007, at 17:59, Burr Sutter wrote: >>> >>>> I'd like to have a conference call on this particular topic. It is >>>> tough to discuss via email. It is important that we clearly >>>> articulate how people build ESB-based applications and "actions" >>>> where not intended as the business logic-based endpoints. WS, EJB, >>>> etc were supposed to be those endpoints. In the future SCA >>>> endpoints will be the business logic elements. >>>> >>>> ServiceMix team recommends 181 WS or Spring beans >>>> Mule recommends Spring beans >>>> >>>> >>>> Bill Burke wrote: >>>>> Whether or not it shouldn't be done, people will want it. >>>>> XDoclet/annotations are a prime example of how people want their >>>>> metadata in one place. Servicemix also mixes business logic with >>>>> message flow/service definition. >>>>> >>>>> jBPM is even more interesting in this regard. The IoC >>>>> information, I believe, is part of the process definition >>>>> metadata. What's interesting is that if you make the message flow >>>>> definition tag along with the message, even configuration >>>>> information can be propagated. So "smart messages" could not only >>>>> know how to route themselves, they know how to configure the >>>>> actions that travel along with them. >>>>> >>>>> Bill >>>>> >>>>> Mark Little wrote: >>>>>> I think the problem we have at the moment is that the actions are >>>>>> the closest thing we have to "service definitions", when in fact >>>>>> they aren't really (or shouldn't be IMO). >>>>>> >>>>>> Mark. >>>>>> >>>>>> >>>>>> >>>>>> On 22 Mar 2007, at 12:12, Bill Burke wrote: >>>>>> >>>>>>> +1 to Burr. Everything should run out of the box. All the >>>>>>> examples, etc. >>>>>>> >>>>>>> I disagree on not having business logic in actions. Users will >>>>>>> want an integrated experience, one-stop shop for where they do >>>>>>> things, IMO. If business logic is implemented as an annotated >>>>>>> EJB its not such a big deal, as in JBOss 5 we'll be able to have >>>>>>> a .jar that deploys both ESB and EJB at the same time instead of >>>>>>> keeping them separate like in JBoss 4.x. But for other >>>>>>> component architectures, like Spring, we'll want to inline them >>>>>>> in ESB XML configuration. >>>>>>> >>>>>>> Bill >>>>>>> >>>>>>> Burr Sutter wrote: >>>>>>>> We did talk about having a "hibernate listener" and we'll >>>>>>>> eventually want web services as well in the default "ESB >>>>>>>> server". So that begins to pull in a lot of other >>>>>>>> components. I'm less worried about the size and more focused >>>>>>>> on the "out-of-the-box-experience". The average end-user will >>>>>>>> want to use the WS capabilities immediately upon installation. >>>>>>>> Perhaps 30%+ on the hibernate feature. >>>>>>>> In any case, I'm always trying to make the point that you need >>>>>>>> to think differently about your technical mediation services vs >>>>>>>> your business services. Your business logic should NOT be in >>>>>>>> ESB custom actions. Custom actions are there to build custom >>>>>>>> mediation "interceptors" but business logic should live where >>>>>>>> it currently lives in EJBs, WSs, Spring beans, POJOs, Struts >>>>>>>> actions, etc. So in the case of the business_service >>>>>>>> quickstart we need to change the documentation so it tells the >>>>>>>> user how to run both engines simultaneously. The >>>>>>>> webservice_war1 should be deployable completely on the ESB >>>>>>>> server without the App Server. >>>>>>>> Kurt T Stam wrote: >>>>>>>>> Good question. And we will have this discussion for JBESB-5.0: >>>>>>>>> "Even >>>>>>>>> when everything is pluggable, What comes standard in it?". My >>>>>>>>> feeling is >>>>>>>>> that is should not come with JBESB by default as it is not >>>>>>>>> core to >>>>>>>>> SOA/ESB, but if we really should have some installer >>>>>>>>> functionality we >>>>>>>>> could make it easy to add them in, just like adding the ftp >>>>>>>>> server, >>>>>>>>> email server etc. I looked into using the izPack thing before, >>>>>>>>> which >>>>>>>>> looks pretty nice. We some customized version in JBossAS, >>>>>>>>> which allows >>>>>>>>> remote installs etc. I think that may be the way to go (after >>>>>>>>> MP1). >>>>>>>>> >>>>>>>>> Bill Burke wrote: >>>>>>>>> >>>>>>>>>> Do we want to add EJB3 for busines_service? Probably add >>>>>>>>>> another >>>>>>>>>> 4meg to the distro. But we would have Hibernate too. >>>>>>>>>> Eventually >>>>>>>>>> somebody will write the Hibernate/JPA actions that Burr >>>>>>>>>> suggested >>>>>>>>>> during the meeting in Westford. >>>>>>>>>> >>>>>>>>>> Kurt T Stam wrote: >>>>>>>>>> >>>>>>>>>>> Starting work on more_action >>>>>>>>>>> >>>>>>>>>>> TODO >>>>>>>>>>> >>>>>>>>>>> business_service (this is ejb3, and will require deploying >>>>>>>>>>> to the >>>>>>>>>>> appserver) >>>>>>>>>>> webservice_war1 (this requires a WS stack, which also >>>>>>>>>>> requires the >>>>>>>>>>> appserver). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Mark Little wrote: >>>>>>>>>>> >>>>>>>>>>>> I thought we decided on today's SILC meeting to postpone >>>>>>>>>>>> the jBPM >>>>>>>>>>>> demo because of lack of time? >>>>>>>>>>>> >>>>>>>>>>>> Mark. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 21 Mar 2007, at 18:44, Kurt T Stam wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> OK I think we should leave aggregator alone, as it has no >>>>>>>>>>>>> real >>>>>>>>>>>>> deployment now. I'm starting on fun_cbr. >>>>>>>>>>>>> >>>>>>>>>>>>> TODO: >>>>>>>>>>>>> >>>>>>>>>>>>> business_service >>>>>>>>>>>>> webservice_war1 >>>>>>>>>>>>> jbpm_simple1 >>>>>>>>>>>>> more_action >>>>>>>>>>>>> >>>>>>>>>>>>> Kurt T Stam wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> The work that needs be done is building an .esb archive >>>>>>>>>>>>>> much like >>>>>>>>>>>>>> the custom-action.jar but in addition it need to contain >>>>>>>>>>>>>> a jboss-esb.xml in META-INF, and then changing the >>>>>>>>>>>>>> deployToSAR >>>>>>>>>>>>>> task to deploy, which should deploy this archive to the >>>>>>>>>>>>>> server/default/deploy directory. If the sample contains >>>>>>>>>>>>>> queue >>>>>>>>>>>>>> definitions you may add this to the root of the .esb >>>>>>>>>>>>>> archive. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For most samples I'm leaving the "ant run" task to start esb >>>>>>>>>>>>>> through the bootstrapper. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm taking static_router and simple_cbr right now. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>> >>>>>>>>>>>>>> --Kurt >>>>>>>>>>>>>> >>>>>>>>>>>>>> Kurt T Stam wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> TODO: >>>>>>>>>>>>>>> aggregator >>>>>>>>>>>>>>> business_service >>>>>>>>>>>>>>> fun_cbr >>>>>>>>>>>>>>> webservice_war1 >>>>>>>>>>>>>>> jbpm_simple1 >>>>>>>>>>>>>>> more_action >>>>>>>>>>>>>>> simple_cbr >>>>>>>>>>>>>>> static_router >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> DONE: >>>>>>>>>>>>>>> helloworld >>>>>>>>>>>>>>> helloworld_action >>>>>>>>>>>>>>> helloworld_db_registration >>>>>>>>>>>>>>> helloworld_file_action >>>>>>>>>>>>>>> helloworld_ftp_action >>>>>>>>>>>>>>> helloworld_sql_action (I'm currently working on this one) >>>>>>>>>>>>>>> scripting_groovy >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Bill Burke wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We want to port the samples to the new .esb deployment >>>>>>>>>>>>>>>> right? Divide >>>>>>>>>>>>>>>> an conquer here? We each take a few? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> esb-dev mailing list >>>>>>>>>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> esb-dev mailing list >>>>>>>>>>>>> esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> >>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> esb-dev mailing list >>>>>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> esb-dev mailing list >>>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>> >>>>>>> >>>>>>> --Bill Burke >>>>>>> JBoss, a division of Red Hat Inc. >>>>>>> _______________________________________________ >>>>>>> esb-dev mailing list >>>>>>> esb-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>> >>>>> >>> >

I think we are showing innovation, but you're right that the higher level model we have at the moment is limiting. However, I've said before that EJBs have nothing to do with SOA. Just adding an EJB onto a Web Services stack doesn't give you SOA. What it does is give you CORBA with SOAP/HTTP transport. Tightly coupled interactions, brittle applications etc. That's not to say we shouldn't support EJBs, POJOs etc (we've been talking about that kind of support for a while), but there's more to an ESB/SOA model than just exposing individual objects. If you ever catch up with our mutual friend Steve Vinoski, he has a great view of how CORBA failed because people were encouraged to expose individual objects onto the CORBA "bus" rather than coarse grained services. Mark. On 22 Mar 2007, at 18:46, Bill Burke wrote: > I still think that jBPM should be the action framework. They already > have, or are going to want to have the same features as ESB's action > framework, plus more. Might as well work together. If you want to > integrate with something like BPEL, then integrate at the inbound > connector layer (the connector exposes a WS or BPEL friendly > interface), not as the action framework. > > No matter what, we should provide a simplified, default model. IMO, > it is absolutely ludricrous to have a 181 as your component model for > actions. Absolutely crazy. It provides zero value. A POJO model > with local EJBs or Spring/MC +/- Seam is what we should promote. > > We're JBoss. We lead, not follow. Take a page out of the Spring > playbook: Show innovation, integration, and added-value and you don't > have to follow these gay specs like JBI 2.0 and SCA. That's what Seam > did. > > Bill > > Burr Sutter wrote: >> Good point. JBI 2.0 should specify the end-user's component >> development model even if they just leverage the work done in the SCA >> project. >> Mark Little wrote: >>> 181 makes sense in a Web Services environment. I'm sure we've talked >>> about this last year, but what I'd like to see is something similar >>> defined in JBI 2.0. >>> >>> Mark. >>> >>> >>> On 22 Mar 2007, at 18:36, Burr Sutter wrote: >>> >>>> Ideally we would recommend Seam components but Seam isn't yet ready >>>> for this sort of use case. However, I also like 181 WS as the >>>> business logic services. >>>> >>>> >>>> Mark Little wrote: >>>>> We can have a call, but it'll have to be next week. BTW, I don't >>>>> think we'll be recommending Spring beans ;-) >>>>> >>>>> Mark. >>>>> >>>>> >>>>> On 22 Mar 2007, at 17:59, Burr Sutter wrote: >>>>> >>>>>> I'd like to have a conference call on this particular topic. It >>>>>> is tough to discuss via email. It is important that we clearly >>>>>> articulate how people build ESB-based applications and "actions" >>>>>> where not intended as the business logic-based endpoints. WS, >>>>>> EJB, etc were supposed to be those endpoints. In the future SCA >>>>>> endpoints will be the business logic elements. >>>>>> >>>>>> ServiceMix team recommends 181 WS or Spring beans >>>>>> Mule recommends Spring beans >>>>>> >>>>>> >>>>>> Bill Burke wrote: >>>>>>> Whether or not it shouldn't be done, people will want it. >>>>>>> XDoclet/annotations are a prime example of how people want their >>>>>>> metadata in one place. Servicemix also mixes business logic >>>>>>> with message flow/service definition. >>>>>>> >>>>>>> jBPM is even more interesting in this regard. The IoC >>>>>>> information, I believe, is part of the process definition >>>>>>> metadata. What's interesting is that if you make the message >>>>>>> flow definition tag along with the message, even configuration >>>>>>> information can be propagated. So "smart messages" could not >>>>>>> only know how to route themselves, they know how to configure >>>>>>> the actions that travel along with them. >>>>>>> >>>>>>> Bill >>>>>>> >>>>>>> Mark Little wrote: >>>>>>>> I think the problem we have at the moment is that the actions >>>>>>>> are the closest thing we have to "service definitions", when in >>>>>>>> fact they aren't really (or shouldn't be IMO). >>>>>>>> >>>>>>>> Mark. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 22 Mar 2007, at 12:12, Bill Burke wrote: >>>>>>>> >>>>>>>>> +1 to Burr. Everything should run out of the box. All the >>>>>>>>> examples, etc. >>>>>>>>> >>>>>>>>> I disagree on not having business logic in actions. Users >>>>>>>>> will want an integrated experience, one-stop shop for where >>>>>>>>> they do things, IMO. If business logic is implemented as an >>>>>>>>> annotated EJB its not such a big deal, as in JBOss 5 we'll be >>>>>>>>> able to have a .jar that deploys both ESB and EJB at the same >>>>>>>>> time instead of keeping them separate like in JBoss 4.x. But >>>>>>>>> for other component architectures, like Spring, we'll want to >>>>>>>>> inline them in ESB XML configuration. >>>>>>>>> >>>>>>>>> Bill >>>>>>>>> >>>>>>>>> Burr Sutter wrote: >>>>>>>>>> We did talk about having a "hibernate listener" and we'll >>>>>>>>>> eventually want web services as well in the default "ESB >>>>>>>>>> server". So that begins to pull in a lot of other >>>>>>>>>> components. I'm less worried about the size and more >>>>>>>>>> focused on the "out-of-the-box-experience". The average >>>>>>>>>> end-user will want to use the WS capabilities immediately >>>>>>>>>> upon installation. Perhaps 30%+ on the hibernate feature. >>>>>>>>>> In any case, I'm always trying to make the point that you >>>>>>>>>> need to think differently about your technical mediation >>>>>>>>>> services vs your business services. Your business logic >>>>>>>>>> should NOT be in ESB custom actions. Custom actions are >>>>>>>>>> there to build custom mediation "interceptors" but business >>>>>>>>>> logic should live where it currently lives in EJBs, WSs, >>>>>>>>>> Spring beans, POJOs, Struts actions, etc. So in the case of >>>>>>>>>> the business_service quickstart we need to change the >>>>>>>>>> documentation so it tells the user how to run both engines >>>>>>>>>> simultaneously. The webservice_war1 should be deployable >>>>>>>>>> completely on the ESB server without the App Server. >>>>>>>>>> Kurt T Stam wrote: >>>>>>>>>>> Good question. And we will have this discussion for >>>>>>>>>>> JBESB-5.0: "Even >>>>>>>>>>> when everything is pluggable, What comes standard in it?". >>>>>>>>>>> My feeling is >>>>>>>>>>> that is should not come with JBESB by default as it is not >>>>>>>>>>> core to >>>>>>>>>>> SOA/ESB, but if we really should have some installer >>>>>>>>>>> functionality we >>>>>>>>>>> could make it easy to add them in, just like adding the ftp >>>>>>>>>>> server, >>>>>>>>>>> email server etc. I looked into using the izPack thing >>>>>>>>>>> before, which >>>>>>>>>>> looks pretty nice. We some customized version in JBossAS, >>>>>>>>>>> which allows >>>>>>>>>>> remote installs etc. I think that may be the way to go >>>>>>>>>>> (after MP1). >>>>>>>>>>> >>>>>>>>>>> Bill Burke wrote: >>>>>>>>>>> >>>>>>>>>>>> Do we want to add EJB3 for busines_service? Probably add >>>>>>>>>>>> another >>>>>>>>>>>> 4meg to the distro. But we would have Hibernate too. >>>>>>>>>>>> Eventually >>>>>>>>>>>> somebody will write the Hibernate/JPA actions that Burr >>>>>>>>>>>> suggested >>>>>>>>>>>> during the meeting in Westford. >>>>>>>>>>>> >>>>>>>>>>>> Kurt T Stam wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Starting work on more_action >>>>>>>>>>>>> >>>>>>>>>>>>> TODO >>>>>>>>>>>>> >>>>>>>>>>>>> business_service (this is ejb3, and will require deploying >>>>>>>>>>>>> to the >>>>>>>>>>>>> appserver) >>>>>>>>>>>>> webservice_war1 (this requires a WS stack, which also >>>>>>>>>>>>> requires the >>>>>>>>>>>>> appserver). >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Mark Little wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I thought we decided on today's SILC meeting to postpone >>>>>>>>>>>>>> the jBPM >>>>>>>>>>>>>> demo because of lack of time? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Mark. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 21 Mar 2007, at 18:44, Kurt T Stam wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> OK I think we should leave aggregator alone, as it has >>>>>>>>>>>>>>> no real >>>>>>>>>>>>>>> deployment now. I'm starting on fun_cbr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> TODO: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> business_service >>>>>>>>>>>>>>> webservice_war1 >>>>>>>>>>>>>>> jbpm_simple1 >>>>>>>>>>>>>>> more_action >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Kurt T Stam wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The work that needs be done is building an .esb archive >>>>>>>>>>>>>>>> much like >>>>>>>>>>>>>>>> the custom-action.jar but in addition it need to contain >>>>>>>>>>>>>>>> a jboss-esb.xml in META-INF, and then changing the >>>>>>>>>>>>>>>> deployToSAR >>>>>>>>>>>>>>>> task to deploy, which should deploy this archive to the >>>>>>>>>>>>>>>> server/default/deploy directory. If the sample contains >>>>>>>>>>>>>>>> queue >>>>>>>>>>>>>>>> definitions you may add this to the root of the .esb >>>>>>>>>>>>>>>> archive. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> For most samples I'm leaving the "ant run" task to >>>>>>>>>>>>>>>> start esb >>>>>>>>>>>>>>>> through the bootstrapper. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm taking static_router and simple_cbr right now. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> --Kurt >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Kurt T Stam wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> TODO: >>>>>>>>>>>>>>>>> aggregator >>>>>>>>>>>>>>>>> business_service >>>>>>>>>>>>>>>>> fun_cbr >>>>>>>>>>>>>>>>> webservice_war1 >>>>>>>>>>>>>>>>> jbpm_simple1 >>>>>>>>>>>>>>>>> more_action >>>>>>>>>>>>>>>>> simple_cbr >>>>>>>>>>>>>>>>> static_router >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> DONE: >>>>>>>>>>>>>>>>> helloworld >>>>>>>>>>>>>>>>> helloworld_action >>>>>>>>>>>>>>>>> helloworld_db_registration >>>>>>>>>>>>>>>>> helloworld_file_action >>>>>>>>>>>>>>>>> helloworld_ftp_action >>>>>>>>>>>>>>>>> helloworld_sql_action (I'm currently working on this one) >>>>>>>>>>>>>>>>> scripting_groovy >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Bill Burke wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> We want to port the samples to the new .esb >>>>>>>>>>>>>>>>>> deployment right? Divide >>>>>>>>>>>>>>>>>> an conquer here? We each take a few? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> esb-dev mailing list >>>>>>>>>>>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> esb-dev mailing list >>>>>>>>>>>>>>> esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> >>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>>>>>>>> >>>>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> esb-dev mailing list >>>>>>>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> esb-dev mailing list >>>>>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>>>> >>>>>>>>> >>>>>>>>> --Bill Burke >>>>>>>>> JBoss, a division of Red Hat Inc. >>>>>>>>> _______________________________________________ >>>>>>>>> esb-dev mailing list >>>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>> >>>>>>> >>>>> >>> > > --Bill Burke > JBoss, a division of Red Hat Inc.

I don't think you understood what I wrote. I'm talking about action frameworks, not freakin SOA! What you state below, is actually what I've stated on various forums that I don't like about the vendor push towards SOA. SOA should not be used by application developers. It should be used by system integrators. I've experienced the failure of fine-grained CORBA applications more than 12 years ago first hand. So really, stop preaching and listen. It becomes annoying at times. * EJB + SOAP is just a feature of Session beans. Ever hear of local EJBs? They provide the same *exact* functionality (even more) of Spring + Hibernate session management + transaction demarcation. There's absolutely no reason not to use finer-grained, local EJBs. They provide a bunch of nice, integrated features (like persistent session management, environment injection, local transaction boundaries). * EJB isn't CORBA with SOAP/HTTP. Ever hear of MDBs? MDBs with JCA behind it allows you to really run over any protocol or message semantic or message interface. Asynch or synch. No reason you couldn't have a JCA adapter to push in WS messages. In fact, that would probably be the best approach as JCA defines a nice contract for importing the transaction context into the application server. I'm even of the strong opinion that JBoss ESB's entire suite of connectors should be refactored to be JCA adapters (or thrown out entirely if one already exists in open source). The whole point of my rant was: screw SCA and JBI. Screw their component models. If we design something that is clean, innovative, well integrated with the rest of JEMS, simple, and productive, people will use it. IMO, JBoss ESB is way too far behind the crowd to ever catch up by just implementing specifications. Bill Mark Little wrote: > I think we are showing innovation, but you're right that the higher > level model we have at the moment is limiting. However, I've said > before that EJBs have nothing to do with SOA. Just adding an EJB onto > a Web Services stack doesn't give you SOA. What it does is give you > CORBA with SOAP/HTTP transport. Tightly coupled interactions, brittle > applications etc. That's not to say we shouldn't support EJBs, POJOs > etc (we've been talking about that kind of support for a while), but > there's more to an ESB/SOA model than just exposing individual > objects. If you ever catch up with our mutual friend Steve Vinoski, > he has a great view of how CORBA failed because people were > encouraged to expose individual objects onto the CORBA "bus" rather > than coarse grained services. > > Mark. > > > On 22 Mar 2007, at 18:46, Bill Burke wrote: > >> I still think that jBPM should be the action framework. They >> already have, or are going to want to have the same features as >> ESB's action framework, plus more. Might as well work together. If >> you want to integrate with something like BPEL, then integrate at >> the inbound connector layer (the connector exposes a WS or BPEL >> friendly interface), not as the action framework. >> >> No matter what, we should provide a simplified, default model. IMO, >> it is absolutely ludricrous to have a 181 as your component model >> for actions. Absolutely crazy. It provides zero value. A POJO >> model with local EJBs or Spring/MC +/- Seam is what we should promote. >> >> We're JBoss. We lead, not follow. Take a page out of the Spring >> playbook: Show innovation, integration, and added-value and you >> don't have to follow these gay specs like JBI 2.0 and SCA. That's >> what Seam did. >> >> Bill >> >> Burr Sutter wrote: >>> Good point. JBI 2.0 should specify the end-user's component >>> development model even if they just leverage the work done in the >>> SCA project. >>> Mark Little wrote: >>>> 181 makes sense in a Web Services environment. I'm sure we've >>>> talked about this last year, but what I'd like to see is something >>>> similar defined in JBI 2.0. >>>> >>>> Mark. >>>> >>>> >>>> On 22 Mar 2007, at 18:36, Burr Sutter wrote: >>>> >>>>> Ideally we would recommend Seam components but Seam isn't yet >>>>> ready for this sort of use case. However, I also like 181 WS as >>>>> the business logic services. >>>>> >>>>> >>>>> Mark Little wrote: >>>>>> We can have a call, but it'll have to be next week. BTW, I don't >>>>>> think we'll be recommending Spring beans ;-) >>>>>> >>>>>> Mark. >>>>>> >>>>>> >>>>>> On 22 Mar 2007, at 17:59, Burr Sutter wrote: >>>>>> >>>>>>> I'd like to have a conference call on this particular topic. >>>>>>> It is tough to discuss via email. It is important that we >>>>>>> clearly articulate how people build ESB-based applications and >>>>>>> "actions" where not intended as the business logic-based >>>>>>> endpoints. WS, EJB, etc were supposed to be those endpoints. >>>>>>> In the future SCA endpoints will be the business logic elements. >>>>>>> >>>>>>> ServiceMix team recommends 181 WS or Spring beans >>>>>>> Mule recommends Spring beans >>>>>>> >>>>>>> >>>>>>> Bill Burke wrote: >>>>>>>> Whether or not it shouldn't be done, people will want it. >>>>>>>> XDoclet/annotations are a prime example of how people want >>>>>>>> their metadata in one place. Servicemix also mixes business >>>>>>>> logic with message flow/service definition. >>>>>>>> >>>>>>>> jBPM is even more interesting in this regard. The IoC >>>>>>>> information, I believe, is part of the process definition >>>>>>>> metadata. What's interesting is that if you make the message >>>>>>>> flow definition tag along with the message, even configuration >>>>>>>> information can be propagated. So "smart messages" could not >>>>>>>> only know how to route themselves, they know how to configure >>>>>>>> the actions that travel along with them. >>>>>>>> >>>>>>>> Bill >>>>>>>> >>>>>>>> Mark Little wrote: >>>>>>>>> I think the problem we have at the moment is that the actions >>>>>>>>> are the closest thing we have to "service definitions", when >>>>>>>>> in fact they aren't really (or shouldn't be IMO). >>>>>>>>> >>>>>>>>> Mark. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 22 Mar 2007, at 12:12, Bill Burke wrote: >>>>>>>>> >>>>>>>>>> +1 to Burr. Everything should run out of the box. All the >>>>>>>>>> examples, etc. >>>>>>>>>> >>>>>>>>>> I disagree on not having business logic in actions. Users >>>>>>>>>> will want an integrated experience, one-stop shop for where >>>>>>>>>> they do things, IMO. If business logic is implemented as an >>>>>>>>>> annotated EJB its not such a big deal, as in JBOss 5 we'll >>>>>>>>>> be able to have a .jar that deploys both ESB and EJB at the >>>>>>>>>> same time instead of keeping them separate like in JBoss >>>>>>>>>> 4.x. But for other component architectures, like Spring, >>>>>>>>>> we'll want to inline them in ESB XML configuration. >>>>>>>>>> >>>>>>>>>> Bill >>>>>>>>>> >>>>>>>>>> Burr Sutter wrote: >>>>>>>>>>> We did talk about having a "hibernate listener" and we'll >>>>>>>>>>> eventually want web services as well in the default "ESB >>>>>>>>>>> server". So that begins to pull in a lot of other >>>>>>>>>>> components. I'm less worried about the size and more >>>>>>>>>>> focused on the "out-of-the-box-experience". The average >>>>>>>>>>> end-user will want to use the WS capabilities immediately >>>>>>>>>>> upon installation. Perhaps 30%+ on the hibernate feature. >>>>>>>>>>> In any case, I'm always trying to make the point that you >>>>>>>>>>> need to think differently about your technical mediation >>>>>>>>>>> services vs your business services. Your business logic >>>>>>>>>>> should NOT be in ESB custom actions. Custom actions are >>>>>>>>>>> there to build custom mediation "interceptors" but business >>>>>>>>>>> logic should live where it currently lives in EJBs, WSs, >>>>>>>>>>> Spring beans, POJOs, Struts actions, etc. So in the case >>>>>>>>>>> of the business_service quickstart we need to change the >>>>>>>>>>> documentation so it tells the user how to run both engines >>>>>>>>>>> simultaneously. The webservice_war1 should be deployable >>>>>>>>>>> completely on the ESB server without the App Server. >>>>>>>>>>> Kurt T Stam wrote: >>>>>>>>>>>> Good question. And we will have this discussion for >>>>>>>>>>>> JBESB-5.0: "Even >>>>>>>>>>>> when everything is pluggable, What comes standard in it?". >>>>>>>>>>>> My feeling is >>>>>>>>>>>> that is should not come with JBESB by default as it is not >>>>>>>>>>>> core to >>>>>>>>>>>> SOA/ESB, but if we really should have some installer >>>>>>>>>>>> functionality we >>>>>>>>>>>> could make it easy to add them in, just like adding the >>>>>>>>>>>> ftp server, >>>>>>>>>>>> email server etc. I looked into using the izPack thing >>>>>>>>>>>> before, which >>>>>>>>>>>> looks pretty nice. We some customized version in JBossAS, >>>>>>>>>>>> which allows >>>>>>>>>>>> remote installs etc. I think that may be the way to go >>>>>>>>>>>> (after MP1). >>>>>>>>>>>> >>>>>>>>>>>> Bill Burke wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Do we want to add EJB3 for busines_service? Probably >>>>>>>>>>>>> add another >>>>>>>>>>>>> 4meg to the distro. But we would have Hibernate too. >>>>>>>>>>>>> Eventually >>>>>>>>>>>>> somebody will write the Hibernate/JPA actions that Burr >>>>>>>>>>>>> suggested >>>>>>>>>>>>> during the meeting in Westford. >>>>>>>>>>>>> >>>>>>>>>>>>> Kurt T Stam wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Starting work on more_action >>>>>>>>>>>>>> >>>>>>>>>>>>>> TODO >>>>>>>>>>>>>> >>>>>>>>>>>>>> business_service (this is ejb3, and will require >>>>>>>>>>>>>> deploying to the >>>>>>>>>>>>>> appserver) >>>>>>>>>>>>>> webservice_war1 (this requires a WS stack, which also >>>>>>>>>>>>>> requires the >>>>>>>>>>>>>> appserver). >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Mark Little wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I thought we decided on today's SILC meeting to >>>>>>>>>>>>>>> postpone the jBPM >>>>>>>>>>>>>>> demo because of lack of time? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Mark. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 21 Mar 2007, at 18:44, Kurt T Stam wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> OK I think we should leave aggregator alone, as it has >>>>>>>>>>>>>>>> no real >>>>>>>>>>>>>>>> deployment now. I'm starting on fun_cbr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> TODO: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> business_service >>>>>>>>>>>>>>>> webservice_war1 >>>>>>>>>>>>>>>> jbpm_simple1 >>>>>>>>>>>>>>>> more_action >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Kurt T Stam wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The work that needs be done is building an .esb >>>>>>>>>>>>>>>>> archive much like >>>>>>>>>>>>>>>>> the custom-action.jar but in addition it need to contain >>>>>>>>>>>>>>>>> a jboss-esb.xml in META-INF, and then changing the >>>>>>>>>>>>>>>>> deployToSAR >>>>>>>>>>>>>>>>> task to deploy, which should deploy this archive to the >>>>>>>>>>>>>>>>> server/default/deploy directory. If the sample >>>>>>>>>>>>>>>>> contains queue >>>>>>>>>>>>>>>>> definitions you may add this to the root of the .esb >>>>>>>>>>>>>>>>> archive. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> For most samples I'm leaving the "ant run" task to >>>>>>>>>>>>>>>>> start esb >>>>>>>>>>>>>>>>> through the bootstrapper. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm taking static_router and simple_cbr right now. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> --Kurt >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Kurt T Stam wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> TODO: >>>>>>>>>>>>>>>>>> aggregator >>>>>>>>>>>>>>>>>> business_service >>>>>>>>>>>>>>>>>> fun_cbr >>>>>>>>>>>>>>>>>> webservice_war1 >>>>>>>>>>>>>>>>>> jbpm_simple1 >>>>>>>>>>>>>>>>>> more_action >>>>>>>>>>>>>>>>>> simple_cbr >>>>>>>>>>>>>>>>>> static_router >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> DONE: >>>>>>>>>>>>>>>>>> helloworld >>>>>>>>>>>>>>>>>> helloworld_action >>>>>>>>>>>>>>>>>> helloworld_db_registration >>>>>>>>>>>>>>>>>> helloworld_file_action >>>>>>>>>>>>>>>>>> helloworld_ftp_action >>>>>>>>>>>>>>>>>> helloworld_sql_action (I'm currently working on this >>>>>>>>>>>>>>>>>> one) >>>>>>>>>>>>>>>>>> scripting_groovy >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Bill Burke wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> We want to port the samples to the new .esb >>>>>>>>>>>>>>>>>>> deployment right? Divide >>>>>>>>>>>>>>>>>>> an conquer here? We each take a few? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> esb-dev mailing list >>>>>>>>>>>>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> esb-dev mailing list >>>>>>>>>>>>>>>> esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> >>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> esb-dev mailing list >>>>>>>>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> esb-dev mailing list >>>>>>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --Bill Burke >>>>>>>>>> JBoss, a division of Red Hat Inc. >>>>>>>>>> _______________________________________________ >>>>>>>>>> esb-dev mailing list >>>>>>>>>> esb-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>>>>> >>>>>>>> >>>>>> >>>> >> >> --Bill Burke >> JBoss, a division of Red Hat Inc. >

ESB Actions vs jBPM Actions OR Actions vs JBI/SCA/Spring/Seam are different discussions. Let's take the Actions vs JBI/SCA/Spring, etc debate first: - It has been my push in the outbound evangelism to state that actions are not the ideal place for your business logic. Leave your business logic where it lives today in WSs, EJBs, Spring beans, etc and simply enable those components as bus services by building some ESB action glue. - Ideally we'll give you numerous actions "out of the box" (OOTB) that allows you to simply configure the capabilities of your solution. You'll get actions (OOTB) for splitter, aggregator, routing, CBR, transformation, etc. - There will be times when you need to build your own custom actions so that you can enable to a specific endpoint in a specific way. For instance, you might have your own action that handles specialized transformation or specialized routing that the current OOTB actions/engines don't yet handle correctly.

Now on the ESB actions vs jBPM actions debate: - jBPM actions have a specific interface/super class that is not "message oriented" they require access to the jBPM context and they are tied to particular "events" like node-enter, node-leave. They are not meant to be "pipelined" or chained together. - ESB actions have a specific interface/super class, they are message oriented (take a Message in), require access to the ESB context and are not tied to any events. They are meant to be chained together (in/out Message objects).

Technically they are different animals.

Plus jBPM's JPDL isn't feature rich enough to express things like a JMS endpoint service with 4 associated OOTB ESB actions and 2 custom ESB actions that is currently expressed in the jboss-esb.xml. jBPM is also focused on the BPM space while the ESB is focused on the EAI space. One is human interaction oriented. The other system to system, application to application, business to business focused. They have 2 fundamentally different usage scenarios.

It may or may not be the right place to put business logic, but do we really care? Now that we have the .esb deployment it's pretty well encapsulated. So I see no downside to deploying business logic there. Leaving it where it is is good, but new stuff can be put where ever it makes sense no? So I'm not so sure this debate is worth having.

> Now on the ESB actions vs jBPM actions debate: > - jBPM actions have a specific interface/super class that is not > "message oriented" they require access to the jBPM context and they > are tied to particular "events" like node-enter, node-leave. They are > not meant to be "pipelined" or chained together. > - ESB actions have a specific interface/super class, they are message > oriented (take a Message in), require access to the ESB context and > are not tied to any events. They are meant to be chained together > (in/out Message objects). > ESB action don't have a specific interface/super class (other then lifecycle support, which has nothing to do with this). And we don't yet have ESB context (in code), so we can still be accommodating.

> Technically they are different animals. > Yes they are different animals, but I think there maybe a foundation that work for both.

> Plus jBPM's JPDL isn't feature rich enough to express things like a > JMS endpoint service with 4 associated OOTB ESB actions and 2 custom > ESB actions that is currently expressed in the jboss-esb.xml. jBPM is > also focused on the BPM space while the ESB is focused on the EAI > space. One is human interaction oriented. The other system to system, > application to application, business to business focused. They have 2 > fundamentally different usage scenarios. > I don't see JPDL (as it is today) describing flow between endpoints, I think that is something ESB specific, but once you are in an ESB-service, it looks very much like a jBPM process with actions..

I don't think jBPM-as-it-is-today integration is the way to go, however integrating on a common foundation is worth exploring in my mind. anyway my 2 cents. I'd really like to know if someone is working on the remaining 2 QuickStarts ;)

Burr Sutter wrote: > ESB Actions vs jBPM Actions OR Actions vs JBI/SCA/Spring/Seam are > different discussions. > Let's take the Actions vs JBI/SCA/Spring, etc debate first: > - It has been my push in the outbound evangelism to state that > actions are not the ideal place for your business logic. Leave > your business logic where it lives today in WSs, EJBs, Spring > beans, etc and simply enable those components as bus services by > building some ESB action glue. - Ideally we'll give you numerous > actions "out of the box" (OOTB) that allows you to simply > configure the capabilities of your solution. You'll get actions > (OOTB) for splitter, aggregator, routing, CBR, transformation, > etc. - There will be times when you need to build your own custom > actions so that you can enable to a specific endpoint in a > specific way. For instance, you might have your own action that > handles specialized transformation or specialized routing that the > current OOTB actions/engines don't yet handle correctly. > Now on the ESB actions vs jBPM actions debate: > - jBPM actions have a specific interface/super class that is not > "message oriented" they require access to the jBPM context and > they are tied to particular "events" like node-enter, node-leave. > They are not meant to be "pipelined" or chained together. I don't believe you are right. After looking at things like Servicemix, reading JBPM docs, reading JBPM forums, doing my own prototyping, contributing to ESB project, I see so much overlap and redundant thinking between the two projects. On "jBPM actions aren't 'message-oriented': You can stuff anything you want in a map. Reply-to destination. Context data, anything. And you can wire anything in a map into an action. Take a look at JBoss's EJB Invocation object. It is really a set of 3 maps. 1 map is transient data is not sent across the wire. 1 map is a distributable payload that is not classloader boundary sensative. The last is a distributable payload that is sensitive to classloader boundaries. These maps have message information (parameters, and method to be invoked) and context information (Tx ID, principal, credentials). JBoss's EJB invocation also has a reference to which aspects/interceptors that are being invoked, and where in the aspect/interceptor chain you are invoking. jBPM has an exact analogous structure. The jBPM token could be transformed from an incoming JMS message, or transformed to an outgoing XML document, or just sent AS IS. (jBPM does exactly this when transitioning over JMS). On "JBPM actions aren't meant to be pipelined or chained tgoether": Go look at what JBPM users are doing. > - ESB actions have a specific interface/super class, they are > message oriented (take a Message in), require access to the ESB > context and are not tied to any events. They are meant to be > chained together (in/out Message objects). Disagree. Takencontent based routing. As you enter the routing decision ("node-enter"), you need to transform the message body from text to a XML document. As you leave ("node-leave"), you might want to notify a auditing layer of what decision was made. In a process view, all you want to see at a high level is input coming in and what are the decision routes. What I've been reading about Tom's philosophy is that the definition of an event, action, or node is often blurred depending on how you want the process view to look. BTW, there's no reason the JBPM process instance context and ESB message context can't be the same. They already do semantically the same thing. > Technically they are different animals. I don't think so. Go look at jBPM 3.2. Its starting to look very much like an ESB except it includes long-running processes and human interaction as well as the plain vanilla message flow that ESB offers. IMO, its only natural for the jBPM team to start looking, feeling, and acting like an ESB. Its the same for JBoss Rules and workflow. Its only natural for them to head in this direction. The thing is though, we're not separate companies, we're one company. > Plus jBPM's JPDL isn't feature rich enough to express things like > a JMS endpoint service with 4 associated OOTB ESB actions and 2 > custom ESB actions that is currently expressed in the jboss-esb.xml. Ditch jboss-esb.xml. There is nothing complicated there. I've already written a prototype that does everything but inbound declaration in a process definition. If jBPM 4.0 was ready, I could even do inbound declaration. And I'm sure the jBPM team or a contributor will end up doing this. Its only natural for them to proceed in this direction. Sit on their user forums for a week or so like I did and you'll see what I mean. > jBPM is also focused on the BPM space while the ESB is focused on > the EAI space. I disagree on the focus of jBPM. jBPM is focused on graph oriented programming and state machines. Everything else is just a plugin. > One is human interaction oriented. The other system to system, > application to application, business to business focused. They > have 2 fundamentally different usage scenarios. jBPM is a definition of a state machine. That's it. Message flow is pretty fundamental, IMO, to both EAI and BPM. > It should be noted that we believe ESB users will also wish to > involve humans and long-running "processes" in which case having > an OOTB ESB action that starts or signals a jBPM process instance > is a very good thing (and what Esteban has been working on). Plus > having the jBPM action that is clever enough to "signal" an ESB > registered service is also important. My whole point with using jBPM as the action framework is that it is lightweight enough to act as a simple action and expandable enough to have long running processes and human interaction. What's even more interesting is that the state-machine metadata could travel along with the message thus giving you smart messages. A client could define the message flow and the servers just be set of dumb ESB servers that receive smart messages that know how to process and route themselves. Tom B and company know how to write state-machines. They also know how these state-machines should be implemented to run long running processes . ESB teams knows more about the issues of remote connections better. Combine them, and you have something compelling (1 + 1 > 2). Treat each other as black boxes, and JBPM and ESB might as well be two different products from two different companies (1 + 1 < 2). Bill -- Bill Burke JBoss, a division of Red Hat Inc.

Are we talking about 2 things here: 1. Service Orchestration. Higher level - sitting above bus and interfacing to it via SOAP, JMS etc (message unaware). In this case, being able to mix and match different process management tools is important (jpdl, bpel etc). 2. Bus Level Orchestration. Lower level - sitting inside the bus. Here you orchestrate message routing (CBR etc), transformation, auditing etc. In this case, perhaps it's not so important to be able to plug and play different process models. This is perhaps where jBPM and ESB Actions cross paths??

Now I'd have thought we were talking about 1! If you were talking about 2 then I can see the disconnect. Mark. On 22 Mar 2007, at 21:39, Bill Burke wrote: > > > Tom Fennelly wrote: >> Are we talking about 2 things here: >> 1. Service Orchestration. Higher level - sitting above bus and >> interfacing to it via SOAP, JMS etc (message unaware). In this >> case, being able to mix and match different process management >> tools is important (jpdl, bpel etc). >> 2. Bus Level Orchestration. Lower level - sitting inside the >> bus. Here you orchestrate message routing (CBR etc), >> transformation, >> auditing etc. In this case, perhaps it's not so important to be >> able to plug and play different process models. This is perhaps >> where jBPM and ESB Actions cross paths?? > > Thanks for clarifying Tom. I've been talking about #2. Although I > think jBPM would be a very interesting option for #1, you wouldn't be > an ESB if you couldn't plug in #1. Maybe that's where Mark and I > have been disconnecting? > > Bill > > --Bill Burke > JBoss, a division of Red Hat Inc.

Burr Sutter wrote: > Option 2 is basically replacing jboss-esb.xml with a .jpdl, right? > A mixture of MC and .jdpl yes. You'd need MC beans to define connectors that are shared between services. (or any bean that is shared between services). > And we've have a ton of work to do to make .jpdl expressive enough to > support what jboss-esb.xml does today. Actually the opposite. You have tons of work to do to make jboss-esb.xml as expressive as .jdpl. IMO, ESB's kernel is pretty basic. Its all the converters, connectors, and transformers where all the hard work went into from what I've seen. > When the ESB was presented to Tom B he suggested we build our own > process language on top of jBPM. He thought that would take > approximately 2 people 2 months assuming all of the features mapped > into the underlying engine. Bill, is this what you are suggesting? > No, that's not what I'm suggesting. I'm suggesting jBPM team does most of the work with the underlying kernel and ESB team focuses on enterprise features around and within it like connectors, transformers, EJB, JPA, Hibernate integration, ESP, Rules integration, and ESB federation. I think with 2 man weeks of work you could beanatize ESB components as well as the jBPM object model. Then 1st iteration could be wiring everything together (inbound, outbound, nodes, actions, transitions) using MC XML. From there you could see the usability patterns and write a schema to simplify things for developers. Or, still beanitize ESB components, but prototype by hacking jbpm 3.2 while jBPM team works on jbpm 4.0 based on requirements from ESB, Rules, and Seam teams. Again, my main drive here is to have a well integrated, uniform look and feel to web-flow, esb, and bpm. I really think these technologies work just as well together as they do apart. If all these guys are sharing the same underlying architecture, then it makes it easier to for Seam to tie them together in a unifying API and to share components between them. I'm sorry I'm being so aggressive about this. I just feel that its so crucial to have a unified, seamless platform. Bill

As a follow up... here is the JPDL example for action chaining/service flow (this is one of my demos today). Note: there is a bunch of code around this for handling of what jboss-esb.xml calls a provider, service, listener, etc. And this particular demo was a bitch to create since the jBPM team hadn't yet fully cooked this particular use case (non-human flow). <?xml version="1.0" encoding="UTF-8"?> <process-definition xmlns="" name="ProcessThree"> <start-state name="start"> <transition name="" to="Validation"></transition> </start-state> <state name="Validation"> <event type="node-enter"> <action name="action1" class="actionhandlers.MessagePusherActionHandler"> <queueName>Demo3Validator_Request</queueName> </action> </event> <transition name="" to="Any Validation Errors"></transition> </state> <decision name="Any Validation Errors" expression="#{ERROR=='true'}"> <transition name="true" to="Send Errors 1"></transition> <transition name="false" to="fork1"></transition> </decision> <decision name="Any Service A Errors" expression="#{ERROR=='true'}"> <transition name="false" to="join1"></transition> <transition name="" to="Send Errors 1"></transition> </decision> <node name="Provide Response"> <event type="node-enter"> <action name="action1" class="actionhandlers.MessagePusherActionHandler"> <queueName>Demo3_Response</queueName> </action> </event> <transition name="" to="end1"></transition> </node> <end-state name="end1"></end-state> <fork name="fork1"> <transition name="B" to="Service B"></transition> <transition name="A" to="Service A"></transition> </fork> <join name="join1"> <transition name="" to="Provide Response"></transition> </join> <state name="Service B"> <event type="node-enter"> <action name="action1" class="actionhandlers.MessagePusherActionHandler"> <queueName>Demo3TransformerB_Request</queueName> </action> </event> <transition name="" to="Any Service B Errors"></transition> </state> <state name="Service A"> <event type="node-enter"> <action name="action1" class="actionhandlers.MessagePusherActionHandler"> <queueName>Demo3TransformerA_Request</queueName> </action> </event> <transition name="" to="Any Service A Errors"></transition> </state> <decision name="Any Service B Errors" expression="#{ERROR=='true'}"> <transition name="false" to="join1"></transition> <transition name="true" to="Send Errors 3"></transition> </decision> <node name="Send Errors 1"> <event type="node-enter"> <action name="action1" class="actionhandlers.MessagePusherActionHandler"> <queueName>Demo3_Errors</queueName> </action> </event> <transition name="" to="end1"></transition> </node> <node name="Send Errors 3"> <event type="node-enter"> <action name="action1" class="actionhandlers.MessagePusherActionHandler"> <queueName>Demo3_Errors</queueName> </action> </event> <transition name="" to="end1"></transition> </node> </process-definition> Burr Sutter wrote: > I'm not seeing any real value. Trying to replacing jboss-esb.xml > with a .jpdl does mean we (the ESB team) don't have to write any > "flow" code for action "chaining" but I don't believe there is much > code in that area to begin with. I need something more concrete to > debate. Here is a jboss-esb.xml file. The only value I see in using > jPDL would be to replace the action area of the service definition, > basically the actions section could in theory be JPDL. Instead of > action1, action2, action3 you would have state1 - transition1, state2 > - transition1 with actions tied to either states/transitions. Is > this more or less what you are proposing? > > <?xml version = "1.0" encoding = "UTF-8"?> > <jbossesb > xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc... > parameterReloadSecs="5"> > > <providers> > <jms-provider name="JBossMQ" > connection-factory="ConnectionFactory"> > <jms-bus busid="quickstartGwChannel"> > <jms-message-filter > dest-type="QUEUE" > > dest-name="queue/quickstart_helloworld_action_Request" > /> > </jms-bus> > <jms-bus busid="quickstartEsbChannel"> > <jms-message-filter > dest-type="QUEUE" > dest-name="queue/B" > /> > </jms-bus> > > </jms-provider> > </providers> > <services> > <service category="HelloWorld_ActionESB" > name="SimpleListener" > description="Hello World" > > <listeners> > <jms-listener name="JMS-Gateway" > > busidref="quickstartGwChannel" > maxThreads="1" > is-gateway="true" > /> > <jms-listener name="JMS-ESBListener" > busidref="quickstartEsbChannel" > maxThreads="1" > /> </listeners> > <actions> > <action name="displayAction" > > class="quickstart.helloworld_action.MyJMSListenerAction" > process="displayMessage"> > <property name="exceptionMethod" > value="exceptionHandler"/> > </action> > <action name="playAction" > > class="quickstart.helloworld_action.MyJMSListenerAction" > process="playWithMessage"> > <property > name="exceptionMethod" value="exceptionHandler"/> > </action> > <action name="notificationAction" > class="org.jboss.soa.esb.actions.Notifier"> > <property name="okMethod" value="notifyOK" /> > <property name="notification-details"> > <NotificationList type="OK"> > <target class="NotifyConsole" /> > <target class="NotifyQueues"> > <queue > jndiName="queue/quickstart_helloworld_action_Response"> > <messageProp name="quickstart" > value="hello_world_action" /> > </queue> > </target> > </NotificationList> > </property> > </action> </actions> > </service> > </services> > </jbossesb> > > > > > Bill Burke wrote: >> >> >> Burr Sutter wrote: >>> Option 2 is basically replacing jboss-esb.xml with a .jpdl, right? >>> >> >> A mixture of MC and .jdpl yes. You'd need MC beans to define >> connectors that are shared between services. (or any bean that is >> shared between services). >> >>> And we've have a ton of work to do to make .jpdl expressive enough >>> to support what jboss-esb.xml does today. >> >> Actually the opposite. You have tons of work to do to make >> jboss-esb.xml as expressive as .jdpl. IMO, ESB's kernel is pretty >> basic. Its all the converters, connectors, and transformers where >> all the hard work went into from what I've seen. >> >>> When the ESB was presented to Tom B he suggested we build our own >>> process language on top of jBPM. He thought that would take >>> approximately 2 people 2 months assuming all of the features mapped >>> into the underlying engine. Bill, is this what you are suggesting? >>> >> >> No, that's not what I'm suggesting. I'm suggesting jBPM team does >> most of the work with the underlying kernel and ESB team focuses on >> enterprise features around and within it like connectors, >> transformers, EJB, JPA, Hibernate integration, ESP, Rules >> integration, and ESB federation. >> >> I think with 2 man weeks of work you could beanatize ESB components >> as well as the jBPM object model. Then 1st iteration could be >> wiring everything together (inbound, outbound, nodes, actions, >> transitions) using MC XML. From there you could see the usability >> patterns and write a schema to simplify things for developers. Or, >> still beanitize ESB components, but prototype by hacking jbpm 3.2 >> while jBPM team works on jbpm 4.0 based on requirements from ESB, >> Rules, and Seam teams. >> >> Again, my main drive here is to have a well integrated, uniform look >> and feel to web-flow, esb, and bpm. I really think these >> technologies work just as well together as they do apart. If all >> these guys are sharing the same underlying architecture, then it >> makes it easier to for Seam to tie them together in a unifying API >> and to share components between them. >> >> I'm sorry I'm being so aggressive about this. I just feel that its >> so crucial to have a unified, seamless platform. >> >> Bill >> > _______________________________________________ > esb-dev mailing list > esb-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/esb-dev _______________________________________________ esb-dev mailing list esb-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/esb-dev

As a follow up... here is the JPDL example for action chaining/service flow (this is one of my demos today). Note: there is a bunch of code around this for handling of what jboss-esb.xml calls a provider, service, listener, etc. And this particular demo was a bitch to create since the jBPM team hadn't yet fully cooked this particular use case (non-human flow). <?xml version="1.0" encoding="UTF-8"?> <process-definition xmlns="" name="ProcessThree"> <start-state name="start"> <transition name="" to="Validation"></transition> </start-state> <state name="Validation"> <event type="node-enter"> <action name="action1" class="actionhandlers.MessagePusherActionHandler"> <queueName>Demo3Validator_Request</queueName> </action> </event> <transition name="" to="Any Validation Errors"></transition> </state> <decision name="Any Validation Errors" expression="#{ERROR=='true'}"> <transition name="true" to="Send Errors 1"></transition> <transition name="false" to="fork1"></transition> </decision> <decision name="Any Service A Errors" expression="#{ERROR=='true'}"> <transition name="false" to="join1"></transition> <transition name="" to="Send Errors 1"></transition> </decision> <node name="Provide Response"> <event type="node-enter"> <action name="action1" class="actionhandlers.MessagePusherActionHandler"> <queueName>Demo3_Response</queueName> </action> </event> <transition name="" to="end1"></transition> </node> <end-state name="end1"></end-state> <fork name="fork1"> <transition name="B" to="Service B"></transition> <transition name="A" to="Service A"></transition> </fork> <join name="join1"> <transition name="" to="Provide Response"></transition> </join> <state name="Service B"> <event type="node-enter"> <action name="action1" class="actionhandlers.MessagePusherActionHandler"> <queueName>Demo3TransformerB_Request</queueName> </action> </event> <transition name="" to="Any Service B Errors"></transition> </state> <state name="Service A"> <event type="node-enter"> <action name="action1" class="actionhandlers.MessagePusherActionHandler"> <queueName>Demo3TransformerA_Request</queueName> </action> </event> <transition name="" to="Any Service A Errors"></transition> </state> <decision name="Any Service B Errors" expression="#{ERROR=='true'}"> <transition name="false" to="join1"></transition> <transition name="true" to="Send Errors 3"></transition> </decision> <node name="Send Errors 1"> <event type="node-enter"> <action name="action1" class="actionhandlers.MessagePusherActionHandler"> <queueName>Demo3_Errors</queueName> </action> </event> <transition name="" to="end1"></transition> </node> <node name="Send Errors 3"> <event type="node-enter"> <action name="action1" class="actionhandlers.MessagePusherActionHandler"> <queueName>Demo3_Errors</queueName> </action> </event> <transition name="" to="end1"></transition> </node> </process-definition> Burr Sutter wrote: > I'm not seeing any real value. Trying to replacing jboss-esb.xml with > a .jpdl does mean we (the ESB team) don't have to write any "flow" > code for action "chaining" but I don't believe there is much code in > that area to begin with. I need something more concrete to debate. > Here is a jboss-esb.xml file. The only value I see in using jPDL > would be to replace the action area of the service definition, > basically the actions section could in theory be JPDL. Instead of > action1, action2, action3 you would have state1 - transition1, state2 > - transition1 with actions tied to either states/transitions. Is > this more or less what you are proposing? > > <?xml version = "1.0" encoding = "UTF-8"?> > <jbossesb > xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc... > parameterReloadSecs="5"> > > <providers> > <jms-provider name="JBossMQ" > connection-factory="ConnectionFactory"> > <jms-bus busid="quickstartGwChannel"> > <jms-message-filter > dest-type="QUEUE" > > dest-name="queue/quickstart_helloworld_action_Request" > /> > </jms-bus> > <jms-bus busid="quickstartEsbChannel"> > <jms-message-filter > dest-type="QUEUE" > dest-name="queue/B" > /> > </jms-bus> > > </jms-provider> > </providers> > <services> > <service category="HelloWorld_ActionESB" > name="SimpleListener" > description="Hello World" > > <listeners> > <jms-listener name="JMS-Gateway" > > busidref="quickstartGwChannel" > maxThreads="1" > is-gateway="true" > /> > <jms-listener name="JMS-ESBListener" > busidref="quickstartEsbChannel" > maxThreads="1" > /> </listeners> > <actions> > <action name="displayAction" > > class="quickstart.helloworld_action.MyJMSListenerAction" > process="displayMessage"> > <property name="exceptionMethod" > value="exceptionHandler"/> > </action> > <action name="playAction" > > class="quickstart.helloworld_action.MyJMSListenerAction" > process="playWithMessage"> > <property > name="exceptionMethod" value="exceptionHandler"/> > </action> > <action name="notificationAction" > class="org.jboss.soa.esb.actions.Notifier"> > <property name="okMethod" value="notifyOK" /> > <property name="notification-details"> > <NotificationList type="OK"> > <target class="NotifyConsole" /> > <target class="NotifyQueues"> > <queue > jndiName="queue/quickstart_helloworld_action_Response"> > <messageProp name="quickstart" > value="hello_world_action" /> > </queue> > </target> > </NotificationList> > </property> > </action> </actions> > </service> > </services> > </jbossesb> > > > > > Bill Burke wrote: >> >> >> Burr Sutter wrote: >>> Option 2 is basically replacing jboss-esb.xml with a .jpdl, right? >>> >> >> A mixture of MC and .jdpl yes. You'd need MC beans to define >> connectors that are shared between services. (or any bean that is >> shared between services). >> >>> And we've have a ton of work to do to make .jpdl expressive enough >>> to support what jboss-esb.xml does today. >> >> Actually the opposite. You have tons of work to do to make >> jboss-esb.xml as expressive as .jdpl. IMO, ESB's kernel is pretty >> basic. Its all the converters, connectors, and transformers where >> all the hard work went into from what I've seen. >> >>> When the ESB was presented to Tom B he suggested we build our own >>> process language on top of jBPM. He thought that would take >>> approximately 2 people 2 months assuming all of the features mapped >>> into the underlying engine. Bill, is this what you are suggesting? >>> >> >> No, that's not what I'm suggesting. I'm suggesting jBPM team does >> most of the work with the underlying kernel and ESB team focuses on >> enterprise features around and within it like connectors, >> transformers, EJB, JPA, Hibernate integration, ESP, Rules >> integration, and ESB federation. >> >> I think with 2 man weeks of work you could beanatize ESB components >> as well as the jBPM object model. Then 1st iteration could be wiring >> everything together (inbound, outbound, nodes, actions, transitions) >> using MC XML. From there you could see the usability patterns and >> write a schema to simplify things for developers. Or, still >> beanitize ESB components, but prototype by hacking jbpm 3.2 while >> jBPM team works on jbpm 4.0 based on requirements from ESB, Rules, >> and Seam teams. >> >> Again, my main drive here is to have a well integrated, uniform look >> and feel to web-flow, esb, and bpm. I really think these >> technologies work just as well together as they do apart. If all >> these guys are sharing the same underlying architecture, then it >> makes it easier to for Seam to tie them together in a unifying API >> and to share components between them. >> >> I'm sorry I'm being so aggressive about this. I just feel that its >> so crucial to have a unified, seamless platform. >> >> Bill >> > _______________________________________________ > esb-dev mailing list > esb-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/esb-dev

After some more consideration of this matter here is where I am at, I still like both models. I still like our "lightweight" orchestration model that allows the end user to lay out their flow by simply adding actions to jboss-esb.xml. It is very easy to use and there are number of out of the box actions that get me going (e.g. transformation, static router, CBR, splitter, aggregator, notifier, etc). The "cons" for the current lightweight model are: - No tools - just raw XML editing, no drag & drop - No BAM - stats on how long it takes to flow from A to B to C - No persistence so it is an "all or nothing" flow The "pros" for the lightweight model are: - Lots of examples (quickstarts) that illustrate the various ways to use it in the context of SOA - Fairly easy to use & learn - simply action tags Now Esteban is working on our jBPM integration which will give us "enterprise-class" orchestration. The "pros" for jBPM-based orchestration are: - Tools - assuming we keep the .jpdl file separate (outside of jboss-esb.xml) then the current tools will allow for editing, dragging & dropping - really, really basic BAM - and it will improve in the future - human-interaction if needed - persistence which means a flow can be "paused" and "restarted" - You can actually mix & match the lightweight flow (e.g. call to the SmooksTranformer then a call to a jBPM process instance) in the same jboss-esb.xml The "cons" for jBPM-based orchestration: - Does require learning of jPDL and jBPM actions. This is not a trivial undertaking. - It requires lots of setup & configuration for jBPM such as getting the database configured correctly and Hibernate mapped correctly. This is not well documented and involves some heavy lifting on the part of the user. It is improving but does have a real learning curve. Burr Sutter wrote: > I'm not seeing any real value. Trying to replacing jboss-esb.xml > with a .jpdl does mean we (the ESB team) don't have to write any > "flow" code for action "chaining" but I don't believe there is much > code in that area to begin with. I need something more concrete to > debate. Here is a jboss-esb.xml file. The only value I see in using > jPDL would be to replace the action area of the service definition, > basically the actions section could in theory be JPDL. Instead of > action1, action2, action3 you would have state1 - transition1, state2 > - transition1 with actions tied to either states/transitions. Is > this more or less what you are proposing? > > <?xml version = "1.0" encoding = "UTF-8"?> > <jbossesb > xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc... > parameterReloadSecs="5"> > > <providers> > <jms-provider name="JBossMQ" > connection-factory="ConnectionFactory"> > <jms-bus busid="quickstartGwChannel"> > <jms-message-filter > dest-type="QUEUE" > > dest-name="queue/quickstart_helloworld_action_Request" > /> > </jms-bus> > <jms-bus busid="quickstartEsbChannel"> > <jms-message-filter > dest-type="QUEUE" > dest-name="queue/B" > /> > </jms-bus> > > </jms-provider> > </providers> > <services> > <service category="HelloWorld_ActionESB" > name="SimpleListener" > description="Hello World" > > <listeners> > <jms-listener name="JMS-Gateway" > > busidref="quickstartGwChannel" > maxThreads="1" > is-gateway="true" > /> > <jms-listener name="JMS-ESBListener" > busidref="quickstartEsbChannel" > maxThreads="1" > /> </listeners> > <actions> > <action name="displayAction" > > class="quickstart.helloworld_action.MyJMSListenerAction" > process="displayMessage"> > <property name="exceptionMethod" > value="exceptionHandler"/> > </action> > <action name="playAction" > > class="quickstart.helloworld_action.MyJMSListenerAction" > process="playWithMessage"> > <property > name="exceptionMethod" value="exceptionHandler"/> > </action> > <action name="notificationAction" > class="org.jboss.soa.esb.actions.Notifier"> > <property name="okMethod" value="notifyOK" /> > <property name="notification-details"> > <NotificationList type="OK"> > <target class="NotifyConsole" /> > <target class="NotifyQueues"> > <queue > jndiName="queue/quickstart_helloworld_action_Response"> > <messageProp name="quickstart" > value="hello_world_action" /> > </queue> > </target> > </NotificationList> > </property> > </action> </actions> > </service> > </services> > </jbossesb> > > > > > Bill Burke wrote: >> >> >> Burr Sutter wrote: >>> Option 2 is basically replacing jboss-esb.xml with a .jpdl, right? >>> >> >> A mixture of MC and .jdpl yes. You'd need MC beans to define >> connectors that are shared between services. (or any bean that is >> shared between services). >> >>> And we've have a ton of work to do to make .jpdl expressive enough >>> to support what jboss-esb.xml does today. >> >> Actually the opposite. You have tons of work to do to make >> jboss-esb.xml as expressive as .jdpl. IMO, ESB's kernel is pretty >> basic. Its all the converters, connectors, and transformers where >> all the hard work went into from what I've seen. >> >>> When the ESB was presented to Tom B he suggested we build our own >>> process language on top of jBPM. He thought that would take >>> approximately 2 people 2 months assuming all of the features mapped >>> into the underlying engine. Bill, is this what you are suggesting? >>> >> >> No, that's not what I'm suggesting. I'm suggesting jBPM team does >> most of the work with the underlying kernel and ESB team focuses on >> enterprise features around and within it like connectors, >> transformers, EJB, JPA, Hibernate integration, ESP, Rules >> integration, and ESB federation. >> >> I think with 2 man weeks of work you could beanatize ESB components >> as well as the jBPM object model. Then 1st iteration could be >> wiring everything together (inbound, outbound, nodes, actions, >> transitions) using MC XML. From there you could see the usability >> patterns and write a schema to simplify things for developers. Or, >> still beanitize ESB components, but prototype by hacking jbpm 3.2 >> while jBPM team works on jbpm 4.0 based on requirements from ESB, >> Rules, and Seam teams. >> >> Again, my main drive here is to have a well integrated, uniform look >> and feel to web-flow, esb, and bpm. I really think these >> technologies work just as well together as they do apart. If all >> these guys are sharing the same underlying architecture, then it >> makes it easier to for Seam to tie them together in a unifying API >> and to share components between them. >> >> I'm sorry I'm being so aggressive about this. I just feel that its >> so crucial to have a unified, seamless platform. >> >> Bill >> > _______________________________________________ > esb-dev mailing list > esb-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/esb-dev

lol He's probably offline at the moment... making his way to your's (or maybe Mark's) house... armed... and dangerous ;-) Burr Sutter wrote: > Come on Bill. Keep up the fight! This is fun. :-) > > Burr Sutter wrote: >> After some more consideration of this matter here is where I am at, I >> still like both models. >> >> I still like our "lightweight" orchestration model that allows the >> end user to lay out their flow by simply adding actions to >> jboss-esb.xml. It is very easy to use and there are number of out of >> the box actions that get me going (e.g. transformation, static >> router, CBR, splitter, aggregator, notifier, etc). The "cons" for >> the current lightweight model are: >> - No tools - just raw XML editing, no drag & drop >> - No BAM - stats on how long it takes to flow from A to B to C >> - No persistence so it is an "all or nothing" flow >> >> The "pros" for the lightweight model are: >> - Lots of examples (quickstarts) that illustrate the various ways to >> use it in the context of SOA >> - Fairly easy to use & learn - simply action tags >> >> Now Esteban is working on our jBPM integration which will give us >> "enterprise-class" orchestration. The "pros" for jBPM-based >> orchestration are: >> - Tools - assuming we keep the .jpdl file separate (outside of >> jboss-esb.xml) then the current tools will allow for editing, >> dragging & dropping >> - really, really basic BAM - and it will improve in the future >> - human-interaction if needed >> - persistence which means a flow can be "paused" and "restarted" >> - You can actually mix & match the lightweight flow (e.g. call to the >> SmooksTranformer then a call to a jBPM process instance) in the same >> jboss-esb.xml >> >> The "cons" for jBPM-based orchestration: >> - Does require learning of jPDL and jBPM actions. This is not a >> trivial undertaking. >> - It requires lots of setup & configuration for jBPM such as getting >> the database configured correctly and Hibernate mapped correctly. >> This is not well documented and involves some heavy lifting on the >> part of the user. It is improving but does have a real learning curve. >> >> >> Burr Sutter wrote: >>> I'm not seeing any real value. Trying to replacing jboss-esb.xml >>> with a .jpdl does mean we (the ESB team) don't have to write any >>> "flow" code for action "chaining" but I don't believe there is much >>> code in that area to begin with. I need something more concrete >>> to debate. Here is a jboss-esb.xml file. The only value I see in >>> using jPDL would be to replace the action area of the service >>> definition, basically the actions section could in theory be JPDL. >>> Instead of action1, action2, action3 you would have state1 - >>> transition1, state2 - transition1 with actions tied to either >>> states/transitions. Is this more or less what you are proposing? >>> >>> <?xml version = "1.0" encoding = "UTF-8"?> >>> <jbossesb >>> xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc... >>> parameterReloadSecs="5"> >>> >>> <providers> >>> <jms-provider name="JBossMQ" >>> connection-factory="ConnectionFactory"> >>> <jms-bus busid="quickstartGwChannel"> >>> <jms-message-filter >>> dest-type="QUEUE" >>> >>> dest-name="queue/quickstart_helloworld_action_Request" >>> /> >>> </jms-bus> >>> <jms-bus busid="quickstartEsbChannel"> >>> <jms-message-filter >>> dest-type="QUEUE" >>> dest-name="queue/B" >>> /> >>> </jms-bus> >>> >>> </jms-provider> >>> </providers> >>> <services> >>> <service category="HelloWorld_ActionESB" >>> name="SimpleListener" >>> description="Hello World" > >>> <listeners> >>> <jms-listener name="JMS-Gateway" >>> >>> busidref="quickstartGwChannel" >>> maxThreads="1" >>> is-gateway="true" >>> /> >>> <jms-listener name="JMS-ESBListener" >>> busidref="quickstartEsbChannel" >>> maxThreads="1" >>> /> </listeners> >>> <actions> >>> <action name="displayAction" >>> >>> class="quickstart.helloworld_action.MyJMSListenerAction" >>> process="displayMessage"> >>> <property name="exceptionMethod" >>> value="exceptionHandler"/> >>> </action> >>> <action name="playAction" >>> >>> class="quickstart.helloworld_action.MyJMSListenerAction" >>> process="playWithMessage"> >>> <property >>> name="exceptionMethod" value="exceptionHandler"/> >>> </action> >>> <action name="notificationAction" >>> class="org.jboss.soa.esb.actions.Notifier"> >>> <property name="okMethod" value="notifyOK" /> >>> <property name="notification-details"> >>> <NotificationList type="OK"> >>> <target class="NotifyConsole" /> >>> <target class="NotifyQueues"> >>> <queue >>> jndiName="queue/quickstart_helloworld_action_Response"> >>> <messageProp name="quickstart" >>> value="hello_world_action" /> >>> </queue> >>> </target> >>> </NotificationList> >>> </property> >>> </action> </actions> >>> </service> >>> </services> >>> </jbossesb> >>> >>> >>> >>> >>> Bill Burke wrote: >>>> >>>> >>>> Burr Sutter wrote: >>>>> Option 2 is basically replacing jboss-esb.xml with a .jpdl, right? >>>>> >>>> >>>> A mixture of MC and .jdpl yes. You'd need MC beans to define >>>> connectors that are shared between services. (or any bean that is >>>> shared between services). >>>> >>>>> And we've have a ton of work to do to make .jpdl expressive enough >>>>> to support what jboss-esb.xml does today. >>>> >>>> Actually the opposite. You have tons of work to do to make >>>> jboss-esb.xml as expressive as .jdpl. IMO, ESB's kernel is pretty >>>> basic. Its all the converters, connectors, and transformers where >>>> all the hard work went into from what I've seen. >>>> >>>>> When the ESB was presented to Tom B he suggested we build our own >>>>> process language on top of jBPM. He thought that would take >>>>> approximately 2 people 2 months assuming all of the features >>>>> mapped into the underlying engine. Bill, is this what you are >>>>> suggesting? >>>>> >>>> >>>> No, that's not what I'm suggesting. I'm suggesting jBPM team does >>>> most of the work with the underlying kernel and ESB team focuses on >>>> enterprise features around and within it like connectors, >>>> transformers, EJB, JPA, Hibernate integration, ESP, Rules >>>> integration, and ESB federation. >>>> >>>> I think with 2 man weeks of work you could beanatize ESB components >>>> as well as the jBPM object model. Then 1st iteration could be >>>> wiring everything together (inbound, outbound, nodes, actions, >>>> transitions) using MC XML. From there you could see the usability >>>> patterns and write a schema to simplify things for developers. Or, >>>> still beanitize ESB components, but prototype by hacking jbpm 3.2 >>>> while jBPM team works on jbpm 4.0 based on requirements from ESB, >>>> Rules, and Seam teams. >>>> >>>> Again, my main drive here is to have a well integrated, uniform >>>> look and feel to web-flow, esb, and bpm. I really think these >>>> technologies work just as well together as they do apart. If all >>>> these guys are sharing the same underlying architecture, then it >>>> makes it easier to for Seam to tie them together in a unifying API >>>> and to share components between them. >>>> >>>> I'm sorry I'm being so aggressive about this. I just feel that its >>>> so crucial to have a unified, seamless platform. >>>> >>>> Bill >>>> >>> _______________________________________________ >>> esb-dev mailing list >>> esb-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/esb-dev > _______________________________________________ > esb-dev mailing list > esb-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/esb-dev

After some more consideration of this matter here is where I am at, I still like both models. I still like our "lightweight" orchestration model that allows the end user to lay out their flow by simply adding actions to jboss-esb.xml. It is very easy to use and there are number of out of the box actions that get me going (e.g. transformation, static router, CBR, splitter, aggregator, notifier, etc). The "cons" for the current lightweight model are: - No tools - just raw XML editing, no drag & drop - No BAM - stats on how long it takes to flow from A to B to C - No persistence so it is an "all or nothing" flow The "pros" for the lightweight model are: - Lots of examples (quickstarts) that illustrate the various ways to use it in the context of SOA - Fairly easy to use & learn - simply action tags

Now Esteban is working on our jBPM integration which will give us "enterprise-class" orchestration. The "pros" for jBPM-based orchestration are: - Tools - assuming we keep the .jpdl file separate (outside of jboss-esb.xml) then the current tools will allow for editing, dragging & dropping - really, really basic BAM - and it will improve in the future - human-interaction if needed - persistence which means a flow can be "paused" and "restarted" - You can actually mix & match the lightweight flow (e.g. call to the SmooksTranformer then a call to a jBPM process instance) in the same jboss-esb.xml The "cons" for jBPM-based orchestration: - Does require learning of jPDL and jBPM actions. This is not a trivial undertaking.

- It requires lots of setup & configuration for jBPM such as getting the database configured correctly and Hibernate mapped correctly. This is not well documented and involves some heavy lifting on the part of the user. It is improving but does have a real learning curve.

Burr Sutter wrote: > I'm not seeing any real value. Trying to replacing jboss-esb.xml with > a .jpdl does mean we (the ESB team) don't have to write any "flow" > code for action "chaining" but I don't believe there is much code in > that area to begin with. I need something more concrete to debate. > Here is a jboss-esb.xml file. The only value I see in using jPDL > would be to replace the action area of the service definition, > basically the actions section could in theory be JPDL. Instead of > action1, action2, action3 you would have state1 - transition1, state2 > - transition1 with actions tied to either states/transitions. Is > this more or less what you are proposing? > > <?xml version = "1.0" encoding = "UTF-8"?> > <jbossesb > xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc... > parameterReloadSecs="5"> > > <providers> > <jms-provider name="JBossMQ" > connection-factory="ConnectionFactory"> > <jms-bus busid="quickstartGwChannel"> > <jms-message-filter > dest-type="QUEUE" > > dest-name="queue/quickstart_helloworld_action_Request" > /> > </jms-bus> > <jms-bus busid="quickstartEsbChannel"> > <jms-message-filter > dest-type="QUEUE" > dest-name="queue/B" > /> > </jms-bus> > > </jms-provider> > </providers> > <services> > <service category="HelloWorld_ActionESB" > name="SimpleListener" > description="Hello World" > > <listeners> > <jms-listener name="JMS-Gateway" > > busidref="quickstartGwChannel" > maxThreads="1" > is-gateway="true" > /> > <jms-listener name="JMS-ESBListener" > busidref="quickstartEsbChannel" > maxThreads="1" > /> </listeners> > <actions> > <action name="displayAction" > > class="quickstart.helloworld_action.MyJMSListenerAction" > process="displayMessage"> > <property name="exceptionMethod" > value="exceptionHandler"/> > </action> > <action name="playAction" > > class="quickstart.helloworld_action.MyJMSListenerAction" > process="playWithMessage"> > <property > name="exceptionMethod" value="exceptionHandler"/> > </action> > <action name="notificationAction" > class="org.jboss.soa.esb.actions.Notifier"> > <property name="okMethod" value="notifyOK" /> > <property name="notification-details"> > <NotificationList type="OK"> > <target class="NotifyConsole" /> > <target class="NotifyQueues"> > <queue > jndiName="queue/quickstart_helloworld_action_Response"> > <messageProp name="quickstart" > value="hello_world_action" /> > </queue> > </target> > </NotificationList> > </property> > </action> </actions> > </service> > </services> > </jbossesb> > > > > > Bill Burke wrote: >> >> >> Burr Sutter wrote: >>> Option 2 is basically replacing jboss-esb.xml with a .jpdl, right? >>> >> >> A mixture of MC and .jdpl yes. You'd need MC beans to define >> connectors that are shared between services. (or any bean that is >> shared between services). >> >>> And we've have a ton of work to do to make .jpdl expressive enough >>> to support what jboss-esb.xml does today. >> >> Actually the opposite. You have tons of work to do to make >> jboss-esb.xml as expressive as .jdpl. IMO, ESB's kernel is pretty >> basic. Its all the converters, connectors, and transformers where >> all the hard work went into from what I've seen. >> >>> When the ESB was presented to Tom B he suggested we build our own >>> process language on top of jBPM. He thought that would take >>> approximately 2 people 2 months assuming all of the features mapped >>> into the underlying engine. Bill, is this what you are suggesting? >>> >> >> No, that's not what I'm suggesting. I'm suggesting jBPM team does >> most of the work with the underlying kernel and ESB team focuses on >> enterprise features around and within it like connectors, >> transformers, EJB, JPA, Hibernate integration, ESP, Rules >> integration, and ESB federation. >> >> I think with 2 man weeks of work you could beanatize ESB components >> as well as the jBPM object model. Then 1st iteration could be wiring >> everything together (inbound, outbound, nodes, actions, transitions) >> using MC XML. From there you could see the usability patterns and >> write a schema to simplify things for developers. Or, still >> beanitize ESB components, but prototype by hacking jbpm 3.2 while >> jBPM team works on jbpm 4.0 based on requirements from ESB, Rules, >> and Seam teams. >> >> Again, my main drive here is to have a well integrated, uniform look >> and feel to web-flow, esb, and bpm. I really think these >> technologies work just as well together as they do apart. If all >> these guys are sharing the same underlying architecture, then it >> makes it easier to for Seam to tie them together in a unifying API >> and to share components between them. >> >> I'm sorry I'm being so aggressive about this. I just feel that its >> so crucial to have a unified, seamless platform. >> >> Bill >> > _______________________________________________ > esb-dev mailing list > esb-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/esb-dev

Bill Burke wrote: > Burr Sutter wrote: >> The "cons" for jBPM-based orchestration: >> - Does require learning of jPDL and jBPM actions. This is not a >> trivial undertaking. > This is a relevant issue, but I think we can refactor base jbpm to > handle the simple usecases. >> - It requires lots of setup & configuration for jBPM such as >> getting the database configured correctly and Hibernate mapped >> correctly. This is not well documented and involves some heavy >> lifting on the part of the user. It is improving but does have a >> real learning curve. >> > I think this is an irrelevant issue. This can be fixed. ESB 4.0 > release had the same problems. Let me expand on this. Burr, we have to stop thinking of other JEMS projects like black boxes. a) Its all open source b) We all work for the same company c) jBPM team is under Mark anyways We need to foster cross-contributors. Bill -- Bill Burke JBoss, a division of Red Hat Inc. _______________________________________________ esb-dev mailing list esb-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/esb-dev

What is your timeframe for this concept? I don't believe there are enough bodies to throw at jBPM 3.3/3.4 and ESB 4.2 to get them both out the door by June 2007 to bring those different worlds closely in-line. Are you proposing a single repository/single codebase or simply looking for better integration? Burr Bill Burke wrote: > > > Bill Burke wrote: >> >> >> Burr Sutter wrote: >>> The "cons" for jBPM-based orchestration: >>> - Does require learning of jPDL and jBPM actions. This is not a >>> trivial undertaking. >> >> This is a relevant issue, but I think we can refactor base jbpm to >> handle the simple usecases. >> >> >>> - It requires lots of setup & configuration for jBPM such as getting >>> the database configured correctly and Hibernate mapped correctly. >>> This is not well documented and involves some heavy lifting on the >>> part of the user. It is improving but does have a real learning curve. >>> >> >> I think this is an irrelevant issue. This can be fixed. ESB 4.0 >> release had the same problems. >> > > Let me expand on this. Burr, we have to stop thinking of other JEMS > projects like black boxes. > > a) Its all open source > b) We all work for the same company > c) jBPM team is under Mark anyways > > We need to foster cross-contributors. > > Bill >

jBPM 4.0 isn't due until late Q1/early Q2 2008. If we had specific requirements we might be able to get the jBPM team focused on a deliverable between now and and then but the challenge for jBPM is focus: human-centric BPM/workflow or service-centric orchestration.

My point is we have plenty of time to worry about this issue considering the jBPM team has a really long term set plan (a rewrite to be multi-process language focused) plus the fact that it has a human-centric workflow concern that is less directly related to the needs of the ESB. Now, we can certainly discuss how much more important are the needs of the ESB vs things like multi-language and human task management. Please sell me on the idea of lifecycle as it relates to jBPM. The instantiation and manipulation of a jBPM process is primarily a series of database transactions.

BTW, did you know jBPM has its own microcontainer ;-)? Mark. On 26 Mar 2007, at 13:31, Bill Burke wrote: > > > Burr Sutter wrote: >> My point is we have plenty of time to worry about this issue >> considering the jBPM team has a really long term set plan (a rewrite >> to be multi-process language focused) plus the fact that it has a >> human-centric workflow concern that is less directly related to the >> needs of the ESB. >> Now, we can certainly discuss how much more important are the needs >> of the ESB vs things like multi-language and human task management. >> Please sell me on the idea of lifecycle as it relates to jBPM. The >> instantiation and manipulation of a jBPM process is primarily a >> series of database transactions. > > Um, jBPM doesn't have to be a series of database transactions. That's > the user's decision. > > As far as lifecycle goes, right now jbpm works the same way as ESB 4.0 > worked. Actions are created per invocation on the action. We need > actions that are created when the process definition starts so that > they can hold state and shared between process instances. ESB would > also need pluggable transition implementations so that per transition, > the developer can decide how the transition happens (over JMS for > instance). > > Bill > > --Bill Burke > JBoss, a division of Red Hat Inc. > _______________________________________________ > esb-dev mailing list > esb-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/esb-dev

My point is we have plenty of time to worry about this issue considering the jBPM team has a really long term set plan (a rewrite to be multi-process language focused) plus the fact that it has a human-centric workflow concern that is less directly related to the needs of the ESB. Now, we can certainly discuss how much more important are the needs of the ESB vs things like multi-language and human task management. Please sell me on the idea of lifecycle as it relates to jBPM. The instantiation and manipulation of a jBPM process is primarily a series of database transactions. Bill Burke wrote: > > > Burr Sutter wrote: >> jBPM 4.0 isn't due until late Q1/early Q2 2008. If we had >> specific requirements we might be able to get the jBPM team >> focused on a deliverable between now and and then but the >> challenge for jBPM is focus: human-centric BPM/workflow or >> service-centric orchestration. > > Again, i think the changes to jBPM that ESB needs are a > fundamental thing that the jBPM team needs anyways. Like lifecycle. > > Man, you're full of excuses. > > Bill _______________________________________________ esb-dev mailing list esb-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/esb-dev

Here are some more things to consider: 1. jPDL is Process Description Language. Now in my eyes the node is pretty much a ESB service and I think that all fits pretty well. But the thing that is missing is the description of the connection between processes, the bus in ESB terms. So I think we'd need to extend jPDL here, to be able to describe that 'bus connection'.

2. As soon as we accept buses between nodes then we may break out into different JVMs, each having their own configuration file. I think this is something that is missing right now too. We'd need some kind of demarcation.

3. Can this foundation be extended to support managing/monitoring messages and errors in the ESB nerwork? I think jBPM wants this too BTW.

Excuse my ignorance, but why exactly do they differentiate between the different types of orchestration (human, service etc)? I'd have just imagined it all as being event-centric, with whatever triggers (??) the event as being somewhat secondary. Where does that fall down?? Burr Sutter wrote: > jBPM 4.0 isn't due until late Q1/early Q2 2008. If we had specific > requirements we might be able to get the jBPM team focused on a > deliverable between now and and then but the challenge for jBPM is > focus: human-centric BPM/workflow or service-centric orchestration. > Bill Burke wrote: >> Huh? I'm confused on exactly what 4.2 is. Mark told me that it >> should basically be in maintenance mode and only one person was >> going to be maintaining it while the rest of the team focused on 5.0. >> >> Better integration, not a single repository. >> >> Burr Sutter wrote: >>> What is your timeframe for this concept? >>> I don't believe there are enough bodies to throw at jBPM 3.3/3.4 >>> and ESB 4.2 to get them both out the door by June 2007 to bring >>> those different worlds closely in-line. Are you proposing a single >>> repository/single codebase or simply looking for better integration? >>> Burr >>> >>> Bill Burke wrote: >>>> >>>> >>>> Bill Burke wrote: >>>>> >>>>> >>>>> Burr Sutter wrote: >>>>>> The "cons" for jBPM-based orchestration: >>>>>> - Does require learning of jPDL and jBPM actions. This is not a >>>>>> trivial undertaking. >>>>> >>>>> This is a relevant issue, but I think we can refactor base jbpm >>>>> to handle the simple usecases. >>>>> >>>>> >>>>>> - It requires lots of setup & configuration for jBPM such as >>>>>> getting the database configured correctly and Hibernate mapped >>>>>> correctly. This is not well documented and involves some heavy >>>>>> lifting on the part of the user. It is improving but does have >>>>>> a real learning curve. >>>>>> >>>>> >>>>> I think this is an irrelevant issue. This can be fixed. ESB 4.0 >>>>> release had the same problems. >>>>> >>>> >>>> Let me expand on this. Burr, we have to stop thinking of other >>>> JEMS projects like black boxes. >>>> >>>> a) Its all open source >>>> b) We all work for the same company >>>> c) jBPM team is under Mark anyways >>>> >>>> We need to foster cross-contributors. >>>> >>>> Bill >>>> >>> >> > > _______________________________________________ > esb-dev mailing list > esb-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/esb-dev

Yeah, Burr. This is exactly the overall picture I envisioned. I don't see how BPEL could solve such a use case where your overall flow involves both a messaging system(s) and various web applications. This is why I think it is crucial for ESB and jBPM to be built upon the same component model and core engine. In your use case below, there really is no clear separation between the ESB and your process flow. You might want to do transformations between page flows, fork a notification to a backend system, wait on a task to be performed by a web application. Do you see how it all bleeds together and why it all needs to be one integrated product? Please, keep arguing. My initial push of having deeper integration between ESB and jBPM was based on intuition. The more I dive into it, the more I think my intuition was correct, but I am still not totally sure. Bill Burr Sutter wrote: > Human-centric means there are some features that are particularly > important like management of swim-lanes, group task queues, > individual user task queues and a dynamically rendered website that > allows end-users (accountants, lawyers, clerks, etc) to interact with > process instances (with supervisor override capability). The > website/console alone requires about 30+% of the jBPM's teams current > resources. > With our current ESB+jBPM integration we should be able to > orchestrate a single "process" between multiple ESB-hosted services > and humans. Consider this scenario: > 1- An order is received via FTP > 2- Order is routed to a validator > 3- Order is routed to a transformer > 4- Order is over $500 and therefore must be sent to a group task > queue (the order processing team) > 5- Simultaneously an async credit check request for the customer on > the order header is made > 6- Process goes to sleep and awaits a response from the order > processing team and the credit check > 7- Once the credit check returns the process is now only waiting on > the order processing team > 8- Every 2 hours an alert is sent out to the order processing team to > let them know that this order is getting old > 9- Sally (a member of the order processing team) picks up the order > from the group queue and moves it to her own queue > 10- She visually inspects the order (nicely transformed by step 3) > and visually inspects the credit report. While the customers credit > score from Dun and Bradstreet is somewhat poor, the customer has > excellent payment history with our business therefore Sally makes > this additional note on the record and pushes it from her queue to > her supervisors (additional approval required). > 11- Her supervisor is currently out on vacation > 12- Her supervisor's supervisor is covering these tasks and logs into > to finish the order > 13- Now that all approvals are secured the order is routed to the > approach fulfillment team > 14-Parts of the order require service activation (e.g. this is an > order for a new cell phone hardware and services) so those line-items > are split off and routed to the appropriate team - that team's queue > is updated to reflect the needed work (e.g. some services require the > dispatch of field workers) > 15-Parts of the order require multiple warehouses to be notified and > used (e.g. one line-item is for a phone from warehouse A, another > line-item is for an blue tooth earbud from warehouse B) both > warehouses respond with real shipping costs (note customer has > already been quoted so this is just to offset the real book keeping) > 16-Various email alerts are collected and properly organized and sent > out to concerned parties (e.g. the person who initiated the order is > notified that it has shipped) > 17- Once all parties report in that there part of the order has been > fulfilled then accounting is alerted, the executive dashboard is > updated, etc) > > My ESB+jBPM should allow me to see this process laid out visually. > Allow me to make ad-hoc process changes to both process instances > that are "above" the current change (altering step 14 for all new > process instances and process instances living prior to step 14). > Allow me to have complete visibility into how "long" something is > taking at any given step (so I can fire my order processing team). > Allow me to understand who/what is perform optimally (number of > orders processed, complexity of orders, warehouse A team is rocking > along, etc). Assuming this end-to-end process involves various 3rd > parties (e.g. partners who fulfill parts of the process), legacy > systems (e.g mainframe customer history system) and you still want a > robust, easily reconfigurable solution - well that is the promise of > SOA for the enterprise. > > > > > Tom Fennelly wrote: >> Excuse my ignorance, but why exactly do they differentiate between >> the different types of orchestration (human, service etc)? I'd have >> just imagined it all as being event-centric, with whatever triggers >> (??) the event as being somewhat secondary. Where does that fall >> down?? >> >> Burr Sutter wrote: >>> jBPM 4.0 isn't due until late Q1/early Q2 2008. If we had specific >>> requirements we might be able to get the jBPM team focused on a >>> deliverable between now and and then but the challenge for jBPM is >>> focus: human-centric BPM/workflow or service-centric orchestration. >>> Bill Burke wrote: >>>> Huh? I'm confused on exactly what 4.2 is. Mark told me that it >>>> should basically be in maintenance mode and only one person was >>>> going to be maintaining it while the rest of the team focused on 5.0. >>>> >>>> Better integration, not a single repository. >>>> >>>> Burr Sutter wrote: >>>>> What is your timeframe for this concept? >>>>> I don't believe there are enough bodies to throw at jBPM 3.3/3.4 >>>>> and ESB 4.2 to get them both out the door by June 2007 to bring >>>>> those different worlds closely in-line. Are you proposing a >>>>> single repository/single codebase or simply looking for better >>>>> integration? >>>>> Burr >>>>> >>>>> Bill Burke wrote: >>>>>> >>>>>> >>>>>> Bill Burke wrote: >>>>>>> >>>>>>> >>>>>>> Burr Sutter wrote: >>>>>>>> The "cons" for jBPM-based orchestration: >>>>>>>> - Does require learning of jPDL and jBPM actions. This is not >>>>>>>> a trivial undertaking. >>>>>>> >>>>>>> This is a relevant issue, but I think we can refactor base jbpm >>>>>>> to handle the simple usecases. >>>>>>> >>>>>>> >>>>>>>> - It requires lots of setup & configuration for jBPM such as >>>>>>>> getting the database configured correctly and Hibernate mapped >>>>>>>> correctly. This is not well documented and involves some >>>>>>>> heavy lifting on the part of the user. It is improving but >>>>>>>> does have a real learning curve. >>>>>>>> >>>>>>> >>>>>>> I think this is an irrelevant issue. This can be fixed. ESB >>>>>>> 4.0 release had the same problems. >>>>>>> >>>>>> >>>>>> Let me expand on this. Burr, we have to stop thinking of other >>>>>> JEMS projects like black boxes. >>>>>> >>>>>> a) Its all open source >>>>>> b) We all work for the same company >>>>>> c) jBPM team is under Mark anyways >>>>>> >>>>>> We need to foster cross-contributors. >>>>>> >>>>>> Bill >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> esb-dev mailing list >>> esb-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/esb-dev >

I've had similar debates in the past and the scenario below is a likely candidate for how we'll go to market on the "platform" therefore better integration at the "project" level makes great sense. The market wants SOA to solve a governance, SLA performance, policy enforcement and most importantly visibility issue (who has the ball, who dropped the ball, why was it dropped, how to re-route around the broken connection, etc). BPEL can actually solve this use case and we'll need to carefully think it through since the market is moving in that direction. If you wrap your task management code with Web Services then they can be orchestrated into a BPEL process definition. The crawl before we walk and walk before we run approach would be to take what Esteban has done with basic jBPM JPDL integration and smooth off the rough edges on jbpm configuration and the programming model and get some users on board with the ideas (such as the one described below). At the same priority level we'll need solid WS-* support and BPEL. Perhaps JPDL can outrun BPEL the way Hibernate outran EJB Entity Beans or Spring outran Session Beans but I'm not so sure of that. jBPM has to become much, much more user friendly for both service orchestration and human task-management. It needs an eco-system of people writing articles and books. It needs a series of demonstrations/examples that illustrate its utility. We'll need to find a way to increase its mass adoption. In theory, jBPM should be at least 30% as utilized as Hibernate and Spring. With a well developed ESB approaching the same utilization of J2EE application servers. So the whole BPEL vs JPDL is whole new debate! I think better integration between the ESB & jBPM is something we have wanted for quite some time. Now we'll just need to hammer out the details and get some feedback on the user experience related to the basic integration that has already occurred. Concepts like Advanced Splitter/Aggregator have been on the task list for a little while now and they are likely candidates for jBPM since the "advanced" part is related to long-running processes. In any case, the original debate was related to replacement of the ESB action framework with jBPM's JPDLs action framework. I'm not sure if we've resolved that concern just yet. Bill Burke wrote: > Yeah, Burr. This is exactly the overall picture I envisioned. I > don't see how BPEL could solve such a use case where your overall > flow involves both a messaging system(s) and various web applications. > > This is why I think it is crucial for ESB and jBPM to be built upon > the same component model and core engine. In your use case below, > there really is no clear separation between the ESB and your process > flow. You might want to do transformations between page flows, fork a > notification to a backend system, wait on a task to be performed by a > web application. Do you see how it all bleeds together and why it > all needs to be one integrated product? > > Please, keep arguing. My initial push of having deeper integration > between ESB and jBPM was based on intuition. The more I dive into > it, the more I think my intuition was correct, but I am still not > totally sure. > > Bill > > Burr Sutter wrote: >> Human-centric means there are some features that are particularly >> important like management of swim-lanes, group task queues, >> individual user task queues and a dynamically rendered website that >> allows end-users (accountants, lawyers, clerks, etc) to interact >> with process instances (with supervisor override capability). The >> website/console alone requires about 30+% of the jBPM's teams >> current resources. >> With our current ESB+jBPM integration we should be able to >> orchestrate a single "process" between multiple ESB-hosted services >> and humans. Consider this scenario: >> 1- An order is received via FTP >> 2- Order is routed to a validator >> 3- Order is routed to a transformer >> 4- Order is over $500 and therefore must be sent to a group task >> queue (the order processing team) >> 5- Simultaneously an async credit check request for the customer on >> the order header is made >> 6- Process goes to sleep and awaits a response from the order >> processing team and the credit check >> 7- Once the credit check returns the process is now only waiting on >> the order processing team >> 8- Every 2 hours an alert is sent out to the order processing team >> to let them know that this order is getting old >> 9- Sally (a member of the order processing team) picks up the order >> from the group queue and moves it to her own queue >> 10- She visually inspects the order (nicely transformed by step 3) >> and visually inspects the credit report. While the customers credit >> score from Dun and Bradstreet is somewhat poor, the customer has >> excellent payment history with our business therefore Sally makes >> this additional note on the record and pushes it from her queue to >> her supervisors (additional approval required). >> 11- Her supervisor is currently out on vacation >> 12- Her supervisor's supervisor is covering these tasks and logs >> into to finish the order >> 13- Now that all approvals are secured the order is routed to the >> approach fulfillment team >> 14-Parts of the order require service activation (e.g. this is an >> order for a new cell phone hardware and services) so those >> line-items are split off and routed to the appropriate team - that >> team's queue is updated to reflect the needed work (e.g. some >> services require the dispatch of field workers) >> 15-Parts of the order require multiple warehouses to be notified and >> used (e.g. one line-item is for a phone from warehouse A, another >> line-item is for an blue tooth earbud from warehouse B) both >> warehouses respond with real shipping costs (note customer has >> already been quoted so this is just to offset the real book keeping) >> 16-Various email alerts are collected and properly organized and >> sent out to concerned parties (e.g. the person who initiated the >> order is notified that it has shipped) >> 17- Once all parties report in that there part of the order has been >> fulfilled then accounting is alerted, the executive dashboard is >> updated, etc) >> >> My ESB+jBPM should allow me to see this process laid out visually. >> Allow me to make ad-hoc process changes to both process instances >> that are "above" the current change (altering step 14 for all new >> process instances and process instances living prior to step 14). >> Allow me to have complete visibility into how "long" something is >> taking at any given step (so I can fire my order processing team). >> Allow me to understand who/what is perform optimally (number of >> orders processed, complexity of orders, warehouse A team is rocking >> along, etc). Assuming this end-to-end process involves various 3rd >> parties (e.g. partners who fulfill parts of the process), legacy >> systems (e.g mainframe customer history system) and you still want a >> robust, easily reconfigurable solution - well that is the promise of >> SOA for the enterprise. >> >> >> >> >> Tom Fennelly wrote: >>> Excuse my ignorance, but why exactly do they differentiate between >>> the different types of orchestration (human, service etc)? I'd >>> have just imagined it all as being event-centric, with whatever >>> triggers (??) the event as being somewhat secondary. Where does >>> that fall down?? >>> >>> Burr Sutter wrote: >>>> jBPM 4.0 isn't due until late Q1/early Q2 2008. If we had >>>> specific requirements we might be able to get the jBPM team >>>> focused on a deliverable between now and and then but the >>>> challenge for jBPM is focus: human-centric BPM/workflow or >>>> service-centric orchestration. >>>> Bill Burke wrote: >>>>> Huh? I'm confused on exactly what 4.2 is. Mark told me that it >>>>> should basically be in maintenance mode and only one person was >>>>> going to be maintaining it while the rest of the team focused on >>>>> 5.0. >>>>> >>>>> Better integration, not a single repository. >>>>> >>>>> Burr Sutter wrote: >>>>>> What is your timeframe for this concept? >>>>>> I don't believe there are enough bodies to throw at jBPM 3.3/3.4 >>>>>> and ESB 4.2 to get them both out the door by June 2007 to bring >>>>>> those different worlds closely in-line. Are you proposing a >>>>>> single repository/single codebase or simply looking for better >>>>>> integration? >>>>>> Burr >>>>>> >>>>>> Bill Burke wrote: >>>>>>> >>>>>>> >>>>>>> Bill Burke wrote: >>>>>>>> >>>>>>>> >>>>>>>> Burr Sutter wrote: >>>>>>>>> The "cons" for jBPM-based orchestration: >>>>>>>>> - Does require learning of jPDL and jBPM actions. This is >>>>>>>>> not a trivial undertaking. >>>>>>>> >>>>>>>> This is a relevant issue, but I think we can refactor base >>>>>>>> jbpm to handle the simple usecases. >>>>>>>> >>>>>>>> >>>>>>>>> - It requires lots of setup & configuration for jBPM such as >>>>>>>>> getting the database configured correctly and Hibernate >>>>>>>>> mapped correctly. This is not well documented and involves >>>>>>>>> some heavy lifting on the part of the user. It is improving >>>>>>>>> but does have a real learning curve. >>>>>>>>> >>>>>>>> >>>>>>>> I think this is an irrelevant issue. This can be fixed. ESB >>>>>>>> 4.0 release had the same problems. >>>>>>>> >>>>>>> >>>>>>> Let me expand on this. Burr, we have to stop thinking of other >>>>>>> JEMS projects like black boxes. >>>>>>> >>>>>>> a) Its all open source >>>>>>> b) We all work for the same company >>>>>>> c) jBPM team is under Mark anyways >>>>>>> >>>>>>> We need to foster cross-contributors. >>>>>>> >>>>>>> Bill >>>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> esb-dev mailing list >>>> esb-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/esb-dev >> >

Tom Fennelly wrote: > If so, how will we make sure we can still support situations where > customers want/have a Service Orchestration solution that isn't in > our unified view of the world? > How would you do this regardless if ESB is jBPM based? You'd have to write inbound adapters, wouldn't you? Bill

Closer integration is the goal. Mark. On 27 Mar 2007, at 09:36, Tom Fennelly wrote: > Absolutely.... the only thing I can see being "unifiable" across > these domains would be the process modeling aspects (the sexy GOP > stuff). Even at that, I think that might sound better (and easier) > in theory than practice - and totally irrelevant in many usecases > (distributed, external Services etc). I don't think I'd have > considered it as being a good idea - def not before "solving" them in > isolation first. I was just getting the impression from some of the > mails on this thread that unification was the goal - hence my > confusion/concern. > > Bill Burke wrote: >> >> >> Tom Fennelly wrote: >>> If so, how will we make sure we can still support situations where >>> customers want/have a Service Orchestration solution that isn't in >>> our unified view of the world? >>> >> >> How would you do this regardless if ESB is jBPM based? You'd have >> to write inbound adapters, wouldn't you? >> >> Bill >> > _______________________________________________ > esb-dev mailing list > esb-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/esb-dev

I'm assuming we're still talking about replacing the action framework too. Mark. On 26 Mar 2007, at 17:10, Tom Fennelly wrote: > Sorry, I'm getting a bit confused here. I get the impression we're > talking about orchestration like it's one big black box. So, in > order to try get some clarification, I doctored a picture I threw > together for something else. > > It's a usecase along the lines Burr outlined earlier (Broadband > Provisioning in this case). My confusion with Burr's usecase however > is that we seem to be blurring together 2 different categories of > orchestration that are fundamentally different (at least in my head) > - Service Level Orchestration and Bus Level Orchestration (as we > mentioned a few days ago). I find it difficult to see how you solve > both of them in a unified way without first addressing each of them > in isolation. I think there are solutions there for the Service > Level Orchestration. > > So, I thought we were now just talking about ESB Level Orch based on > jBPM, but I get the impression now that we're talking about a > solution that merges the 2 worlds (that I see anyway :-) ). If so, > how will we make sure we can still support situations where customers > want/have a Service Orchestration solution that isn't in our unified > view of the world? > > > <orchestration-etc.gif> > > > > Burr Sutter wrote: >> I've had similar debates in the past and the scenario below is a >> likely candidate for how we'll go to market on the "platform" >> therefore better integration at the "project" level makes great >> sense. The market wants SOA to solve a governance, SLA performance, >> policy enforcement and most importantly visibility issue (who has >> the ball, who dropped the ball, why was it dropped, how to re-route >> around the broken connection, etc). >> >> BPEL can actually solve this use case and we'll need to carefully >> think it through since the market is moving in that direction. If >> you wrap your task management code with Web Services then they can >> be orchestrated into a BPEL process definition. >> The crawl before we walk and walk before we run approach would be to >> take what Esteban has done with basic jBPM JPDL integration and >> smooth off the rough edges on jbpm configuration and the programming >> model and get some users on board with the ideas (such as the one >> described below). At the same priority level we'll need solid WS-* >> support and BPEL. >> Perhaps JPDL can outrun BPEL the way Hibernate outran EJB Entity >> Beans or Spring outran Session Beans but I'm not so sure of that. >> jBPM has to become much, much more user friendly for both service >> orchestration and human task-management. It needs an eco-system of >> people writing articles and books. It needs a series of >> demonstrations/examples that illustrate its utility. We'll need to >> find a way to increase its mass adoption. In theory, jBPM should be >> at least 30% as utilized as Hibernate and Spring. With a well >> developed ESB approaching the same utilization of J2EE application >> servers. >> >> So the whole BPEL vs JPDL is whole new debate! >> I think better integration between the ESB & jBPM is something we >> have wanted for quite some time. Now we'll just need to hammer out >> the details and get some feedback on the user experience related to >> the basic integration that has already occurred. Concepts like >> Advanced Splitter/Aggregator have been on the task list for a little >> while now and they are likely candidates for jBPM since the >> "advanced" part is related to long-running processes. >> >> In any case, the original debate was related to replacement of the >> ESB action framework with jBPM's JPDLs action framework. I'm not >> sure if we've resolved that concern just yet. >> Bill Burke wrote: >>> Yeah, Burr. This is exactly the overall picture I envisioned. I >>> don't see how BPEL could solve such a use case where your overall >>> flow involves both a messaging system(s) and various web applications. >>> >>> This is why I think it is crucial for ESB and jBPM to be built upon >>> the same component model and core engine. In your use case below, >>> there really is no clear separation between the ESB and your >>> process flow. You might want to do transformations between page >>> flows, fork a notification to a backend system, wait on a task to >>> be performed by a web application. Do you see how it all bleeds >>> together and why it all needs to be one integrated product? >>> >>> Please, keep arguing. My initial push of having deeper integration >>> between ESB and jBPM was based on intuition. The more I dive into >>> it, the more I think my intuition was correct, but I am still not >>> totally sure. >>> >>> Bill >>> >>> Burr Sutter wrote: >>>> Human-centric means there are some features that are particularly >>>> important like management of swim-lanes, group task queues, >>>> individual user task queues and a dynamically rendered website >>>> that allows end-users (accountants, lawyers, clerks, etc) to >>>> interact with process instances (with supervisor override >>>> capability). The website/console alone requires about 30+% of the >>>> jBPM's teams current resources. >>>> With our current ESB+jBPM integration we should be able to >>>> orchestrate a single "process" between multiple ESB-hosted >>>> services and humans. Consider this scenario: >>>> 1- An order is received via FTP >>>> 2- Order is routed to a validator >>>> 3- Order is routed to a transformer >>>> 4- Order is over $500 and therefore must be sent to a group task >>>> queue (the order processing team) >>>> 5- Simultaneously an async credit check request for the customer >>>> on the order header is made >>>> 6- Process goes to sleep and awaits a response from the order >>>> processing team and the credit check >>>> 7- Once the credit check returns the process is now only waiting >>>> on the order processing team >>>> 8- Every 2 hours an alert is sent out to the order processing team >>>> to let them know that this order is getting old >>>> 9- Sally (a member of the order processing team) picks up the >>>> order from the group queue and moves it to her own queue >>>> 10- She visually inspects the order (nicely transformed by step 3) >>>> and visually inspects the credit report. While the customers >>>> credit score from Dun and Bradstreet is somewhat poor, the >>>> customer has excellent payment history with our business therefore >>>> Sally makes this additional note on the record and pushes it from >>>> her queue to her supervisors (additional approval required). >>>> 11- Her supervisor is currently out on vacation >>>> 12- Her supervisor's supervisor is covering these tasks and logs >>>> into to finish the order >>>> 13- Now that all approvals are secured the order is routed to the >>>> approach fulfillment team >>>> 14-Parts of the order require service activation (e.g. this is an >>>> order for a new cell phone hardware and services) so those >>>> line-items are split off and routed to the appropriate team - that >>>> team's queue is updated to reflect the needed work (e.g. some >>>> services require the dispatch of field workers) >>>> 15-Parts of the order require multiple warehouses to be notified >>>> and used (e.g. one line-item is for a phone from warehouse A, >>>> another line-item is for an blue tooth earbud from warehouse B) >>>> both warehouses respond with real shipping costs (note customer >>>> has already been quoted so this is just to offset the real book >>>> keeping) >>>> 16-Various email alerts are collected and properly organized and >>>> sent out to concerned parties (e.g. the person who initiated the >>>> order is notified that it has shipped) >>>> 17- Once all parties report in that there part of the order has >>>> been fulfilled then accounting is alerted, the executive dashboard >>>> is updated, etc) >>>> >>>> My ESB+jBPM should allow me to see this process laid out >>>> visually. Allow me to make ad-hoc process changes to both process >>>> instances that are "above" the current change (altering step 14 >>>> for all new process instances and process instances living prior >>>> to step 14). Allow me to have complete visibility into how "long" >>>> something is taking at any given step (so I can fire my order >>>> processing team). Allow me to understand who/what is perform >>>> optimally (number of orders processed, complexity of orders, >>>> warehouse A team is rocking along, etc). Assuming this end-to-end >>>> process involves various 3rd parties (e.g. partners who fulfill >>>> parts of the process), legacy systems (e.g mainframe customer >>>> history system) and you still want a robust, easily reconfigurable >>>> solution - well that is the promise of SOA for the enterprise. >>>> >>>> >>>> >>>> >>>> Tom Fennelly wrote: >>>>> Excuse my ignorance, but why exactly do they differentiate >>>>> between the different types of orchestration (human, service >>>>> etc)? I'd have just imagined it all as being event-centric, with >>>>> whatever triggers (??) the event as being somewhat secondary. >>>>> Where does that fall down?? >>>>> >>>>> Burr Sutter wrote: >>>>>> jBPM 4.0 isn't due until late Q1/early Q2 2008. If we had >>>>>> specific requirements we might be able to get the jBPM team >>>>>> focused on a deliverable between now and and then but the >>>>>> challenge for jBPM is focus: human-centric BPM/workflow or >>>>>> service-centric orchestration. >>>>>> Bill Burke wrote: >>>>>>> Huh? I'm confused on exactly what 4.2 is. Mark told me that >>>>>>> it should basically be in maintenance mode and only one person >>>>>>> was going to be maintaining it while the rest of the team >>>>>>> focused on 5.0. >>>>>>> >>>>>>> Better integration, not a single repository. >>>>>>> >>>>>>> Burr Sutter wrote: >>>>>>>> What is your timeframe for this concept? >>>>>>>> I don't believe there are enough bodies to throw at jBPM >>>>>>>> 3.3/3.4 and ESB 4.2 to get them both out the door by June 2007 >>>>>>>> to bring those different worlds closely in-line. Are you >>>>>>>> proposing a single repository/single codebase or simply >>>>>>>> looking for better integration? >>>>>>>> Burr >>>>>>>> >>>>>>>> Bill Burke wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Bill Burke wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Burr Sutter wrote: >>>>>>>>>>> The "cons" for jBPM-based orchestration: >>>>>>>>>>> - Does require learning of jPDL and jBPM actions. This is >>>>>>>>>>> not a trivial undertaking. >>>>>>>>>> >>>>>>>>>> This is a relevant issue, but I think we can refactor base >>>>>>>>>> jbpm to handle the simple usecases. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> - It requires lots of setup & configuration for jBPM such >>>>>>>>>>> as getting the database configured correctly and Hibernate >>>>>>>>>>> mapped correctly. This is not well documented and involves >>>>>>>>>>> some heavy lifting on the part of the user. It is >>>>>>>>>>> improving but does have a real learning curve. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think this is an irrelevant issue. This can be fixed. >>>>>>>>>> ESB 4.0 release had the same problems. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Let me expand on this. Burr, we have to stop thinking of >>>>>>>>> other JEMS projects like black boxes. >>>>>>>>> >>>>>>>>> a) Its all open source >>>>>>>>> b) We all work for the same company >>>>>>>>> c) jBPM team is under Mark anyways >>>>>>>>> >>>>>>>>> We need to foster cross-contributors. >>>>>>>>> >>>>>>>>> Bill >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> esb-dev mailing list >>>>>> esb-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>> >>> >> > <orchestration-etc.gif> > _______________________________________________ > esb-dev mailing list > esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/esb-dev

jBPM 4.0 isn't due until late Q1/early Q2 2008. If we had specific requirements we might be able to get the jBPM team focused on a deliverable between now and and then but the challenge for jBPM is focus: human-centric BPM/workflow or service-centric orchestration. Bill Burke wrote: > Huh? I'm confused on exactly what 4.2 is. Mark told me that it > should basically be in maintenance mode and only one person was > going to be maintaining it while the rest of the team focused on 5.0. > > Better integration, not a single repository. > > Burr Sutter wrote: >> What is your timeframe for this concept? >> I don't believe there are enough bodies to throw at jBPM 3.3/3.4 >> and ESB 4.2 to get them both out the door by June 2007 to bring >> those different worlds closely in-line. Are you proposing a >> single repository/single codebase or simply looking for better >> integration? >> Burr >> >> Bill Burke wrote: >>> >>> >>> Bill Burke wrote: >>>> >>>> >>>> Burr Sutter wrote: >>>>> The "cons" for jBPM-based orchestration: >>>>> - Does require learning of jPDL and jBPM actions. This is not >>>>> a trivial undertaking. >>>> >>>> This is a relevant issue, but I think we can refactor base jbpm >>>> to handle the simple usecases. >>>> >>>> >>>>> - It requires lots of setup & configuration for jBPM such as >>>>> getting the database configured correctly and Hibernate mapped >>>>> correctly. This is not well documented and involves some >>>>> heavy lifting on the part of the user. It is improving but >>>>> does have a real learning curve. >>>>> >>>> >>>> I think this is an irrelevant issue. This can be fixed. ESB >>>> 4.0 release had the same problems. >>>> >>> >>> Let me expand on this. Burr, we have to stop thinking of other >>> JEMS projects like black boxes. >>> >>> a) Its all open source >>> b) We all work for the same company >>> c) jBPM team is under Mark anyways >>> >>> We need to foster cross-contributors. >>> >>> Bill >>> >> > _______________________________________________ esb-dev mailing list esb-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/esb-dev

Option 2 is basically replacing jboss-esb.xml with a .jpdl, right? And we've have a ton of work to do to make .jpdl expressive enough to support what jboss-esb.xml does today. When the ESB was presented to Tom B he suggested we build our own process language on top of jBPM. He thought that would take approximately 2 people 2 months assuming all of the features mapped into the underlying engine. Bill, is this what you are suggesting? Mark Little wrote: > Now I'd have thought we were talking about 1! If you were talking > about 2 then I can see the disconnect. > > Mark. > > > On 22 Mar 2007, at 21:39, Bill Burke wrote: > >> >> >> Tom Fennelly wrote: >>> Are we talking about 2 things here: >>> 1. Service Orchestration. Higher level - sitting above bus and >>> interfacing to it via SOAP, JMS etc (message unaware). In this >>> case, being able to mix and match different process management >>> tools is important (jpdl, bpel etc). >>> 2. Bus Level Orchestration. Lower level - sitting inside the >>> bus. Here you orchestrate message routing (CBR etc), >>> transformation, >>> auditing etc. In this case, perhaps it's not so important to be >>> able to plug and play different process models. This is perhaps >>> where jBPM and ESB Actions cross paths?? >> >> Thanks for clarifying Tom. I've been talking about #2. Although I >> think jBPM would be a very interesting option for #1, you wouldn't be >> an ESB if you couldn't plug in #1. Maybe that's where Mark and I >> have been disconnecting? >> >> Bill >> >> --Bill Burke >> JBoss, a division of Red Hat Inc. > _______________________________________________ esb-dev mailing list esb-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/esb-dev

On 23 Mar 2007, at 03:13, Dan Marchant wrote: > Personally I like the idea of JBPM as a way of gluing the things > together. With that said you could just as easily do this with Drools > as well. I'm not sure if JBossRules can play as much of a role as jBPM, but it's certainly able to fulfill some of the criteria. We're using it successfully for CBR, where it supports XPATH as well as "native" expressions. > Salience could represent the version of the service and > multiple services could be retrieved and run depending on the criteria > of the message. Does the BUS really care about process? Is a service > always part of a process? Depends what you mean by service ;-)

> > My thought is that maybe the initialization of the bus is based on > OSGI/microcontainer and as part of that the process engine loads > based on the definition types (could be JBPM/ variant) that strings > utility based services to business based services. Yes. It should be possible to tie together the components using different technologies in the way you describe. > > I guess the question really is what is the core offering that the ESB > wants to fill going forward? A service infrastructure, a service > router, etc... What do you want people to use the ESB for? Abstracting > existing services, adding new services, aggregation, orchestration? The ESB needs to support all of this. While we'd expect people to write new services from scratch, given where we see ESB, SOA and Web Services taking off, plugging in existing services will be the dominant scenario for the short-to-medium term. The ESB itself doesn't provide orchestration per se but supports it (I hope that distinction makes sense). Things like aggregation, CBR, transformation, are out-of-the-box services/components that plug into the ESB and do "clever" things with the messages. How those services are implemented is important and we've got some good candidates for technology to do this. > > I see alot of conversations about what technologies to use for > replacing existing parts but only a couple comments about the goals of > the ESB. My thoughts are that the ESB needs to very flexible and > whether it has JBPM as an action framework or not for a type of > orchestration is just a different type of provider. +1 > The ESB needs to > be very simple to add and update protocols, formats, transformations, > etc... for a competitive edge. +1 > > The faster you can add any type of protocol, listener, action > framework, etc... the better we can react to the changing demands of > the service space. This also allows additions based on standards > fairly easily. Right now it is a bit messy to incorporate new listener > types, etc... based on various protocols or message formats. +1 > > One of the benefits I see the ESB could give people going forward is a > light-weight service infrastructure that would allow users to talk to > a service in JSON, XML over HTTP, MQ, or whatever someone desires to > talk to the service with. The benefit of the bus is that it opens up > the possibilities of how to manage services, monitor services, route > and version services. +1 > > Thoughts? How do you see people using the bus? Just another framework > or something more useful? A useful framework ;-)?

Mark. > > > > > > On 3/22/07, Burr Sutter <bsutter(a)redhat.com&gt; wrote: >> Option 2 is basically replacing jboss-esb.xml with a .jpdl, right? >> >> And we've have a ton of work to do to make .jpdl expressive enough to >> support what jboss-esb.xml does today. When the ESB was presented to >> Tom B he suggested we build our own process language on top of >> jBPM. He >> thought that would take approximately 2 people 2 months assuming >> all of >> the features mapped into the underlying engine. >> >> Bill, is this what you are suggesting? >> >> >> >> Mark Little wrote: >> > Now I'd have thought we were talking about 1! If you were talking >> > about 2 then I can see the disconnect. >> > >> > Mark. >> > >> > >> > On 22 Mar 2007, at 21:39, Bill Burke wrote: >> > >> >> >> >> >> >> Tom Fennelly wrote: >> >>> Are we talking about 2 things here: >> >>> 1. Service Orchestration. Higher level - sitting above bus and >> >>> interfacing to it via SOAP, JMS etc (message unaware). >> In this >> >>> case, being able to mix and match different process >> management >> >>> tools is important (jpdl, bpel etc). >> >>> 2. Bus Level Orchestration. Lower level - sitting inside the >> >>> bus. Here you orchestrate message routing (CBR etc), >> >>> transformation, >> >>> auditing etc. In this case, perhaps it's not so >> important to be >> >>> able to plug and play different process models. This is >> perhaps >> >>> where jBPM and ESB Actions cross paths?? >> >> >> >> Thanks for clarifying Tom. I've been talking about #2. >> Although I >> >> think jBPM would be a very interesting option for #1, you >> wouldn't be >> >> an ESB if you couldn't plug in #1. Maybe that's where Mark and I >> >> have been disconnecting? >> >> >> >> Bill >> >> >> >> --Bill Burke >> >> JBoss, a division of Red Hat Inc. >> > >> _______________________________________________ >> esb-dev mailing list >> esb-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/esb-dev >>

If a user wants to interact with other process engines, then they'll need to write an action that bridges the two. This is no different than what you are currently doing now with jBPM in JBoss ESB 4.0. Having jBPM as core process engine just takes out one step the user has to do to integrate two of our products that overlap each other. I really think jBPM's core engine is lightweight enough to handle the simple case. If you build in Seam's bi-jection, IoC, and token/message mappings to method invocations (like Seam does) into jBPM there's really no reason the majority of ESB or jBPM actions ever need to see the token or Message interface. What becomes really interesting in this model is that ESB components can start to bleed into the Seam web-flow space and JEMS really starts to look like a complete integrated product. If jBPM becomes core, you can let them do what they do best and have them handle writing the ESB's kernel, while ESB team can focus on the interesting enterprise problems. Not only that, but you can start leveraging the jBPM community to gain visibility for ESB rather than jBPM competing with you guys on a bunch of different features and semantics. You know, working with you guys the past few weeks really got me excited of what we can do with JEMS as an integrated product line. Bill Mark Little wrote: > What you're suggesting is strong coupling of jBPM to JBossESB, > such that any user of JBossESB also has to be a user of jBPM. > That's certainly a way of going. However, the way we're going is > to support jBPM on JBossESB in a way that only those users who > want to use/know about jBPM have to know about it and use it. But > if I want to control the flow of messages using some other process > engine, or even mix-and-match with difference engines for > different parts of my application, then I'll be able to. However, > from the perspective of the jBPM user, it shouldn't matter: if we > do it right then they shouldn't notice the difference. We're a > superset of the capabilities you're suggesting so I don't see the > conflict. > Mark. > On 22 Mar 2007, at 20:53, Bill Burke wrote: >> >> >> Burr Sutter wrote: >>> ESB Actions vs jBPM Actions OR Actions vs JBI/SCA/Spring/Seam >>> are different discussions. >>> Let's take the Actions vs JBI/SCA/Spring, etc debate first: >>> - It has been my push in the outbound evangelism to state that >>> actions are not the ideal place for your business logic. Leave >>> your business logic where it lives today in WSs, EJBs, Spring >>> beans, etc and simply enable those components as bus services by >>> building some ESB action glue. - Ideally we'll give you numerous >>> actions "out of the box" (OOTB) that allows you to simply >>> configure the capabilities of your solution. You'll get actions >>> (OOTB) for splitter, aggregator, routing, CBR, transformation, >>> etc. - There will be times when you need to build your own >>> custom actions so that you can enable to a specific endpoint in >>> a specific way. For instance, you might have your own action >>> that handles specialized transformation or specialized routing >>> that the current OOTB actions/engines don't yet handle correctly. >>> Now on the ESB actions vs jBPM actions debate: >>> - jBPM actions have a specific interface/super class that is not >>> "message oriented" they require access to the jBPM context and >>> they are tied to particular "events" like node-enter, node- >>> leave. They are not meant to be "pipelined" or chained together. >> >> I don't believe you are right. After looking at things like >> Servicemix, reading JBPM docs, reading JBPM forums, doing my own >> prototyping, contributing to ESB project, I see so much overlap >> and redundant thinking between the two projects. >> >> On "jBPM actions aren't 'message-oriented': >> >> You can stuff anything you want in a map. Reply-to destination. >> Context data, anything. And you can wire anything in a map into >> an action. Take a look at JBoss's EJB Invocation object. It is >> really a set of 3 maps. 1 map is transient data is not sent >> across the wire. 1 map is a distributable payload that is not >> classloader boundary sensative. The last is a distributable >> payload that is sensitive to classloader boundaries. These maps >> have message information (parameters, and method to be invoked) >> and context information (Tx ID, principal, credentials). JBoss's >> EJB invocation also has a reference to which aspects/interceptors >> that are being invoked, and where in the aspect/interceptor chain >> you are invoking. jBPM has an exact analogous structure. The >> jBPM token could be transformed from an incoming JMS message, or >> transformed to an outgoing XML document, or just sent AS IS. >> (jBPM does exactly this when transitioning over JMS). >> >> On "JBPM actions aren't meant to be pipelined or chained tgoether": >> >> Go look at what JBPM users are doing. >> >>> - ESB actions have a specific interface/super class, they are >>> message oriented (take a Message in), require access to the ESB >>> context and are not tied to any events. They are meant to be >>> chained together (in/out Message objects). >> >> >> Disagree. Takencontent based routing. As you enter the routing >> decision ("node-enter"), you need to transform the message body >> from text to a XML document. As you leave ("node-leave"), you >> might want to notify a auditing layer of what decision was made. >> In a process view, all you want to see at a high level is input >> coming in and what are the decision routes. What I've been >> reading about Tom's philosophy is that the definition of an >> event, action, or node is often blurred depending on how you want >> the process view to look. >> >> BTW, there's no reason the JBPM process instance context and ESB >> message context can't be the same. They already do semantically >> the same thing. >> >>> Technically they are different animals. >> >> I don't think so. Go look at jBPM 3.2. Its starting to look >> very much like an ESB except it includes long-running processes >> and human interaction as well as the plain vanilla message flow >> that ESB offers. IMO, its only natural for the jBPM team to start >> looking, feeling, and acting like an ESB. Its the same for JBoss >> Rules and workflow. Its only natural for them to head in this >> direction. The thing is though, we're not separate companies, >> we're one company. >> >> >>> Plus jBPM's JPDL isn't feature rich enough to express things >>> like a JMS endpoint service with 4 associated OOTB ESB actions >>> and 2 custom ESB actions that is currently expressed in the >>> jboss-esb.xml. >> >> Ditch jboss-esb.xml. There is nothing complicated there. I've >> already written a prototype that does everything but inbound >> declaration in a process definition. If jBPM 4.0 was ready, I >> could even do inbound declaration. And I'm sure the jBPM team or >> a contributor will end up doing this. Its only natural for them >> to proceed in this direction. Sit on their user forums for a week >> or so like I did and you'll see what I mean. >> >>> jBPM is also focused on the BPM space while the ESB is focused >>> on the EAI space. >> >> I disagree on the focus of jBPM. jBPM is focused on graph >> oriented programming and state machines. Everything else is just >> a plugin. >> >> >>> One is human interaction oriented. The other system to system, >>> application to application, business to business focused. They >>> have 2 fundamentally different usage scenarios. >> >> jBPM is a definition of a state machine. That's it. Message >> flow is pretty fundamental, IMO, to both EAI and BPM. >> >> >>> It should be noted that we believe ESB users will also wish to >>> involve humans and long-running "processes" in which case having >>> an OOTB ESB action that starts or signals a jBPM process >>> instance is a very good thing (and what Esteban has been working >>> on). Plus having the jBPM action that is clever enough to >>> "signal" an ESB registered service is also important. >> >> My whole point with using jBPM as the action framework is that it >> is lightweight enough to act as a simple action and expandable >> enough to have long running processes and human interaction. >> What's even more interesting is that the state-machine metadata >> could travel along with the message thus giving you smart >> messages. A client could define the message flow and the servers >> just be set of dumb ESB servers that receive smart messages that >> know how to process and route themselves. >> >> >> Tom B and company know how to write state-machines. They also >> know how these state-machines should be implemented to run long >> running processes . ESB teams knows more about the issues of >> remote connections better. Combine them, and you have something >> compelling (1 + 1 > 2). Treat each other as black boxes, and >> JBPM and ESB might as well be two different products from two >> different companies (1 + 1 < 2). >> >> Bill >> >> --Bill Burke >> JBoss, a division of Red Hat Inc. -- Bill Burke JBoss, a division of Red Hat Inc.

One of the community members (Jason) is working on Hibernate integration, though not for this release. EJB3 integration is one of the tasks we've got (http://jira.jboss.com/jira/browse/JBESB-425) for after the release. Does that cover what you had in mind? Mark. On 21 Mar 2007, at 21:53, Bill Burke wrote: > Do we want to add EJB3 for busines_service? Probably add another > 4meg to the distro. But we would have Hibernate too. Eventually > somebody will write the Hibernate/JPA actions that Burr suggested > during the meeting in Westford. > > Kurt T Stam wrote: >> Starting work on more_action >> TODO >> business_service (this is ejb3, and will require deploying to the >> appserver) >> webservice_war1 (this requires a WS stack, which also requires the >> appserver). >> Mark Little wrote: >>> I thought we decided on today's SILC meeting to postpone the jBPM >>> demo because of lack of time? >>> >>> Mark. >>> >>> >>> On 21 Mar 2007, at 18:44, Kurt T Stam wrote: >>> >>>> OK I think we should leave aggregator alone, as it has no real >>>> deployment now. I'm starting on fun_cbr. >>>> >>>> TODO: >>>> >>>> business_service >>>> webservice_war1 >>>> jbpm_simple1 >>>> more_action >>>> >>>> Kurt T Stam wrote: >>>>> The work that needs be done is building an .esb archive much like >>>>> the custom-action.jar but in addition it need to contain >>>>> a jboss-esb.xml in META-INF, and then changing the deployToSAR >>>>> task to deploy, which should deploy this archive to the >>>>> server/default/deploy directory. If the sample contains queue >>>>> definitions you may add this to the root of the .esb archive. >>>>> >>>>> For most samples I'm leaving the "ant run" task to start esb >>>>> through the bootstrapper. >>>>> >>>>> I'm taking static_router and simple_cbr right now. >>>>> >>>>> Cheers, >>>>> >>>>> --Kurt >>>>> >>>>> Kurt T Stam wrote: >>>>>> TODO: >>>>>> aggregator >>>>>> business_service >>>>>> fun_cbr >>>>>> webservice_war1 >>>>>> jbpm_simple1 >>>>>> more_action >>>>>> simple_cbr >>>>>> static_router >>>>>> >>>>>> DONE: >>>>>> helloworld >>>>>> helloworld_action >>>>>> helloworld_db_registration >>>>>> helloworld_file_action >>>>>> helloworld_ftp_action >>>>>> helloworld_sql_action (I'm currently working on this one) >>>>>> scripting_groovy >>>>>> >>>>>> >>>>>> >>>>>> Bill Burke wrote: >>>>>> >>>>>>> We want to port the samples to the new .esb deployment right? >>>>>>> Divide >>>>>>> an conquer here? We each take a few? >>>>>>> >>>>>> _______________________________________________ >>>>>> esb-dev mailing list >>>>>> esb-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>> >>>> _______________________________________________ >>>> esb-dev mailing list >>>> esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>> >> ------------------------------------------------------------------------ >> _______________________________________________ >> esb-dev mailing list >> esb-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/esb-dev > > --Bill Burke > JBoss, a division of Red Hat Inc.