On 22 Mar 2007, at 19:56, Bill Burke wrote:
I don't think you understood what I wrote. I'm talking about
action frameworks, not freakin SOA!
JBossESB is a SOA infrastructure. What we're pushing is the
technology part of SOA, so we need to support it. That means we need
to have a model that allows for SOA applications to be developed. If
you think that SOA is not applicable to ESB in general and JBossESB
specifically then you're wrong. The action framework we currently
have is part of that. Whether or not we support the action framework
going forward is less important than the fact that we support SOA
application development.
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.
Same here, though longer than that. If you want to start comparing
experiences then we can ;-) Though it may end up as a p*ssing
competition!
So really, stop preaching and listen. It becomes annoying at
times.
Tell me about it! It's annoying when people don't listen.
* 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).
Yes we'll allow people to expose fine grained objects via the ESB.
MSFT does the same with .NET as part of their SOA infrastructure.
However, they also support a coarse grained model and encourage
people to use that. Take a look at some of the stuff that Don Box is
currently working on.
* EJB isn't CORBA with SOAP/HTTP.
And you're not listening either. We've had this conversation for many
weeks and it's getting us no where. I didn't mean that EJB on Web
Services is equivalent to CORBA using SOAP/HTTP. But exposing
individual objects on an ESB gives you the same model as CORBA, but
this time using SOAP/HTTP instead of IIOP. CORBA has been taken and
used for exposing fine grained objects. JEE does the exact same
thing. I'm not going to bother preaching the pros and cons of that
model any more though!
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).
JCA is definitely something we want to support.
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.
Well we're not implementing any specifications at the moment, so this
part of your argument is moot. From the feedback we've been getting I
think we're doing well enough so far. It is still too early to say
we're dead before we even got started.
Mark.
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(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
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>>> 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.
--
Bill Burke
JBoss, a division of Red Hat Inc.