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