Enterprise Integration Zone is brought to you in partnership with:

Len DiMaggio is a software QE engineer for JBoss at Red Hat. Len concentrates on open source Java middleware and is located in the USA. Len has been contributing to DZone since 2009. Len is a DZone MVB and is not an employee of DZone and has posted 20 posts at DZone. View Full User Profile

From HTTP to ESB - JBossESB 4.7's New Servlet based HTTP Gateway

02.24.2010
| 19374 views |
  • submit to reddit
One of the primary functions performed by JBossESB is the routing of messages between services. (Remember that, on an ESB, everything is either a message or a service.) The messages that JBoss ESB handles conform to org.jboss.soa.esb.message.Message. Service endpoints that can process messages in this format are described as being "ESB-aware." This is all well and good for services and applications that were designed and written with this message format in mind, but what about other services, including legacy applications, that communicate through other non-ESB aware data formats?

JBossESB handles connecting services that communicate in non-ESB aware message formats through its gateway listeners. These listeners route incoming messages from outside the ESB to ESB services. The ESB's set of gateway listeners (generally referred to as "gateways") support a variety of message formats such as files, FTP, and JMS. These gateways accept messages in a non-ESB aware format onto the ESB and then convert them (actually, they wrap the message payload) into ESB-aware messages before sending them to their service's action pipeline.

In this post, we'll take a look at JBossESB 4.7's new HTTP gateway ("http-gateway" ). [1]

You use an http-gateway to "expose" an ESB-unaware endpoint on the ESB. In other words, an http-gateway enables you to communicate to ESB services through HTTP endpoints, in the familiar format used by Java servlets. This servlet-based approach is made possible by the http-gateway leveraging the JBossESB Server or JBoss Application Server's HTTP container, just as any servlet would. This means that many of the HTTP configuration properties such as port addresses are already handled for you. You don't have to create the entire HTTP configuration for your http-gateway, as many configurations work right out-of-the-box. This is in keeping with other features of JBossESB, such as its rich set of out-of-the-box actions. [2]

A Very Basic Example

Let's take a quick look at a very basic http-gateway configuration. We'll take a longer look at variations of http-gateway usage later on in this post. To begin, let's start small. Here's a service definition taken from the JBossESB user guide [3] that you would create in your JBossESB application's jboss-esb.xml file:
  <service category="Vehicles" name="Cars" description="" invmScope="GLOBAL">
<listeners>
<http-gateway name="Http" />
</listeners>
<actions mep="RequestResponse">
<!-- Service Actions.... -->
</actions>
</service>
Like a lot of things with JBossESB, you can do a lot with a little. Let's examine this example line-by-line:
  • Line 1: Service name and category are used to differentiate the services. Every service has a category and name attribute. JBossESB uses these attributes to register a service's listeners (gateway listeners or ESB-aware listeners) endpoints in a service registry. The InVM transport enables services to communicate using the same JVM and without having to go through a second non-gateway provider. This makes things more efficient as the services don't have use any networking protocols between JVM instances. The "GLOBAL" value indicates that the this service can be invoked using the InVM transport using the same JVM.
  • Line 3: Here's the definition of the http gateway.
  • Line 5: Remember that since the gateway is servlet based, it requires a request/response message exchange pattern (or "mep" for short).
  • Line 6: And, here's where the pipeline of actions would be defined.

Simple, right? Before we move on, did you notice what's not here? Dude, where's my service provider?

Since a provider is not defined, the service uses a the ESB's default HTTP provider. And, since there is no bus reference ID (the busrefid element in a provider definition and then referenced elsewhere in jboss-esb.xml files), the ESB builds the HTTP endpoint that it exposes out of these fields:
     http://<host>:<port>/<.esbname>/http/Vehicles/Cars
The host and port number come from the ESB server. The "<.esbname>" token is the actual name of the deployed .esb archive, minus the .esb extension. Note that while this string is an HTTP URL, it's also an endpoint. The prefix of "http" is actually a namespace that is used for all the http-gateway endpoints.

It's also important to note that the http-gateway listener captures all incoming HTTP requests that match the servlet mapping pattern expressed in the HTTP endpoint. You can make use of this mapping with the gateway's "urlPattern" property. For example, if we modify the service and gateway definition that we just looked at to include a urlPattern:
  <service category="Vehicles" name="Cars" description="" invmScope="GLOBAL">
<listeners>
<http-gateway name="Http" urlPattern="esb-cars/*" />
</listeners>
<actions mep="RequestResponse">
<!-- Service Aactions.... -->
</actions>
</service>

Then, the service's exposed HTTP endpoint would capture incoming HTTP requests at this address:

http://<host>:<port>/<.esbname>/http/esb-cars/*


Creating a Message From a Request

How does the http-gateway actually convert an incoming HTTP request into an ESB message? It depends on the request's MIME type. What controls this is the “core:org.jboss.soa.esb.mime.text.types” configuration property. This property is defined in your server's jbossesb-properties.xml as a semi-colon separated list of character MIME types. The default value of the property includes wildcard support and is set equal to this set:

text/*
application/xml
application/*-xml

The http-gateway uses this property to determine whether the request payload should be decoded into a Java String before it's given to the service, or if the payload should stay as a Byte array, and have the Service perform the decoding itself in an action. The http-gateway can also over-ride the default MIME type with the "payloadAs" attribute. This attribute enables you to have the gateway treat the payload as either “BYTES” or “STRING.” For text payloads, the gateway uses the same character encoding from the request.

What about the other information in the incoming HTTP request?

The request parameters are contained in the RequestParameterMap (a java.util.Map). These request query string parameters are stored as message properties on the ESB message created by the gateway. Full access to the URL arguments/query string is supported in that you can access the parameters in your service's actions by:
  Map params = (Map) message.getProperties().getProperty(“RequestParameterMap”);

 

The RequestInfoMap is another java.util.Map that contains request information such as authType, characterEncoding, HTTP Method, remoteHost, contentLength, etc.. You can access the parameters in your service's actions by:

  Map params = (Map) message.getProperties().getProperty(“RequestInfoMap”);

 

Let's switch gears now and look at a more extensive example.

The http_gateway Quickstart Example

JBossESB release 4.7 includes the aptly named "http_gateway" quickstart example application. (As I always tell people, the quickstarts included with JBossESB are both a great learning tool and a great starting point for developing your own ESB applications.) The http_gateway quickstart demonstrates multiple ways of using the gateway to pass HTTP requests onto ESB services:

  • Basic authentication
  • The default http bus
  • Mapping ESB exceptions to HTTP error codes globally for an http-provider...
  • ...and how to over-ride that global setting
  • Setting up an asynchronous response that changes the default response code
  • Message-Level Security

We'll take these one at a time.

Basic Authentication

The quickstart uses the "java:/jaas/JBossWS" security domain, which is already installed in JBoss ESB/App Server out-of-the-box configuration. The login username is "kermit" and the password is "thefrog". You can see this username/password combination defined in the "server/[server profile]/conf/props/jbossws-roles.properties" file. Let's take a look at the security setting in the quickstart's jboss-esb.xml file:
  <globals>
<!-- Security setting for all http-providers and all EBWSs in this jboss-esb.xml file.-->
<war-security method="BASIC" domain="JBossWS" />
</globals>

 

This "global" section is new with the http-gateway in JBossESB 4.7. Like the comment says, this defines the global security setting for all the http and EBWS providers in this application. The other supported settings for the war-security method are: DIGEST [4] and CLIENT-CERT.

And here's the http-provider definition:

  <http-provider name="http">
<http-bus busid="secureFriends">
<!-- Only users in the "friend" role are allowed
access via the "GET" method. Unspecified
methods are not protected (i.e. are allowed)... -->
<allowed-roles>
<role name="friend" />
</allowed-roles>
<protected-methods>
<method name="GET" />
<method name="POST" />
</protected-methods>
</http-bus>
<!-- Global exception mappings file... -->
<exception mappingsFile="/http-exception-mappings.properties" />
</http-provider>

 

In this file fragment we see:

  • Line 2: Here's where the http-bus definition starts. Note the name chosen for the busid ("secureFriends"). We'll reference this in the definition of the http-gateway in a moment.
  • Line 5: The set of allowed roles starts here.
  • Line 8: And the set of HTTP methods that user in the allowed roles can use is defined here. Note that the http-gateway supports using these HTTP methods: GET, PUT, POST and DELETE
  • Line 14: Here's another global (global to the http-provider, that is) definition. We'll come back to the exception mappingsFile in a bit. This definition enables you to define status codes to be returned for exceptions.

Now, let's look at the actual http-gateway definition:
  <service category="Sales" name="List" description="" invmScope="GLOBAL">
<listeners>
<!-- Receives: http://<host>:<port>/Quickstart_http_gateway/http/sales/* but will be forced to
authenticate because the "sales" bus has basic auth configured (above)... -->
<http-gateway name="sales" busidref="secureFriends" urlPattern="sales/*" />
</listeners>
<actions mep="RequestResponse">
<action name="print" class="org.jboss.soa.esb.samples.quickstart.httpgateway.MyAction"/>
</actions>
</service>

 

Here's where it all ties together:

  • Line 1: The service definition begins here. Note the "GLOBAL InVM scope that we talked about earlier.
  • Line 5: The http-gateway definition is here. Note the reference to the busidref that we defined in the http-bus. Also note the urlPattern. We'll use this pattern when we run the quickstart.
  • Line 6: The message exchange pattern (mep) is RequestResponse as, remember we're dealing with HTTP.
  • Line 7: Our customer action. This class prints out informatin from the request.
OK - let's run the quickstart and see the results.

Where's the client program that we run? Well, this quickstart is different from most of the other quickstarts in that you don't initial the test by generating a message. Remember how the http-provider we defined specified the GET and POST HTTP verbs? To run this part of the quickstart, you can just fire up your favorite browser and send an HTTP GET request by entering this URL:

http://localhost:8080/Quickstart_http_gateway/http/sales/a/b/c

For the sake of illustration, we'll use the lynx (text) browser.
  lynx -dump -source -auth=kermit:thefrog http://localhost:8080/Quickstart_http_gateway/http/sales/a/b/c
Service: Sales:List

------------Http Request Info (XStream Encoded)-------------------
<org.jboss.soa.esb.http.HttpRequest>
<authType>BASIC</authType>
<contextPath>/Quickstart_http_gateway</contextPath>
<localAddr>127.0.0.1</localAddr>
<localName>localhost.localdomain</localName>
<method>GET</method>
<pathInfo>/a/b/c</pathInfo>
<protocol>HTTP/1.0</protocol>
<remoteAddr>127.0.0.1</remoteAddr>
<remoteHost>127.0.0.1</remoteHost>
<remoteUser>kermit</remoteUser>
<contentLength>-1</contentLength>
<requestURI>/Quickstart_http_gateway/http/sales/a/b/c</requestURI>
<scheme>http</scheme>
<serverName>localhost</serverName>
<requestPath>/http/sales</requestPath>
<pathInfoTokens>
<string>a</string>
<string>b</string>
<string>c</string>
</pathInfoTokens>
<queryParams/>
<headers>
<org.jboss.soa.esb.http.HttpHeader>
<name>host</name>
<value>localhost:8080</value>
</org.jboss.soa.esb.http.HttpHeader>
<org.jboss.soa.esb.http.HttpHeader>
<name>accept</name>
<value>text/html, text/plain, audio/mod, image/*, application/msword, application/pdf, application/postscript, application/x-java-jnlp-file, text/sgml, video/mpeg, */*;q=0.01</value>
</org.jboss.soa.esb.http.HttpHeader>
<org.jboss.soa.esb.http.HttpHeader>
<name>accept-language</name>
<value>en</value>
</org.jboss.soa.esb.http.HttpHeader>
<org.jboss.soa.esb.http.HttpHeader>
<name>user-agent</name>
<value>Lynx/2.8.5rel.1 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/0.9.8e-fips-rhel5</value>
</org.jboss.soa.esb.http.HttpHeader>
<org.jboss.soa.esb.http.HttpHeader>
<name>authorization</name>
<value>Basic a2VybWl0OnRoZWZyb2c=</value>
</org.jboss.soa.esb.http.HttpHeader>
</headers>

The Default HTTP Bus in Action

In the next part of the QuickStart we'll take another look a service definition where the definition doesn't reference a bus definition (busidref) and instead uses the "default" http bus. The definition of this service looks like this:
 <service category="Index" name="List" description="" invmScope="GLOBAL">
<listeners>
<!-- Receives: http://<host>:<port>/Quickstart_http_gateway/http/index/*
Uses the default http bus configuration... -->
<http-gateway name="Index" urlPattern="index/*" />
</listeners>
<actions mep="RequestResponse">
<action name="print" class="org.jboss.soa.esb.samples.quickstart.httpgateway.MyAction"/>
</actions>
</service>

Well, there's not a great deal to look at here since the default http bus is being used. To access this service, you point your browser at this URL:

http://localhost:8080/Quickstart_http_gateway/http/index/XXXX/yyy?a=1,b=2

Note that we discussed earlier in this post and that this URL shows, we're able to process request parameters in the URL. Here's what lynx shows us:
 lynx -dump -source http://localhost:8080/Quickstart_http_gateway/http/index/XXXX/yyy?a=1,b=2
Service: Index:List

------------Http Request Info (XStream Encoded)-------------------
<org.jboss.soa.esb.http.HttpRequest>
<contextPath>/Quickstart_http_gateway</contextPath>
<localAddr>127.0.0.1</localAddr>
<localName>localhost.localdomain</localName>
<method>GET</method>
<pathInfo>/XXXX/yyy</pathInfo>
<protocol>HTTP/1.0</protocol>
<queryString>a=1,b=2</queryString>
<remoteAddr>127.0.0.1</remoteAddr>
<remoteHost>127.0.0.1</remoteHost>
<contentLength>-1</contentLength>
<requestURI>/Quickstart_http_gateway/http/index/XXXX/yyy</requestURI>
<scheme>http</scheme>
<serverName>localhost</serverName>
<requestPath>/http/index</requestPath>
<pathInfoTokens>
<string>XXXX</string>
<string>yyy</string>
</pathInfoTokens>
<queryParams>
<entry>
<string>a</string>
<string-array>
<string>1,b=2</string>
</string-array>
</entry>
</queryParams>
<headers>
<org.jboss.soa.esb.http.HttpHeader>
<name>host</name>
<value>localhost:8080</value>
</org.jboss.soa.esb.http.HttpHeader>
<org.jboss.soa.esb.http.HttpHeader>
<name>accept</name>
<value>text/html, text/plain, audio/mod, image/*, application/msword, application/pdf, application/postscript, application/x-java-jnlp-file, text/sgml, video/mpeg, */*;q=0.01</value>
</org.jboss.soa.esb.http.HttpHeader>
<org.jboss.soa.esb.http.HttpHeader>
<name>accept-language</name>
<value>en</value>
</org.jboss.soa.esb.http.HttpHeader>
<org.jboss.soa.esb.http.HttpHeader>
<name>user-agent</name>
<value>Lynx/2.8.5rel.1 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/0.9.8e-fips-rhel5</value>
</org.jboss.soa.esb.http.HttpHeader>
</headers>

 

Take special note of these lines:

  <queryParams>
<entry>
<string>a</string>
<string-array>
<string>1,b=2</string>
</string-array>
</entry>
</queryParams>

 

Let's change the URL a bit and make sure that the query parameters can really be accessed by the service and its actions:

  lynx -dump -source http://localhost:8080/Quickstart_http_gateway/http/index/XXXX/yyy?param1=hello,param2=world

<queryParams>
<entry>
<string>param1</string>
<string-array>
<string>hello,param2=world</string>
</string-array>
</entry>
</queryParams>

 

Yup! It's them!

A Global Exception

In the description of the basic authentication example that we discussed earlier, we skipped over the definition of a global exceptions mapping for the http-provider:

  <!-- Global exception mappings file... -->
<<exception mappingsFile="/http-exception-mappings.properties" />

 

As its name indicates, this feature enables you to define a status code that will be returned for all requests that are received by a service. Let's take a look at the http-exception-mappings.properties file:

  org.jboss.soa.esb.services.security.SecurityServiceException=401
org.jboss.soa.esb.samples.quickstart.httpgateway.MyActionException=502

 

What this file indicates is that all requests that raise an exception of type org.jboss.soa.esb.services.security.SecurityServiceException will result in an HTTP return status code of 401 being returned to the client that sent in the request, and all requests that raise an exception of type org.jboss.soa.esb.samples.quickstart.httpgateway.MyActionException will result in an HTTP return sttaus code of 502 being returned. To illustrate how this, we'll invoke this service:

  <service category="Exceptions" name="Exception1" description="" invmScope="GLOBAL">
<listeners>
<http-gateway name="Exception2" />
</listeners>
<actions mep="RequestResponse">
<!-- Uses the globally defined exception mappings defined on the <http-provider>... -->
<action name="print" class="org.jboss.soa.esb.samples.quickstart.httpgateway.MyExceptionAction"/>
</actions>
</service>

 

The MyExceptionAction class is minimal - just enough code to throw an exception:

  public class MyExceptionAction extends AbstractActionPipelineProcessor {

public MyExceptionAction(ConfigTree config) {
}

public Message process(Message message) throws ActionProcessingException {
throw new MyActionException("MyActionException!!!!");
}

 

To access this service, you point your browser at this URL: http://localhost:8080/Quickstart_http_gateway/http/Exceptions/Exception1

  lynx -dump -source http://localhost:8080/Quickstart_http_gateway/http/Exceptions/Exception1 -error_file=error.txt
org.jboss.soa.esb.couriers.FaultMessageException: org.jboss.soa.esb.samples.quickstart.httpgateway.MyActionException: MyActionException!!!!
at org.jboss.soa.esb.listeners.message.errors.Factory.createExceptionFromFault(Factory.java:50)
at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.pickup(TwoWayCourierImpl.java:207)
at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.attemptDelivery(ServiceInvoker.java:675)
at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.access$200(ServiceInvoker.java:569)
at org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:359)
at org.jboss.soa.esb.client.ServiceInvoker.deliverSync(ServiceInvoker.java:219)
at org.jboss.soa.esb.listeners.gateway.http.HttpGatewayServlet.service(HttpGatewayServlet.java:187)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
at java.lang.Thread.run(Thread.java:636)
Caused by: org.jboss.soa.esb.samples.quickstart.httpgateway.MyActionException: MyActionException!!!!
at org.jboss.soa.esb.samples.quickstart.httpgateway.MyExceptionAction.process(MyExceptionAction.java:34)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:634)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:586)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:420)
at org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:540)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
... 1 more

 

And - here's the return code that we wanted:


 cat error.txt
URL=http://localhost:8080/Quickstart_http_gateway/http/Exceptions/Exception1 (GET)
STATUS=HTTP/1.1 502 Bad Gateway
Over-Riding a Global Exception

It's good to be able to handle all exceptions at a global level. However, there may be times when you will want to receive a different return status code. To do this, you can over-ride that global setting. Here's a service definition to over-ride the global variable that we just discussed:
 <service category="Exceptions" name="Exception2" description="" invmScope="GLOBAL">
<listeners>
<http-gateway name="Exception1">
<!-- Override the exception mappings defined on the <http-provider>... -->
<exception>
<mapping class="org.jboss.soa.esb.samples.quickstart.httpgateway.MyActionException" status="503" />
</exception>
</http-gateway>
</listeners>
<actions mep="RequestResponse">
<!-- Uses the override exception mappings defined on the <http-gateway>... -->
<action name="print" class="org.jboss.soa.esb.samples.quickstart.httpgateway.MyExceptionAction"/>
</actions>
</service>

 

Line 6 is the one that we're interested in. Here's where we map the class that throws the exception to the code that is returned. And, here's what happens:

  lynx -dump -source http://localhost:8080/Quickstart_http_gateway/http/Exceptions/Exception2 -error_file=error.txt
org.jboss.soa.esb.couriers.FaultMessageException: org.jboss.soa.esb.samples.quickstart.httpgateway.MyActionException: MyActionException!!!!
at org.jboss.soa.esb.listeners.message.errors.Factory.createExceptionFromFault(Factory.java:50)
at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.pickup(TwoWayCourierImpl.java:207)
at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.attemptDelivery(ServiceInvoker.java:675)
at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.access$200(ServiceInvoker.java:569)
at org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:359)
at org.jboss.soa.esb.client.ServiceInvoker.deliverSync(ServiceInvoker.java:219)
at org.jboss.soa.esb.listeners.gateway.http.HttpGatewayServlet.service(HttpGatewayServlet.java:187)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
at java.lang.Thread.run(Thread.java:636)
Caused by: org.jboss.soa.esb.samples.quickstart.httpgateway.MyActionException: MyActionException!!!!
at org.jboss.soa.esb.samples.quickstart.httpgateway.MyExceptionAction.process(MyExceptionAction.java:34)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:634)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:586)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:420)
at org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:540)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
... 1 more

cat error.txt
URL=http://localhost:8080/Quickstart_http_gateway/http/Exceptions/Exception2 (GET)
STATUS=HTTP/1.1 503 Service Unavailable

 

An Asynchronous Response

So far, we've only seen synchronous responses to our requests. It's also possible to have the invoked service respond asynchronously. Here's the quickstart's service definition that illustrates this:

  <service category="Async" name="List" description="" invmScope="GLOBAL">
<listeners>
<!-- Receives: http://<host>:<port>/Quickstart_http_gateway/http/Async/List
Uses the default http bus configuration... -->
<http-gateway name="Async">
<asyncResponse statusCode="202">
<payload classpathResource="/readme.txt" contentType="text/plain" characterEncoding="UTF-8" />
</asyncResponse>
</http-gateway>
</listeners>
<actions mep="RequestResponse">
<action name="print" class="org.jboss.soa.esb.samples.quickstart.httpgateway.MyAction"/>
</actions>
</service>

 

  • Line 5: This is where the asynchronous response definition starts. Note that the return code is 202.
  • Line 6: And. we're also able to specify a file, the contents of which will be returned as a static payload in the response along with the return code.

  lynx -dump -source http://localhost:8080/Quickstart_http_gateway/http/Async/List -error_file=error.txt
Overview:
=========
The purpose of the http_gateway quickstart sample is to demonstarte how to
configue a http gateway to pass the http request into ESB service.


Running this quickstart:
========================
Please refer to 'ant help-quickstarts' for prerequisites about the quickstarts
and a more detailed descripton of the different ways to run the quickstarts.

To Run '.esb' archive mode:
===========================
1. In a command terminal window in this folder ("Window1"), type 'ant deploy'.
2. Open the web brower and send http requests to the following addresses. Be sure to
check the Server console after executing each request:
a) http://localhost:8080/Quickstart_http_gateway/http/sales/a/b/c - Will be routed to the Sales:List
service. Will return some details about the request. This Service's <http-gateway> references a
"secureFriends" bus, which contains login configurations. The login username is "kermit" and the
password is "thefrog". It usee the "java:/jaas/JBossWS" security domain, which is already installed
in your JBoss ESB/App Server.
b) http://localhost:8080/Quickstart_http_gateway/http/index/XXXX/yyy?a=1,b=2 - Will be routed to the Index:List
service. Will return some details about the request. This Service's <http-listener> does not refer
to any bus and so simply uses the "default" http bus.
c) http://localhost:8080/Quickstart_http_gateway/http/Exceptions/Exception1 - Will be routed to the
Exceptions:Exception1 service. This service throws a "MyActionException", resulting in a
502 (Bad Gateway) status being returned in accordance with the Exception to HTTP status code
mappings defined globally on the <http-provider>.
d) http://localhost:8080/Quickstart_http_gateway/http/Exceptions/Exception2 - Will be routed to the
Exceptions:Exception2 service. This service also throws a "MyActionException", but the <http-gateway>
on this service overrides the globally defined Exception to HTTP status code mappings defined globally
on the <http-provider> to return a 503 (Service Unavailable) status for the "MyActionException" exception.
e) http://localhost:8080/Quickstart_http_gateway/http/Async/List - Will be routed to the
Async:List service, which responds asynchronously with a 202 (Accepted) response code and a static
payload of this readme.txt.
f) http://localhost:8080/Quickstart_http_gateway/http/soap/ - Will be routed to the
Soap:List service, which requires message level seurity. An 401 error will occur. Now
switch to the command line and run "ant soap". This POSTs a SOAP message, with login credentials
to the gateway. The service should respond successfully this time!!
3. In this folder ("Window1"), type 'ant undeploy'.

