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.