[
http://jira.jboss.com/jira/browse/JBESB-501?page=comments#action_12359060 ]
Tom Fennelly commented on JBESB-501:
------------------------------------
Re removing the ability to chain actions... I don't think we should be throwing out
the baby with the bath water. Not saying I'm a big lover of action chaining in its
current form, but I'd suspect removing the option completely and replacing it with
nothing more than "singleaction + service2service" will meet with some
disapproval from the likes of Burr (and others).
When we got Rosetta first, this was effectively what we had. Plugging
"actions" (code that operates on a message) together meant defining separate
services and routing the message between them. Otherwise you had to write monolithic
actions (un-reuseable). IMO, either option was a total pain in the ass from a
usability/reuseability perspective.
Why can't we have a happy medium of some sort, where chained actions are still
supported but we make "troublesome" actions (for scoping reasons or whatever)
into standalone Services as Kurt describes.
remove action pipeline
----------------------
Key: JBESB-501
URL:
http://jira.jboss.com/jira/browse/JBESB-501
Project: JBoss ESB
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Rosetta
Affects Versions: 4.2 Milestone Release 1
Environment: any
Reporter: Kurt Stam
Assigned To: Mark Little
Fix For: 4.2 Milestone Release 2
I think we should discourage action pipelining as it muddies to waters. I think each
action should be it's own service, and that all communication is service2service. This
way each .esb archive does not have to package up all the Smooks jar (and dependencies).
If we think this adds to much overhead then we should fix this by adding smarts to our
framework, where it figures out if it can make a local call (go over a local transport).
It also muddies the waters from the perspective of a service description if we allow
action chaining.
This also removes the need for TwoWayCouriers, since we might as well forward it onto the
next service, in stead of replying to the current one. I do think we should make an option
for a blocking gateway, where the gateway waits for a a reply from an ESB Service.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira