We examined some of the header contents through the API. We printed the From, To, and the MessageID from within our MyAction class.

Now modify the MyAction class to print the Action, ReplyTo, RelatesTo, and FaultTo contents of the header to the console.

Here is the listing of the modified MyAction class's method:

public Message displayMessage(Message message) throws Exception {
    System.out.println("&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&");
    System.out.println("From: " +message.getHeader().getCall().getFrom());
    System.out.println("To: " +message.getHeader().getCall().getTo());
    System.out.println("MessageID: " +message.getHeader().getCall().getMessageID());
    System.out.println("Action: " +message.getHeader().getCall().getAction());
    System.out.println("FaultTo: " +message.getHeader().getCall().getFaultTo());
    System.out.println("RelatesTo: " +message.getHeader().getCall().getRelatesTo());
    System.out.println("ReplyTo: " +message.getHeader().getCall().getReplyTo());
    System.out.println("&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&");
    return message;
}

The message context is used to transport the active contextual information when the message is sent to the target service. This may include information such as the current security context, transactional information, or even context specific to the application. This contextual information is not considered to be part of the service contract and is assumed to change between successive message deliveries.

Where the message context really becomes important is when a service pipeline is invoked through an InVM transport, as this can allow the message to be passed by reference. We will learn more about InVM transport in Chapter 5. When the transport passes the message to the target service it will create a copy of the message header and message context, allowing each to be updated in subsequent actions without affecting the invoked service.

Modify the MyAction class to print the context of the ESB message; obtain the context through the getContext() method. You will notice that the context is empty for our sample application as we currently have no security or transactional context attached to the message.

The message format within JBoss ESB allows the consumer and producer to use any payload that suits the purpose of the service contract. No constraints are placed on this payload other than the fact that it must be possible to marshall the payload contents so that the messages can be transported between the consumer and producer.

While this ability is useful for creating composite services, it can be a disadvantage when you need to design services that have an abstract contract, hide the details of the implementation, are loosely coupled, and can easily be reused. In order to encourage the loose coupling of services it is often advantageous to choose a payload that does not dictate implementation, for example XML.

JBoss ESB provides support for enforcing the structure of XML payloads for request and response messages, through the XML schema language as defined through the W3C. An XML Schema Document (XSD) is an abstract, structural definition which can be used to formally describe an XML message and guarantee that a specific payload matches that definition through a process called validation.

Enabling validation on a service is simply a matter of providing the schema associated with the request and/or response messages and specifying the validate attribute, as follows:

<actions inXsd="/request.xsd" outXsd="/response.xsd" validate="true">
  ...
</actions>

This will force the service pipeline to validate the request and response messages against the XSD files, if they are specified, with the request validation occurring before the first service action is executed and the response validation occurring immediately before the response message is sent to the consumer.

If validation of the request or response message does fail then a MessageValidationException fault will be raised and sent to the consumer using the normal fault processing as defined in the MEPs and responses section. This exception can also be seen by enabling DEBUG logging through the mechanism supported by the server.

Add a request.xsd or a response.xsd or both to your actions in the sample application provided. Enable validation and test the output.