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.