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
>