We actually had this capability at one point (in a crude, but usable
form). It's been lost for some time now though I think.
Where I've also been thinking about this is wrt transformation. At the
moment, if you wanna do a transformation you have to stick in an ugly
action configuration into the listener configuration. It would be nice
if this could happen automagically based on info attached to the
message. This would require the ESB to modify this metadata as the
message flows through the Bus i.e. as it's routing a message it
decorates it with metadata indicating the sender and receiver in the
exchange (plus message data typing info). This can drive a
transformation (if required).
Related to this... if we could support actions annotated with metadata
re supported input and output data formats, it would help the above, but
would also mean we could do "assembly" time checks on pipeline configs.
T.
Mark Little wrote:
On this subject, I remember a long time back Tom and I were talking
about flowing the entire Action chaining information (or portions of
it) along with messages, so you can dynamically build up the chain at
the receiver as the message is processed. Combining that with Rules
would give you some interesting dynamic reconfiguration options for
the server-side processing.
Mark.
On 22 Mar 2007, at 15:59, Mark Little wrote:
> Smart messages are something we've been talking about for a while.
> Tagging rules onto messages is one way that I've been talking with
> Proctor about since last year. The idea of distributing new
> configuration information is interesting and I think we touched on it
> in Boston. Though I think at that time the topic was about global ESB
> management and configuration updates, rather than just the actions.
>
> Mark.
>
>
> On 22 Mar 2007, at 15:54, 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.
>
> _______________________________________________
> 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