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
>>>
>>