cat error.txt
URL=http://localhost:8080/Quickstart_http_gateway/http/Async/List (GET)
STATUS=HTTP/1.1 202 Accepted

SOAP and Security

The quickstart finishes where it began; with an example of some basic security. Here's the service definition:
  <service category="Soap" name="List" description="" invmScope="GLOBAL">
<listeners>
<!-- Receives: http://<host>:<port>/Quickstart_http_gateway/http/soap/*
Execute "ant soap" on command line.... -->
<http-gateway name="soap" busidref="secureFriends" urlPattern="soap/*">
<exception>
<mapping class="org.jboss.soa.esb.services.security.SecurityServiceException" status="401" />
</exception>
</http-gateway>
</listeners>
<actions mep="RequestResponse">
<action name="print" class="org.jboss.soa.esb.samples.quickstart.httpgateway.MyAction"/>
</actions>
</service>

  • Line 5: Here's the http-gateway definition. Note that we're using the "secureFriends" busidref again. (This means that kermit will have to login again.)
  • Line 7: And, here's the exception that we'll throw, with a return status code of 401.

Sure enough, when we send a request, we get that exception and return code:
  lynx -dump -source http://localhost:8080/Quickstart_http_gateway/http/soap -error_file=error.txt
HTTP: Access authorization required.
Use the -auth=id:pw parameter.

Looking up localhost:8080
Making HTTP connection to localhost:8080
Sending HTTP request.
HTTP request sent; waiting for response.
Alert!: Access without authorization denied -- retrying

lynx: Can't access startfile http://localhost:8080/Quickstart_http_gateway/http/soap

cat error.txt
URL=http://localhost:8080/Quickstart_http_gateway/http/soap (GET)
STATUS=HTTP/1.1 401 Unauthorized

 

Now, we could just provide login credentials manually through the browser UI, but we want our client code to be able to do this programatically. The answer to avoiding this exception, is ot have request that we send has to include login credentials. The quickstart's build.xml file provides an ant target to do this for you by invoking the JBossESB HttpRouter action (org.jboss.soa.esb.actions.routing.http.HttpRouter). This action is one of the JBossESB's large set of "out-of-the-box" actions.

  <target name="soap" depends="compile" description="sends a SOAP HTTP request to the http gateway">
<echo>Http Client</echo>
<java fork="yes" classname="org.jboss.soa.esb.actions.routing.http.HttpRouter" failonerror="true">
<arg value="endpointUrl=http://localhost:8080/Quickstart_http_gateway/http/soap/"/>
<!-- The EBWS is secured with container level security -->
<arg value="configurators=HttpProtocol,AuthBASIC"/>
<arg value="method=POST"/>
<arg value="auth-username=kermit"/>
<arg value="auth-password=thefrog"/>
<arg value="authscope-host=localhost"/>
<arg value="authscope-port=8080"/>
<!-- The actual payload to POST -->
<arg value="payload=soap-login.xml"/>
<classpath refid="exec-classpath"/>
</java>
</target>

 

The actual message payload that is sent is defined in the soap-login.xml file is:

  <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<soap:Header>
</soap:Header>

<soap:Body>
</soap:Body>

</soap:Envelope>

 

And, the successful results look like this:

  soap:
