Let us create another action class that simply prints the message body. We will add this action to the sample application that was opened up at the beginning of this chapter.
- Right click on the
srcfolder and choose New and select Class:
- Enter the Name as "MyAction", enter the Package as "org.jboss.soa.samples.chapter3", and select the Superclass as "org.jboss.soa.esb.actions.AbstractActionLifecycle":
- Click Finish.
- Add the following imports and the following body contents to the code:
import org.jboss.soa.esb.helpers.ConfigTree; import org.jboss.soa.esb.message.Message; protected ConfigTree _config; public MyAction(ConfigTree config) { _config = config; } public Message displayMessage(Message message) throws Exception { System.out.println("&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&"); System.out.println("&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&"); System.out.println("Body: " + message.getBody().get()); System.out.println("&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&"); return message; } - Click Save.
- Open the
jboss-esb.xmlfile in Tree mode, expand till Actions is displayed in the tree. Select Actions, click Add | Custom Action:
- Enter the Name as "BodyPrinter" and choose the "MyAction" class and "displayMessage" process method:
- Click Save and the application will be deployed. If the server was stopped then deploy it using the Run menu and select Run As | Run on Server:
- Once the application is deployed on the server, run
SendJMSMessage.javaby clicking Run | Run As | Java Application.The following can be seen displayed in the console output:
12:19:32,562 INFO [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 12:19:32,562 INFO [STDOUT] Body: Chapter 3 says Hello! 12:19:32,562 INFO [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
You have just created your own action class that used the Message API to get the main payload of the message and printed it to the console.
Now add another miscellaneous SystemPrintln action after our BodyPrinter. Name it PrintAfter and make sure printfull is set to true. Modify the MyAction class and add additional named content using the getBody().add(name, object) method and see what gets printed on the console.
Here is the actions section of the config file
<actions mep="OneWay">
<action class="org.jboss.soa.esb.actions.SystemPrintln"
name="PrintBefore">
<property name="message"/>
<property name="printfull" value="true"/>
</action>
<action class="org.jboss.soa.esb.samples.chapter3.MyAction"
name="BodyPrinter" process="displayMessage"/>
<action class="org.jboss.soa.esb.actions.SystemPrintln"
name="PrintAfter">
<property name="message"/>
<property name="printfull" value="true"/>
</action>
</actions>The following is the listing of the MyAction class's modified displayMessage method
public Message displayMessage(Message message) throws Exception {
System.out.println("&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&");
System.out.println("Body: " + message.getBody().get());
message.getBody().add("Something", "Unknown");
System.out.println("&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&");
return message;
}The message header contains the information relating to the identity, routing, and the correlation of messages. This information is based on, and shares much in common with, the concepts defined in the W3C WS-Addressing specification.
Every time a message is sent within the ESB it contains information which describes who sent the message, which service it should be routed to, and where any replies/faults should be sent once processing is complete. The creation of this information is the responsibility of the invoker and, once delivered, any changes made to this information, from within the target service, will be ignored by that service.
The information in the header takes the form of Endpoint References (EPRs) containing a representation of the service address, often transport specific, and extensions which can contain relevant contextual information for that endpoint. This information should be treated as opaque by all parties except the party which was responsible for creating it.
There are four EPRs included in the header, they are as follows:
To: This is the only mandatory EPR, representing the address of the service to which the message is being sent. This will be initialized byServiceInvokerwith the details of the service chosen to receive the message.From: This EPR represents the originator of the message, if present, and may be used as the address for responses if there is neither an explicitReplyTonorFaultToset on the message.ReplyTo: This EPR represents the endpoint to which all responses will be sent, if present, and may be used as the address for faults if there is no explicitFaultToset on the message. This will normally be initialized byServiceInvokerif a synchronous response is expected by the service consumer.FaultTo: This EPR represents the endpoint to which all faults will be sent, if present.
When thinking about the routing information it is important to view these details from the perspective of the service consumer, as the EPRs represent the wishes of the consumer and must be adhered to. If the service implementation involves more advanced topologies, like chaining and continuations, which we will discuss later in the chapter, then care must be taken to preserve these EPRs when messages are propagated to subsequent services.
There are two parts of the header which are related to the identity of the message and its correlation with a preceding message. These are as follows:
MessageID: A unique reference which can be used to identify the message as it progresses through the ESB. The reference is represented by a Uniform Resource Name (URN), a specialized Uniform Resource Identifier (URI) which will represent the identity of the message within a specific namespace. The creator of the message may choose to associate it with an identity which is specific to the application context within which it is being used, in which case the URN should refer to a namespace which is also application context specific. If noMessageIDhas been associated with the message then the ESB will assign a unique identifier when it is first sent to a service.RelatesTo: When sending a reply, this represents the unique reference of the message representing the request. This may be used to correlate the response message with the original request.
The action header is an optional, service-specific URN that may be used to further refine the processing of the message by a service provider or service consumer. The URN should refer to an application-specific namespace.
There are no restrictions on how this header is to be used by the application including, if considered appropriate, ignoring its contents.