By simply declaring the schemas for the service we were able to automatically create a web service endpoint for the ESB service. We then sent a SOAP request to this web service and received a SOAP response back, containing all the authors of the books which the service had in stock. Notice that the WSDL was auto-generated for us, based on the specified schemas, when the application was deployed.

Now that we have a better idea of how a web service is generated from the ESB service, let's examine at how it looks to the actions in the pipeline.

Earlier we stated that the schemas declare the XML format of their respective message bodies. What this means is that the message payload passed in to the service from the web service will be the XML representation of the SOAP body and that the service response payload must be the XML representation of the associated web service response.

The following listing of the MyAction class' process method shows how the payload contents can be manipulated in a straightforward manner. Note that the action expects the request to be in the form of an XML string and creates an XML string payload as a response.

private String _books[] = new String[] {
    "Great Expectations", "Hound Of The Baskervilles",
    "The Da Vinci Code", "The Immortals Of Meluha" };
private String _authors[] = new String[] {
    "Charles Dickens", "Sir Arthur Conan Doyle",
    "Dan Brown", "Amish Tripathi" };

public Message process(Message message) throws Exception {
    String req = (String) message.getBody().get();
    StringBuffer resp = new StringBuffer();
    if (req.indexOf("getAuthors") > 0) {
        resp.append("<ns2:getAuthorsResponsexmlns:ns2="http://chapter8.samples.esb.soa.jboss.org/">");
        for (String author : _authors) {
            resp.append("<return>").append(author).append("</return>");
        }
        resp.append("</ns2:getAuthorsResponse>");
    } else if (req.indexOf("getBooks") > 0) {
        resp.append("<ns2:getBooksResponse xmlns:ns2="http://chapter8.samples.esb.soa.jboss.org/">");
        for (String book : _books) {
            resp.append("<return>").append(book).append("</return>");
        }
        resp.append("</ns2:getBooksResponse>");
    } else {
        resp.append("Unknown request!");
    }
    message.getBody().add(resp);
    return message;
}

Often it is desirable to transform the XML contents of the request and response into objects, in order to enable simpler processing or reuse of existing code or services. This can easily be achieved by introducing a transformation action into the exposed service pipeline, for example by using Smooks or XStream as was covered in Chapter 4, and then routing the message to a second service. This architecture may look like the following:

Note that the second ESB service can be directly consumed by other ESB services and also by the ESB service that is exporting the web service endpoint.

Modify the TestWebService.java file to retrieve the books. Update MyAction to perform fault handling. Go ahead and add a Smooks transformer after the MyAction configuration and try to remove the MyAction process methods' XML String code.

An ESB service exported through a web service endpoint can be secured through the usual service security mechanism, specified through configuration of the <security> element within the service definition. As with any other service you will need to specify the moduleName and rolesAllowed attributes to control how the authentication and authorization occurs.

The web service endpoint will extract the security credentials from the incoming SOAP request, identified within the request through the security SOAP header. The web service endpoint will recognize the UsernameToken element, the BinarySecurityToken element (for X.509/Kerberos and others), and Security Assertion Markup Language (SAML) assertions.

Specifying the security configuration will ensure that access to the web service will be authenticated and secure.

Here is a sample configuration that can be used to secure connections to EBWS. The sample shows a security module allowing access from users having either the thosewhohaveaccesstows or moreroleswithaccess role.

<service category="SecuredSample" name="SecuredService">
  <security moduleName="SomeSecurityModule"
       rolesAllowed="thosewhohaveaccesstows, moreroleswithaccess"/>
...
</service>