[echo] Http Client
[java] Request payload:
[java] <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
[java] xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
[java] xmlns:xsd="http://www.w3.org/2001/XMLSchema">
[java]
[java] <soap:Header>
[java] </soap:Header>
[java]
[java] <soap:Body>
[java] </soap:Body>
[java]
[java] </soap:Envelope>
[java]
[java] --------------------------
[java]
[java]
[java] Response Status Code: 200
[java] Response payload:
[java] Service: Soap:List
[java]
[java] ------------Http Request Info (XStream Encoded)-------------------
[java] <org.jboss.soa.esb.http.HttpRequest>
[java] <authType>BASIC</authType>
[java] <characterEncoding>UTF-8</characterEncoding>
[java] <contentType>text/xml;charset=UTF-8</contentType>
[java] <contextPath>/Quickstart_http_gateway</contextPath>
[java] <localAddr>127.0.0.1</localAddr>
[java] <localName>localhost.localdomain</localName>
[java] <method>POST</method>
[java] <pathInfo>/</pathInfo>
[java] <protocol>HTTP/1.1</protocol>
[java] <remoteAddr>127.0.0.1</remoteAddr>
[java] <remoteHost>127.0.0.1</remoteHost>
[java] <remoteUser>kermit</remoteUser>
[java] <contentLength>268</contentLength>
[java] <requestURI>/Quickstart_http_gateway/http/soap/</requestURI>
[java] <scheme>http</scheme>
[java] <serverName>localhost</serverName>
[java] <requestPath>/http/soap</requestPath>
[java] <pathInfoTokens/>
[java] <queryParams/>
[java] <headers>
[java] <org.jboss.soa.esb.http.HttpHeader>
[java] <name>content-type</name>
[java] <value>text/xml;charset=UTF-8</value>
[java] </org.jboss.soa.esb.http.HttpHeader>
[java] <org.jboss.soa.esb.http.HttpHeader>
[java] <name>user-agent</name>
[java] <value>Jakarta Commons-HttpClient/3.0.1</value>
[java] </org.jboss.soa.esb.http.HttpHeader>
[java] <org.jboss.soa.esb.http.HttpHeader>
[java] <name>content-length</name>
[java] <value>268</value>
[java] </org.jboss.soa.esb.http.HttpHeader>
[java] <org.jboss.soa.esb.http.HttpHeader>
[java] <name>authorization</name>
[java] <value>Basic a2VybWl0OnRoZWZyb2c=</value>
[java] </org.jboss.soa.esb.http.HttpHeader>
[java] <org.jboss.soa.esb.http.HttpHeader>
[java] <name>host</name>
[java] <value>localhost:8080</value>
[java] </org.jboss.soa.esb.http.HttpHeader>
[java] </headers>
[java] </org.jboss.soa.esb.http.HttpRequest>
[java] --------------------------
[java]

 

Closing Thoughts

The JBossESB's new http-gateway provides great flexibility in integrating HTTP applications across the ESB. The http_gateway quickstart illustrates some of this flexibility, and, incidentally, shows just how much you can do without writing a lot of custom code. Did you notice while eading this post, that we didn't have to write support routines to handle authentication, exception handling, and dealing with URL patterns? The http-gateway and the JBossESB did the heavy lifting for us.

Acknowledgements

Thanks to the JBossESB community and its contributors (see http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/Contributors.txt) - and to Kevin Conner for his timely review comments!

References

[1] http://www.jboss.org/community/wiki/HTTPGateway
[2] http://jboss-soa-p.blogspot.com/2009/09/works-great-right-out-of-box.html
[3] http://www.jboss.org/jbossesb/docs/4.7/manuals/html/ProgrammersGuide.html
[4] http://en.wikipedia.org/wiki/Digest_access_authentication

Published at DZone with permission of Len DiMaggio, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Vijay Ivaturi replied on Fri, 2011/06/03 - 4:22am

Hi Len, I checked the source code for HttpServletSecUtil in JBoss ESB 4.7. Looks like it supports on basic authentication. There is a "// TODO: Add support for Client-cert and Digest auth?" comment. Does it mean we cannot use the new HTTP gateway for these other types of authentication?

Vijaya Baskar V... replied on Thu, 2011/10/13 - 11:16am

Hi Len, This article is very useful. I have a question on the security. Is it possible to have more granularity on the "allowed-roles" and "protected-methods". For example, if I want to give access to the method 'GET and PUT' for role 'ROLEA'. And for the other role 'ROLEB', I want to give access to 'POST and DELETE' methods. Is it possible to give such a granular access to the http-gateway? thanks for the help, Vijay

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.