[
http://jira.jboss.com/jira/browse/JBIDE-2068?page=comments#action_12409195 ]
Mark Little commented on JBIDE-2068:
------------------------------------
Each Action has a well defined interface (there are exceptions, but we can ignore them for
now). There are essentially three methods: process, processException and processSuccess.
After that Action properties (e.g., one-way versus request-response) are defined in the
jboss-esb.xml
<actions mep="OneWay">
<action name="action1"
class="org.jboss.soa.esb.samples.quickstart.helloworldtxsqlaction.MyAction"
process="displayMessage"
/>
<action name="action2"
class="org.jboss.soa.esb.actions.SystemPrintln" />
</actions>
This says that the MyAction instance and SystemPrintln combination creates a one-way (no
response) service. The MyAction 'process' method is displayMessage (if omitted it
is assumed to be process, as is the case for SystemPrintln).
If you look at the whole service definition in XML it may be clearer how the graphical
construction of services from chaining actions comes together:
<services>
<service
category="myCategory"
name="myTxListener"
description="Hello World TX SQL Action (esb jdbc listener)">
<listeners>
<sql-listener name="SqlGateway"
busidref="helloSQLChannel"
maxThreads="1"
is-gateway="true"/>
<sql-listener name="TxSqlListener"
busidref="TxHelloSQLChannel"
maxThreads="1">
<property name="transacted" value="true"/>
</sql-listener>
</listeners>
<actions mep="OneWay">
<action name="action1"
class="org.jboss.soa.esb.samples.quickstart.helloworldtxsqlaction.MyAction"
process="displayMessage"
/>
<action name="action2"
class="org.jboss.soa.esb.actions.SystemPrintln" />
</actions>
</service>
</services>
Design-time service creator
---------------------------
Key: JBIDE-2068
URL:
http://jira.jboss.com/jira/browse/JBIDE-2068
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: esb
Reporter: Mark Little
Fix For: LATER, 2.2.x
Attachments: SOA Tooling.pdf
When building services within a Service Oriented Infrastructure (SOI) you typically do so
by composition of other services. Those other services are typically discovered
dynamically either by browsing the registry or by broadcasting to the entire SOI. The
information returned by such a search (registry or broadcast) contains service contract
information (such as the SLA, type of service, work it offers etc.) and the developer can
then select the right service(s) from the list. Newly created services (either composites
or atomic) are then published back to the registry (or the SOI).
--
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