In this post I show you how I setup a little test to see if and how easy I could manage to route the traffic to and from a web service through Mule ESB. The business case for this is an issue that one of our customers ran into when using web services. In a program hundreds of calls are done in a relative short period. Most of the time this isn’t a problem but sometimes vague issues occur. To get a better insight in this issue I want to put Mule in the middle so I can log the request and response and hopefully get a better idea about what is sent across the line. This is called the Web Service Proxy pattern and is commonly used to validate and audit the web service calls. For more background info about this pattern see this article.

To get started I downloaded the Mule Standalone edition here and installed it. That isn’t very hard, just untar the thing and set the MULE_HOME property. Go to the bin directory and give ‘./mule’ and off you go (except for a warning when running on MacOS 64-bit, but it doesn’t seem to harm so far…):

To create a test web service I setup a MockService in SoapUI. Like this:

All you need is a WSDL available. I just picked one from a previous project for testing purposes. With this MockService started you can fire your SOAP requests and will receive a (predefined) response from the MockService:

Next step is create a new Mule project (I still favor Maven above the Mule Studio):

• create new Maven project with

mvn mule-project-archetype:create -DartifactId=WSProxy -DmuleVersion=3.1.2

• Set up the WS Proxy

To create WS Proxy I followed the description here
Note: to make use of the pre-defined ‘pattern’ you must add the following dependency to the pom:

1 2 3 4 5 6

<dependency> <groupId>org.mule.patterns</groupId> <artifactId>mule-patterns-all</artifactId> <version>${mule.version}</version> <scope>provided</scope> </dependency>

My Mule config file looks like this:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

<?xml version="1.0" encoding="UTF-8"?> <mule xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:pattern="http://www.mulesoft.org/schema/mule/pattern" xsi:schemaLocation=" http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/3.1/mule.xsd http://www.mulesoft.org/schema/mule/pattern http://www.mulesoft.org/schema/mule/pattern/3.1/mule-pattern.xsd"> <description> Proxies a Web Service </description> <custom-transformer name="my-transformer" class="nl.redstream.proxy.wsproxy.MyTransformer" /> <object-to-string-transformer name="ObjectToStringTransformer" />   <pattern:web-service-proxy name="my-order-ws-proxy" inboundAddress="http://Pascal-Almas-MacBook-Pro.local:8090/my-order" responseTransformer-refs="ObjectToStringTransformer my-transformer" outboundAddress="http://Pascal-Almas-MacBook-Pro.local:8088/mockDataServiceSoapBinding" /> </mule>

• Fire up the proxy

To run the Mule application just make sure your Mule installation is running and in your project execute the command ‘mvn clean install’
You should see a message in your Mule console like this:

Now we can put the proxy at work by redirecting the SoapUI request to the url: http://Pascal-Almas-MacBook-Pro.local:8090/my-order. It should the be forwarded to the original url and the translator I put in between should output the content to the Mule console:

However if you try this for the first time big chance you will run into this issue (at least I did). To get around this issue modify the soapUI settings like this:

Although it has been a while since I posted about SoapUI I am still receiving questions about the tool. The most frequently asked question is how to solve the error ‘Error import WSDL’ so I will post the steps I took in the past to solve this error, hoping that this might help you. The first step I usually take is to try to open the WSDL in a web browser.
If this is also not working and the WSDL runs on a machine on the world wide web then you have 3 options:

1. No access to internet

Easy to check if that is the case but you might just want to check it out to make sure

2. the link to the wsdl is dead

This often occurs if the source where you got the link from is rather old, like an article on the net that was posted in 2005.

3. a typo is made in the link

Make sure you have the right url with all ‘?’ and ‘/’ in the right place

If the WSDL in the browser is also not working and the WSDL runs on a machine in your local network then please check the following:

1. Make sure you can access the machine over HTTP

Try to ping the machine name or IP address to see if it is accessible from your machine. Although there is a chance the machine is accessible without being ping-able it often gives a good indication.

2. Make sure the web server hosting the wsdl (and webservice) is up

Point your browser to the machine and check if there is a web server running on port 80/8080/8000 or something like that. If the web server is down also the WSDL will not be found.

3. a typo is made in the link

Make sure you have the right url with all ‘?’ and ‘/’ in the right place

If the WSDL is showing up in the browser and the WSDL runs on a machine on the world wide web then you might check the following:

• Need a proxy to access the net

Check to see if your web browser uses a proxy to get access to the net. This is very common if your computer is connected to a companies network. If so, then add this proxy to the preferences in Soap UI so it will use the same proxy.

• a typo is made in the link

Make sure you have the right url with all ‘?’ and ‘/’ in the right place. I also recently heard leading or trailing spaces might lead to unexpected behaviour in SoapUI so please make sure to remove them.

If the WSDL is showing up in the browser and the WSDL runs on a machine in your local network then please check the following:

• a typo is made in the link

Make sure you have the right url with all ‘?’ and ‘/’ in the right place. I also recently heard leading or trailing spaces might lead to unexpected behaviour in SoapUI so please make sure to remove them.

• use the host’s IP address instead of host name

I once got the situation it was only working with the IP address, but apparently not able to resolve the host name, so you could try this.

So, these are the things you could check. I know there will be much more reasons why this error might show up (how about https access for example), but I hope that in your case these steps will help to solve it. If you know other solutions to this problem just let me know, so I can add them to this list.

This will be the last ‘hands-on’ article about testing Oracle WSM setup with SoapUI. I have posted about two other examples here and here. In this example Oracle WSM is configured to verify the signature of the incoming SOAP message (request) and to add a digital signature to the outgoing message (response). How to arrange this in Oracle WSM is described in the book so I won’t describe that here. What I will show is how to setup SoapUI to test the OWSM setup.
The WSDL for which I created a new project in SoapUI is:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

<definitions name="TimeService" targetNamespace="urn:Test:TimeService" xmlns:tns="urn:Test:TimeService" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://schemas.xmlsoap.org/wsdl/">
   <message name="getTime0SoapIn">
      <part name="format" type="xsd:string"/>
   </message>
   <message name="getTime0SoapOut">
      <part name="Result" type="xsd:string"/>
   </message>
   <portType name="TimeServiceSoap">
      <operation name="getTime" parameterOrder="format">
         <input name="getTime0SoapIn" message="tns:getTime0SoapIn"/>
         <output name="getTime0SoapOut" message="tns:getTime0SoapOut"/>
      </operation>
   </portType>
   <binding name="TimeServiceSoap" type="tns:TimeServiceSoap">
      <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
      <operation name="getTime">
         <soap:operation soapAction="getTime" style="rpc"/>
         <input name="getTime0SoapIn">
            <soap:body use="encoded" namespace="urn:Test:GetTime" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
         </input>
         <output name="getTime0SoapOut">
            <soap:body use="encoded" namespace="urn:Test:GetTime" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
         </output>
      </operation>
   </binding>
   <service name="TimeService">
      <port name="TimeServiceSoap" binding="tns:TimeServiceSoap">
         <soap:address location="http://localhost:3115/gateway/services/SID0003004"/>
      </port>
   </service>
</definitions>

The configuration for the verification of the SOAP request is configured in Oracle WSM like this:

To have SoapUI adding a signature to the outgoing request I took the following steps:

• added my keystore to the project:
  

• added a configuration step called ‘SignRequest’ to the project as Outgoing WS-Security Configuration:
  
• added a configuration step called ‘verifySignature’ to the project as Incoming WS-Security Configuration:
  
• configured the SOAP request with which the OWSM is tested:
  

Now with all this in place I sent the request and received the following response:

1
2
3
4
5
6
7
8
9

<soap-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <soap-ENV:Body>
      <soap-ENV:Fault>
         <faultcode xmlns:p="http://schemas.oblix.com/ws/2003/08/Faults">p:Client.GenericFault</faultcode>
         <faultstring>WS-Security process failure:null</faultstring>
         <detail/>
      </soap-ENV:Fault>
   </soap-ENV:Body>
</soap-ENV:Envelope>

It took some time before I realized the error was not my configuration of SoapUI. In the log file of OWSM I found this stacktrace:

2009-01-17 20:23:03,452 WARNING [HTTPThreadGroup-8] wssecurity.SecurityBaseStep – Failure while applying XML Security
java.lang.NullPointerException
at oracle.security.xmlsec.util.XMLNode.removeChild(Unknown Source)
at com.cfluent.policysteps.security.wssecurity.OSDTWSSecurity.decryptVerify(OSDTWSSecurity.java:538)
at com.cfluent.policysteps.security.wssecurity.VerifyStep.performXmlSecurity(VerifyStep.java:147)
at com.cfluent.policysteps.security.wssecurity.SecurityBaseStep.execute(SecurityBaseStep.java:238)
at com.cfluent.pipelineengine.container.DefaultPipeline.executeStep(DefaultPipeline.java:124)
at com.cfluent.pipelineengine.container.DefaultPipeline.execute(DefaultPipeline.java:97)
at com.cfluent.pipelineengine.container.DefaultPolicy$DeferredPipeline.execute(DefaultPolicy.java:63)
at com.cfluent.pipelineengine.container.DefaultPolicy$DeferredPipeline.access$300(DefaultPolicy.java:18)
at com.cfluent.pipelineengine.container.DefaultPolicy.execute(DefaultPolicy.java:126)
at com.cfluent.pipelineengine.container.PipelineContainer.execute(PipelineContainer.java:114)
at com.cfluent.agent.Agent.intercept(Agent.java:123)
at com.cfluent.agent.AgentRuntime.intercept(AgentRuntime.java:200)
at com.cfluent.pipelineengine.util.PolicyInvoker.execute(PolicyInvoker.java:30)
at com.cfluent.pipelineengine.util.InvokerChain.execute(InvokerChain.java:30)
at com.cfluent.gateway.Invoker.execute(Invoker.java:118)
at com.cfluent.gateway.listener.ProtocolListener$ListenerTask.run(ProtocolListener.java:272)
at com.cfluent.gateway.listener.ProtocolListener.invoke(ProtocolListener.java:110)
at com.cfluent.gateway.listener.GatewayRuntime.invoke(GatewayRuntime.java:32)
at com.cfluent.gateway.listener.http.HttpListener.invoke(HttpListener.java:30)
at com.cfluent.gateway.listener.http.ServicesServlet.handlePost(ServicesServlet.java:34)
at com.cfluent.common.servlet.BaseServlet.doPost(BaseServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:711)
at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:368)
at com.evermind.server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:866)
at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:448)
at com.evermind.server.http.HttpRequestHandler.serveOneRequest(HttpRequestHandler.java:216)
at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:117)
at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:110)
at oracle.oc4j.network.ServerSocketReadHandler$SafeRunnable.run(ServerSocketReadHandler.java:260)
at oracle.oc4j.network.ServerSocketAcceptHandler.procClientSocket(ServerSocketAcceptHandler.java:239)
at oracle.oc4j.network.ServerSocketAcceptHandler.access$700(ServerSocketAcceptHandler.java:34)
at oracle.oc4j.network.ServerSocketAcceptHandler$AcceptHandlerHorse.run(ServerSocketAcceptHandler.java:880)
at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
at java.lang.Thread.run(Thread.java:595)

Now this appears to be a bug (5897046) in OWSM as discussed here. Unfortunately I do not have access to MetaLink at the moment, so I cannot check for solutions or patches. The workaround I did was to skip the deletion of the signature in the incoming request:

Now when I send the request I get the response as expected:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

<soap:Envelope soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:oas="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
   <soap:Header>
      <wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wsse:BinarySecurityToken ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" wsu:Id="_b5MY1ev1b2sj4s0nZL2VDg22" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">MIICBDCCAW0CBElt0WUwDQYJKoZIhvcNAQEFBQAwSTELMAkGA1UEBhMCTkwxETAPBgNVBAoMCHBhbG1hLWl0MRIwEAYDVQQLDAlkZXZlbG9wZXIxEzARBgNVBAMMCnBhc2NhbGFsbWEwHhcNMDkwMTE0MTE0OTU3WhcNMDkwNzEzMTE0OTU3WjBJMQswCQYDVQQGEwJOTDERMA8GA1UECgwIcGFsbWEtaXQxEjAQBgNVBAsMCWRldmVsb3BlcjETMBEGA1UEAwwKcGFzY2FsYWxtYTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApSBk3VobSFPMBuzkWpHvVsQLxWcICzOXWuhescOPqgvkQRfBl6g99v/O+73l0eJjrS/ayUf9fNs/VpUWrgHJ2AMD2/tRKrjfOV9YpG9HcupGB74ygpJ4lDy9VY6KxDDnNF0G6q1oJEZWhHkfupTZIZh70DzRVXqrzf6WqXOzd7MCAwEAATANBgkqhkiG9w0BAQUFAAOBgQAGJAPB24oqfBSlUXXBg/krsKKKPKgpxKV5mpoSf+G9WVjIgK1lplURht2Wyecze91MKhQONMqecHqyIorzXmnO0DWa+ND7exDjcGw+tsagVrxIr1FG85QzJqic+l/uX2+8c5a5m85+o0qPLQeKAwc8DWuANJXIh7/Fy76H7CAMvg==</wsse:BinarySecurityToken>
         <dsig:Signature xmlns="http://www.w3.org/2000/09/xmldsig#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
            <dsig:SignedInfo>
               <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
               <dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
               <dsig:Reference URI="#519sSPHD1xaC8TcH23RKyA22">
                  <dsig:Transforms>
                     <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                  </dsig:Transforms>
                  <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                  <dsig:DigestValue>lzj1qOFAUqEnuIqM2VGOfLDJ1x8=</dsig:DigestValue>
               </dsig:Reference>
               <dsig:Reference URI="#42uhaWCT0QoDrDGlwKsyZA22">
                  <dsig:Transforms>
                     <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                  </dsig:Transforms>
                  <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                  <dsig:DigestValue>8qR3lN2UDPj2EknUuxaf5Xf+8Ic=</dsig:DigestValue>
               </dsig:Reference>
            </dsig:SignedInfo>
         <dsig:SignatureValue>g9S4GajLoXFtNkLJHRDponTv3ubZe432onBI0xfqHQ1zqtt2lalDwnyxbitBjbLaBcu94Fr0FeL7vst50e6KoujrAwt3lCT3sCsKBnvTFZKRKicKf6AdqAkq+d2PyIr0w2gpGJD5ejot8HaYUhJyXI/ogPiYxUmHqXkJVGcZzQ0=</dsig:SignatureValue>
            <dsig:KeyInfo>
               <wsse:SecurityTokenReference wsu:Id="_Gn6xvVFEyg5rUp3hrpAfYg22" xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
                  <wsse:Reference URI="#_b5MY1ev1b2sj4s0nZL2VDg22"/>
               </wsse:SecurityTokenReference>
            </dsig:KeyInfo>
         </dsig:Signature>
         <wsu:Timestamp wsu:Id="42uhaWCT0QoDrDGlwKsyZA22" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:oas1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <wsu:Created>2009-01-19T10:09:33Z</wsu:Created>
         </wsu:Timestamp>
      </wsse:Security>
   </soap:Header>
   <soap:Body wsu:Id="519sSPHD1xaC8TcH23RKyA22" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
      <n:getTimeResponse xmlns:n="urn:Test:GetTime">
         <result xsi:type="xsd:string">11:09 AM</result>
      </n:getTimeResponse>
   </soap:Body>
</soap:Envelope>

As said before I am currently going through the book ‘Oracle Web Service Manager‘. In chapter 5 of this book an example is given how to configure OWSM to encrypt outgoing and decrypt incoming soap messages for a web service. To test this setup a dotNet client is created. In this post I will show you how you can test the setup by using SoapUI instead.
The first step (assuming that SoapUI is already installed) is to create a keystore on the client machine. This keystore must also be used in the OWSM configuration in the example. To create the keystore and necessary key-pair I use Portecle. I created a new keystore (PKCS based) and added a key for ‘pascalalma’ to it. Here is the screenshot with all the necessary info:

In SoapUI I have created a new project based on the WSDL in the example. At the project level I enter the WS-Security parameters and actions that must be performed. Since the gateway expects the soap message to be encoded I have to encode the outgoing message in SoapUI and decode the incoming response message.
Here is the security configuration at project level. First select the keystore to be used by SoapUI:

Then define the outgoing encryption action:

And the last one, define the incoming decryption action:

Now everything at project level is set. The next step is to tell the request it should use these settings. This is a step that took some time for me to discover. But when you click at the ‘Auth’ tab at the request window you can define the actions that must be executed by SoapUI for the request (and response) of the SOAP call. Here you can find the tab:

And here are the parameters set for the security:

Now, this should be it. Actually kind of straightforward…. But not in my case. I am using SoapUI2.5 and when I sended the request I go the following response back:

1
2
3
4
5
6
7
8
9

<soap-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <soap-ENV:Body>
      <soap-ENV:Fault>
         <faultcode xmlns:p="http://schemas.oblix.com/ws/2003/08/Faults">p:Client.GenericFault</faultcode>
         <faultstring>WS-Security process failure:FAULT CODE: UnsupportedSecurityToken FAULT MESSAGE: An unsupported token was provided</faultstring>
         <detail/>
      </soap-ENV:Fault>
   </soap-ENV:Body>
</soap-ENV:Envelope>

After an extensive search I found out it was a version problem in the SOAP header. OWSM gateway expects an element ‘wsse:Reference’ with attribute
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
but SoapUI was sending the request with ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v1"
When I knew what caused the error the solution was quickly found here. I downloaded the older version of the WSS4J library (wss4j-1.5.3.jar) and put that in the SoapUI/lib/ directory. I also modified the SoapUI/bin/soapui.bat file so the correct version is loaded by SoapUI. And this time the call worked like a charm. The response I got back now was (decrypted by SoapUI of course):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

<soap:Envelope soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soap:Header>
      <wsse:Security soap:mustUnderstand="1" xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="asKWwEekHdcXDlFgYL5yP3w22" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">MIICBDCCAW0CBElt0WUwDQYJKoZIhvcNAQEFBQAwSTELMAkGA1UEBhMCTkwxETAPBgNVBAoMCHBhbG1hLWl0MRIwEAYDVQQLDAlkZXZlbG9wZXIxEzARBgNVBAMMCnBhc2NhbGFsbWEwHhcNMDkwMTE0MTE0OTU3WhcNMDkwNzEzMTE0OTU3WjBJMQswCQYDVQQGEwJOTDERMA8GA1UECgwIcGFsbWEtaXQxEjAQBgNVBAsMCWRldmVsb3BlcjETMBEGA1UEAwwKcGFzY2FsYWxtYTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApSBk3VobSFPMBuzkWpHvVsQLxWcICzOXWuhescOPqgvkQRfBl6g99v/O+73l0eJjrS/ayUf9fNs/VpUWrgHJ2AMD2/tRKrjfOV9YpG9HcupGB74ygpJ4lDy9VY6KxDDnNF0G6q1oJEZWhHkfupTZIZh70DzRVXqrzf6WqXOzd7MCAwEAATANBgkqhkiG9w0BAQUFAAOBgQAGJAPB24oqfBSlUXXBg/krsKKKPKgpxKV5mpoSf+G9WVjIgK1lplURht2Wyecze91MKhQONMqecHqyIorzXmnO0DWa+ND7exDjcGw+tsagVrxIr1FG85QzJqic+l/uX2+8c5a5m85+o0qPLQeKAwc8DWuANJXIh7/Fy76H7CAMvg==</wsse:BinarySecurityToken>
         <xenc:EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
            <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
            <dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
               <wsse:SecurityTokenReference xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
                  <wsse:Reference URI="#asKWwEekHdcXDlFgYL5yP3w22" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
               </wsse:SecurityTokenReference>
            </dsig:KeyInfo>
            <xenc:CipherData>
               <xenc:CipherValue>aSM+UvvqfsS/2Damu9pgg2U1oea1O5CjYZ08pKOG0U8IKTJaRgWIDVfjXZI+Gq4Wmsbsz0oWc6wKYawH23clYedt/ScX1ZpEAAHhSEzV8e/+hl3/vZ8Iq7UfLz3DRAat0cn0B00qW8VI+2j94hdTMQJ1v+EjH+7eQpnq0i09UBg=</xenc:CipherValue>
            </xenc:CipherData>
            <xenc:ReferenceList>
               <xenc:DataReference URI="#_o8iRaqZLI6bBw6wR009kLQ22"/>
            </xenc:ReferenceList>
         </xenc:EncryptedKey>
      </wsse:Security>
   </soap:Header>
   <soap:Body>
      <n:getTimeResponse xmlns:n="urn:Test:GetTime">
         <result xsi:type="xsd:string">12:23 PM</result>
      </n:getTimeResponse>
   </soap:Body>
</soap:Envelope>

Last week I started to have a look at the product ‘Oracle Web Server Manager‘. I am reading a packtpub book about this product and am halfway now. I will post more about this book later but one thing I one to mention already is that there are several examples described which are tested by creating a web service client with .Net. I am not familiar with .Net (and do not have the intention to change that) so I used my favorite tool SoapUI as client to test the Oracle gateway.
The first example is created in chapter 4. In this example basic authentication is added to a web service. The book describes in detail how you do this with Oracle WSM. To test this setup I will use SoapUI. The first step is to create a project in SoapUI based on the web service’s WSDL. I accept the defaults so an example request is generated.
The WSDL of the web service looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

<definitions name="TimeService" targetNamespace="urn:Test:TimeService" xmlns:tns="urn:Test:TimeService" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://schemas.xmlsoap.org/wsdl/">
   <message name="getTime0SoapIn">
      <part name="format" type="xsd:string"/>
   </message>
   <message name="getTime0SoapOut">
      <part name="Result" type="xsd:string"/>
   </message>
   <portType name="TimeServiceSoap">
      <operation name="getTime" parameterOrder="format">
         <input name="getTime0SoapIn" message="tns:getTime0SoapIn"/>
         <output name="getTime0SoapOut" message="tns:getTime0SoapOut"/>
      </operation>
   </portType>
   <binding name="TimeServiceSoap" type="tns:TimeServiceSoap">
      <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
      <operation name="getTime">
         <soap:operation soapAction="getTime" style="rpc"/>
         <input name="getTime0SoapIn">
            <soap:body use="encoded" namespace="urn:Test:GetTime" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
         </input>
         <output name="getTime0SoapOut">
            <soap:body use="encoded" namespace="urn:Test:GetTime" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
         </output>
      </operation>
   </binding>
   <service name="TimeService">
      <port name="TimeServiceSoap" binding="tns:TimeServiceSoap">
         <soap:address location="http://localhost:3115/gateway/services/SID0003001"/>
      </port>
   </service>
</definitions>

If I don’t configure anything in SoapUI and just send the request I get the response:

1
2
3
4
5
6
7
8
9

<soap-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <soap-ENV:Body>
      <soap-ENV:Fault>
         <faultcode xmlns:p="http://schemas.oblix.com/ws/2003/08/Faults">p:Client.AuthenticationFault</faultcode>
         <faultstring>Invalid username or password</faultstring>
         <detail/>
      </soap-ENV:Fault>
   </soap-ENV:Body>
</soap-ENV:Envelope>

which is logical, because I have to supply credentials. These credentials must be added to the SOAP call according to the WS-Security specs. Luckily this is done by SoapUI by default. Here is the configuration of the call in SoapUI:

The SOAP request that is send now looks like this (the raw xml):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:Test:GetTime" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Header>
      <wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wsse:UsernameToken wsu:Id="UsernameToken-32950583" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <wsse:Username>palma</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">alma23</wsse:Password>
            <wsse:Nonce>Ekgk+pK0FhRj8EnzWxFsKg==</wsse:Nonce>
            <wsu:Created>2009-01-15T08:37:08.005Z</wsu:Created>
         </wsse:UsernameToken>
      </wsse:Security>
   </soapenv:Header>
   <soapenv:Body>
      <urn:getTime soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
         <format xsi:type="xsd:string">?</format>
      </urn:getTime>
   </soapenv:Body>
</soapenv:Envelope>

As you might notice a SOAP header is now added with the credentials information. The result now is:

1
2
3
4
5
6
7

<soap:Envelope soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
   <soap:Body>
      <n:getTimeResponse xmlns:n="urn:Test:GetTime">
         <result xsi:type="xsd:string">09:37 AM</result>
      </n:getTimeResponse>
   </soap:Body>
</soap:Envelope>

So this works!

The next example in the book for which I use SoapUI is about encrypting and decrypting the message. This has some more configuration to setup so I will show this in a separate post.

As I have posted before we are using XFire to implement our web service. Unfortunately, we are running into some serious issues with the framework, so we decided to look after another implementation. Since XFire is no longer supported by the community (or at least at a very low profile) and ‘replaced’ by CXF, we decided to have a look at Spring WS. We also have used the Spring Framework throughout our application elsewhere, so this would be a logical choice. After a quick look at the framework it convinced us that this would be the framework to use for our web services. It was easy to set up and well documented.
In this post I will show you how to use StAX to parse and write the SOAP request and response in combination with Spring WS, Maven2 and JBoss.

1. Setup maven

First thing to do is to setup Maven2. I assume this won’t be a problem, so I only show the settings.xml which I use for my Maven2 installation (you can also check out this post and this one):

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

<settings> <localRepository>d:/maven2/repo/</localRepository> <profiles> <profile> <id>default-repositories</id> <repositories> <repository> <id>global</id> <name>External Mirror of Central Repository</name> <url>http://repo1.maven.org/maven2</url> </repository> <repository> <id>repo.maven</id> <url>http://repo1.maven.org/maven2-repoclean-java.net</url> </repository> <repository> <id>jboss.maven</id> <url>http://repository.jboss.com/maven2/</url> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>repo1org</id> <name>External Plugin Repository</name> <url>http://repo1.maven.org/maven2/</url> </pluginRepository> </pluginRepositories> </profile> <profile> <id>dev-environment</id> <activation> <activeByDefault>true</activeByDefault> <property> <name>env</name> <value>dev</value> </property> </activation> <properties> <appserver.home>d:/java/jboss-4.0.5</appserver.home> <server.name>default</server.name> </properties> </profile> </profiles> <activeProfiles> <activeProfile>dev-environment</activeProfile> <activeProfile>default-repositories</activeProfile> </activeProfiles> </settings>

2. Create a Maven2 web project

You can do this with this command (as described in more detail here):
mvn archetype:create -DgroupId=net.pascalalma -DartifactId=spring-ws-test
-DarchetypeArtifactId=maven-archetype-webapp

3. Create the XML Schema’s (XSD) for the request and response SOAP messages

As an example I take the schema of the Spring WS reference documentation. The request is described there and I have added a response myself. Here is the xsd:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:hr="http://www.redstream.nl/hr/schemas" elementFormDefault="qualified" targetNamespace="http://www.redstream.nl/hr/schemas"> <xs:element name="HolidayRequest"> <xs:complexType> <xs:all> <xs:element name="Holiday" type="hr:HolidayType"/> <xs:element name="Employee" type="hr:EmployeeType"/> </xs:all> </xs:complexType> </xs:element> <xs:complexType name="HolidayType"> <xs:sequence> <xs:element name="StartDate" type="xs:date"/> <xs:element name="EndDate" type="xs:date"/> </xs:sequence> </xs:complexType> <xs:complexType name="EmployeeType"> <xs:sequence> <xs:element name="Number" type="xs:integer"/> <xs:element name="FirstName" type="xs:string"/> <xs:element name="LastName" type="xs:string"/> </xs:sequence> </xs:complexType> <xs:element name="HolidayResponse" type="hr:Status" /> <xs:simpleType name="Status"> <xs:restriction base="xs:string"> <xs:enumeration value="DENIED"/> <xs:enumeration value="PENDING"/> <xs:enumeration value="APPROVED"/> </xs:restriction> </xs:simpleType> </xs:schema>

I have stored this schema as ‘hr.xsd’ in the directory ‘$PROJECT_HOME$/WEB-INF/schema’.

4. Configure the web application

We have to reroot the incoming HTTP request to the Spring WS servlet. TO do this we define the Spring WS servlet in the web.xml, like this:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app> <!-- === Servlets === --> <servlet> <servlet-name>spring-ws</servlet-name> <display-name>Spring-WS Servlet</display-name> <servlet-class> org.springframework.ws.transport.http.MessageDispatcherServlet </servlet-class> <init-param> <param-name>transformWsdlLocations</param-name> <param-value>true</param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>spring-ws</servlet-name> <url-pattern>/services/*</url-pattern> </servlet-mapping> <welcome-file-list id="WelcomeFileList"> <welcome-file>index.html</welcome-file> </welcome-file-list> </web-app>

5. Create model classes

Now it’s time to start some Java coding. First I create the model classes that will represent the Objects as described by the xsd. We will have the following classes:
The Employee.java
The Holiday.java
And the HolidayRequest.java

6. Create the StAX parser and writer classes

To get from the incoming XML to our Java model classes we make use of StAX parsing and writing. Here are the two classes that do the XML-Object translation and back:
HolidayRequestReader.java
HolidayResponseWriter.java

7. Implement endpoint/webservice

The last Java class we have to make is the Webservice implementation itself. Since we want to use StAX parsing, I simply extend the Spring class ‘AbstractStaxStreamPayloadEndpoint’:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

package net.pascalalma.ws;   import javax.xml.stream.XMLStreamReader; import javax.xml.stream.XMLStreamWriter;   import net.pascalalma.model.HolidayRequest; import net.pascalalma.xml.HolidayRequestReader; import net.pascalalma.xml.HolidayResponseWriter;   import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; import org.springframework.ws.server.endpoint.AbstractStaxStreamPayloadEndpoint;   public class HolidayRequestService extends AbstractStaxStreamPayloadEndpoint {   private static final Log LOG = LogFactory.getLog(HolidayRequestService.class);   @Override protected void invokeInternal(XMLStreamReader streamreader, XMLStreamWriter streamwriter) throws Exception { try { HolidayRequest hr = HolidayRequestReader.parseMessage(streamreader);   LOG.info("Result = " + hr);   HolidayResponseWriter.writeResponse(hr, streamwriter); } catch (Throwable t) { LOG.error("Catched exception", t); } } }

8. Setup the SpringWS context

Now that we have all the Java classes in place we have to configure the Spring context that is used by our webservice implementation. In our case it looks like the following XML file that is stored under the name ‘spring-ws-servlet’ in the ‘$PROJECT_HOME$/webapp/WEB-INF’ directory:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd"> <bean class="org.springframework.ws.server.endpoint.mapping.PayloadRootQNameEndpointMapping"> <property name="mappings"> <props> <prop key="{http://www.redstream.nl/hr/schemas}HolidayRequest"> myEndPoint </prop> </props> </property> </bean> <bean id="myEndPoint" class="net.pascalalma.ws.HolidayRequestService" > </bean> <bean id="holiday" class="org.springframework.ws.wsdl.wsdl11.DefaultWsdl11Definition"> <property name="schema" ref="schema" /> <property name="portTypeName" value="HumanResource" /> <property name="locationUri" value="http://localhost:8080/spring-ws-test/services/holidayService/" /> <property name="targetNamespace" value="http://www.redstream.nl/hr/definitions" /> </bean> <bean id="schema" class="org.springframework.xml.xsd.SimpleXsdSchema"> <property name="xsd" value="/WEB-INF/schemas/hr.xsd" /> </bean> </beans>

9. Build and deploy to jboss

With this file as the project’s POM file we can simply build, package and deploy our webservice to JBoss with the command in the command prompt:
mvn clean package jboss:harddeploy

10. Access wsdl in browser to test

If everything went well and JBoss is started, you can access the dynamically generated WSDL with the following url:
http://localhost:8080/spring-ws-test/services/holiday.wsdl
This should give the following WSDL in your browser:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68

<wsdl:definitions targetNamespace="http://www.redstream.nl/hr/definitions"> <wsdl:types> <xs:schema elementFormDefault="qualified" targetNamespace="http://www.redstream.nl/hr/schemas"> <xs:element name="HolidayRequest"> <xs:complexType> <xs:all> <xs:element name="Holiday" type="hr:HolidayType"/> <xs:element name="Employee" type="hr:EmployeeType"/> </xs:all> </xs:complexType> </xs:element> <xs:complexType name="HolidayType"> <xs:sequence> <xs:element name="StartDate" type="xs:date"/> <xs:element name="EndDate" type="xs:date"/> </xs:sequence> </xs:complexType> <xs:complexType name="EmployeeType"> <xs:sequence> <xs:element name="Number" type="xs:integer"/> <xs:element name="FirstName" type="xs:string"/> <xs:element name="LastName" type="xs:string"/> </xs:sequence> </xs:complexType> <xs:element name="HolidayResponse" type="hr:Status"/> <xs:simpleType name="Status"> <xs:restriction base="xs:string"> <xs:enumeration value="DENIED"/> <xs:enumeration value="PENDING"/> <xs:enumeration value="APPROVED"/> </xs:restriction> </xs:simpleType> </xs:schema> </wsdl:types> <wsdl:message name="HolidayResponse"> <wsdl:part element="sch:HolidayResponse" name="HolidayResponse"> </wsdl:part> </wsdl:message> <wsdl:message name="HolidayRequest"> <wsdl:part element="sch:HolidayRequest" name="HolidayRequest"> </wsdl:part> </wsdl:message> <wsdl:portType name="HumanResource"> <wsdl:operation name="Holiday"> <wsdl:input message="tns:HolidayRequest" name="HolidayRequest"> </wsdl:input> <wsdl:output message="tns:HolidayResponse" name="HolidayResponse"> </wsdl:output> </wsdl:operation> </wsdl:portType> <wsdl:binding name="HumanResourceSoap11" type="tns:HumanResource"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="Holiday"> <soap:operation soapAction=""/> <wsdl:input name="HolidayRequest"> <soap:body use="literal"/> </wsdl:input> <wsdl:output name="HolidayResponse"> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="HumanResourceService"> <wsdl:port binding="tns:HumanResourceSoap11" name="HumanResourceSoap11"> <soap:address location="http://localhost:8080/spring-ws-test/services/holidayService/"/> </wsdl:port> </wsdl:service> </wsdl:definitions>

That’s it. You can test your web service with a tool like SoapUI and create test cases based on the generated WSDL like I described here.

]]> http://www.redstream.nl/2008/06/14/using-stax-with-spring-ws/feed/ 7 http://www.redstream.nl/2008/02/03/creating-an-ejb3-webservice-with-maven2-running-on-jboss-421/ http://www.redstream.nl/2008/02/03/creating-an-ejb3-webservice-with-maven2-running-on-jboss-421/#comments Sun, 03 Feb 2008 09:48:40 +0000 Pascal Alma http://www.pascalalma.net/2008/02/03/creating-an-ejb3-webservice-with-maven2-running-on-jboss-421/ Continue reading →]]>



In this blog I’ll show you how you can create a WebService of your EJB3 objects by using anotations. I will also show you how to build and deploy the package with Maven2. Let’s start with the initial situation.
I have installed JBoss 4.2.1 and Maven2. In my settings.xml of Maven2 I have set a property pointing to my JBoss installation and I have defined a JBoss/Maven2 repository.

The settings.xml file looks like this:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

<settings> <localRepository>d:/maven2/repo/</localRepository> <profiles> <profile> <id>default-repositories</id> <repositories> <repository> <id>global</id> <name>External Mirror of Central Repository</name> <url>http://repo1.maven.org/maven2</url> </repository> <repository> <id>repo.maven</id> <url>http://repo1.maven.org/maven2-repoclean-java.net</url> </repository> <repository> <id>jboss.maven</id> <url>http://repository.jboss.com/maven2/</url> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>repo1org</id> <name>External Plugin Repository</name> <url>http://repo1.maven.org/maven2/</url> </pluginRepository> </pluginRepositories> </profile> <profile> <id>property-overrides</id> <properties> <jboss.home>C:\java\jboss-4.2.1.GA</jboss.home> </properties> </profile> </profiles> <activeProfiles> <activeProfile>property-overrides</activeProfile> <activeProfile>default-repositories</activeProfile> </activeProfiles> </settings>

Lateron we’ll see that Maven uses the JBoss plugin and the property for the deployment of our application.

I have created a project ‘my-ejb-project’ with a simple EJB session bean. The bean (and it’s interface) looks like this:

1 2 3 4 5 6 7 8 9

package net.pascalalma.services;   import javax.ejb.Remote;   @Remote public interface EchoService {   public String sayHello(String subject); }

and the implementation:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

package net.pascalalma.services.impl;   import javax.ejb.Stateless;   import net.pascalalma.services.EchoService;   @Stateless public class EchoServiceBean implements EchoService {   public String sayHello(String name) { return "Hi " + name + "!"; } }

To build this project I have this in the project’s pom.xml file:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74

<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>net.pascalalma</groupId> <artifactId>my-ejb-project</artifactId> <version>1.0</version> <packaging>ejb</packaging>   <build> <sourceDirectory>src/main/java</sourceDirectory> <finalName>my-ejb-project</finalName> <plugins> <plugin> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.5</source> <target>1.5</target> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-javadoc-plugin</artifactId> <configuration> <classpath>/src/main/java</classpath> </configuration> </plugin> <plugin> <artifactId>maven-ejb-plugin</artifactId> <configuration> <ejbVersion>3.0</ejbVersion> <archive> <manifest> <addClasspath>true</addClasspath> </manifest> </archive> </configuration> </plugin> </plugins> </build> <dependencies> <dependency> <groupId>org.apache.geronimo.specs</groupId> <artifactId>geronimo-jpa_3.0_spec</artifactId> <version>1.1</version> <scope>provided</scope> </dependency> <dependency> <groupId>org.apache.geronimo.specs</groupId> <artifactId>geronimo-ejb_3.0_spec</artifactId> <version>1.0</version> <scope>provided</scope> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.1</version> <scope>test</scope> </dependency> </dependencies> <reporting> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-report-plugin</artifactId> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jxr-plugin</artifactId> </plugin> </plugins> </reporting> </project>

Besides this ejb-project I have also created a ear-project that is used to create an ear file containing the EJB’s jar file (and optionally other deliverables like war-file etc). The pom file of this project looks like (the project doesn’t contain anything else):

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>net.pascalalma</groupId> <artifactId>my-ear-project</artifactId> <packaging>ear</packaging> <version>1.0</version> <name>my-ear-project</name> <dependencies> <dependency> <groupId>net.pascalalma</groupId> <artifactId>my-ejb-project</artifactId> <version>1.0</version> <type>ejb</type> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>jboss-maven-plugin</artifactId> <configuration> <jbossHome>${jboss.home}</jbossHome> <serverName>default</serverName> <port>8080</port> </configuration> </plugin> <plugin> <artifactId>maven-ear-plugin</artifactId> <configuration> <displayName>My EJB Component</displayName> <description>My EJB Component</description> <version>1.4</version> <modules> <ejbModule> <groupId>net.pascalalma</groupId> <artifactId>my-ejb-project</artifactId> </ejbModule> </modules> </configuration> </plugin> </plugins> </build> </project>

With all this in place we are able to build the EJB3 project with the command:
c:\workspace\my-ejb-project\mvn clean install
and to package and deploy the EAR project with:
c:\workspace\my-ear-project\mvn clean package jboss:harddeploy

To make our EJB3 bean available as a webservice, we have to add some annotations to the source, so the code of the interface and the bean will become something like this:

1 2 3 4 5 6 7 8 9 10 11

package net.pascalalma.services;   import javax.ejb.Remote; import javax.jws.WebService;   @Remote @WebService() public interface EchoService {   public String sayHello(String subject); }

and the implementation class:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

package net.pascalalma.services.impl;   import javax.ejb.Stateless; import javax.jws.WebService; import javax.jws.soap.SOAPBinding;   import net.pascalalma.services.EchoService;   @Stateless @WebService(endpointInterface = "net.pascalalma.services.EchoService",serviceName="EchoService") @SOAPBinding(style = javax.jws.soap.SOAPBinding.Style.DOCUMENT) public class EchoServiceBean implements EchoService { @javax.jws.WebMethod() public String sayHello(String name) { return "Hi " + name + "!"; } }

That’s it! The only thing left is that we have to add a new dependency to the pom (for the javax.jws.*). The dependency looks like:

1 2 3 4 5 6

<dependency> <groupId>xfire</groupId> <artifactId>xfire-jsr181-api</artifactId> <version>1.0-M1</version> <scope>provided</scope> </dependency>

As you can see the dependency has the scope ‘provided’ because the library is already available in JBoss, so we don’t want to package it in our jar file.

Now rebuild and redeploy the packages and it is done!

To test the webservice I use my favorite tool ‘Soap UI‘. We can generate the necessary WSDL at runtime by going to the url: ‘http://127.0.0.1:8080/EchoServiceBeanService/EchoServiceBean?wsdl’. The result in SOAP UI looks like this:


After sending the request we will get this respone:


I hope this post makes clear that is easy to make your EJB3 session beans available as a webservice, by simply adding some annotations to your code.

]]> http://www.redstream.nl/2008/02/03/creating-an-ejb3-webservice-with-maven2-running-on-jboss-421/feed/ 20 http://www.redstream.nl/2007/08/24/debugging-soap-by-logging-the-incoming-httprequest/ http://www.redstream.nl/2007/08/24/debugging-soap-by-logging-the-incoming-httprequest/#comments Fri, 24 Aug 2007 11:02:33 +0000 Pascal Alma http://www.pascalalma.net/2007/08/24/debugging-soap-by-logging-the-incoming-httprequest/ Continue reading →]]>



As I described here I had a situation in which we wanted to be able to store all incoming SOAP requests for debugging purposes. The thing that made it a little tricky was that the logging had to be done before the request reached the XFire servlet and after JBoss had decoded the request (it is sent using https) and made it readable for us, humans.
Now I am aware of the HTTPtunnelers and other tools out there that could be used for this, but to find one that works according to our demands and to find out how it works, we decided it would easier/quicker to create a Filter and use that for our needs.
I don’t know about you, but this is really a thing that just has to go wrong with the first attempt. The idea we had for the filter was to do something like this:

• get the request
• get the inputstream
• log the inputstream to log file
• continue the normal process

So we build a filter with the following code (only the main part is shown):

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {   InputStream is = request.getInputStream(); LOG.info( slurp(is)); is.close(); chain.doFilter(request, response); }   private String slurp(InputStream is) throws IOException { StringBuffer out = new StringBuffer(); byte[] b = new byte[4096]; for (int n; (n = is.read(b)) != -1;) { out.append(new String(b, 0, n)); } return out.toString(); }

When you try this implementation of the filter you will definitely receive errors in your web service! This is caused by the fact that the inputstream is already processed in the filter so you can not process it again in your web service/servlet: it just doesn’t receive a body of the request anymore.
After we realized this, I remembered an example of the book ‘Head First Servlets and JSP’. In that book they have a similar problem and to solve it they make their own implementation of the HttpServletRepsonse by constructing a wrapper around the original one. We quickly realized we had to do the same thing here but then for the request. So what we will do in our filter implementation is that we will pass an instance of our LoggingRequest to the chain. In our loggingRequest everything that is read from the inputstream is copied to a stringbuffer and when we get back in our filter (when the reponse is sent back to the client) we get the content of that stringbuffer and we have our desired output. Sounds nice, huh? Well, here is the code of the whole filter:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117

package net.pascalalma.filter;   import java.io.IOException;   import javax.servlet.Filter; import javax.servlet.FilterChain; import javax.servlet.FilterConfig; import javax.servlet.ServletException; import javax.servlet.ServletInputStream; import javax.servlet.ServletRequest; import javax.servlet.ServletResponse; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletRequestWrapper;   import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory;   public class LogRequestFilter implements Filter {   private static final Log LOG = LogFactory.getLog(LogRequestFilter.class);   /** * DoFilter method. */ public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { LoggingRequest req = new LoggingRequest((HttpServletRequest)request); chain.doFilter(req, response); LOG.info(req.getPayload()); }   /** * Init method. */ public void init(FilterConfig config) throws ServletException { }   /** * Destroy method. */ public void destroy() { }   /* Private class definitions */ private class LoggingRequest extends HttpServletRequestWrapper {   private LoggingInputStream is;   public LoggingRequest(HttpServletRequest request) throws IOException { super(request); this.is = new LoggingInputStream(request.getInputStream()); }   @Override public ServletInputStream getInputStream() throws IOException { return is; }   public String getPayload() { return is.getPayload(); } }   private class LoggingInputStream extends ServletInputStream {   private StringBuffer bfr = new StringBuffer(); private ServletInputStream is;   public LoggingInputStream(ServletInputStream is) { super(); this.is = is; }   // Since we are not sure which method is used just overwrite all 4 of them: @Override public int read() throws IOException { int ch = is.read(); if (ch != -1) { bfr.append((char)ch); } return ch; }   @Override public int read(byte[] b) throws IOException { int ch = is.read(b); if (ch != -1) { for (byte byteSingle: b ) bfr.append( (char)byteSingle); } return ch; }   @Override public int read(byte[] b, int o, int l) throws IOException { int ch = is.read(b,o,l); if (ch != -1) { for (byte byteSingle: b ) bfr.append( (char)byteSingle);   } return ch; } @Override public int readLine(byte[] b, int o, int l) throws IOException { int ch = is.readLine(b,o,l); if (ch != -1) { bfr.append(b); } return ch; }   public String getPayload() { return bfr.toString(); } } }

So although it took a little longer then we had planned, it sure was fun to do ;-)

]]> http://www.redstream.nl/2007/08/24/debugging-soap-by-logging-the-incoming-httprequest/feed/ 10 http://www.redstream.nl/2007/08/14/could-it-be-true-a-bug-in-soap-ui/ http://www.redstream.nl/2007/08/14/could-it-be-true-a-bug-in-soap-ui/#comments Tue, 14 Aug 2007 16:51:03 +0000 Pascal Alma http://www.pascalalma.net/?p=57 Continue reading →]]>



While performing the load test of our web service (of course with my favourite tool SoapUI) I was getting some errors when I used a number of threads at a time to call my service. Most error messages were related to an invalid XML format of the incoming message. I was told this probably had something to do with SoapUI (that would be the first drawback with it…). When multiple threads are used in SoapUI to sent the messages, they somehow would get mixed up and invalid SOAP messages were sent. So I was told.
After a few weeks I finally got some time to look in to it. To check if Soap UI was indeed messing up the SOAP messages, we made a Filter that outputted the incoming HTTP request to a log file. This filter was configured to receive the request before it would be received by the XFire servlet, but after it was decoded (we are using HTTPS for our web service communication). I will handle the code for this filter in another post, since it might be handy in other situations too.
After our tests with the filter in place we could only conclude that Soap UI was working correctly (what a surprise ;) ) and that all messages were sent in the correct SOAP format. So that forced us to look for the problem in another direction, may be even our own code ;). Looking for the cause of the problem we soon found out that all errors were traced back to one class (one of our own), the SchemaUtils.java. Here is the main part of the code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

import java.io.IOException;   import javax.xml.parsers.DocumentBuilderFactory; import javax.xml.parsers.ParserConfigurationException; import javax.xml.transform.Source; import javax.xml.transform.stream.StreamSource; import javax.xml.validation.Schema; import javax.xml.validation.SchemaFactory; import javax.xml.validation.Validator;   public class SchemaUtils {   private static final Validator VALIDATOR; private static final SchemaFactory SF; private static final Schema SCHEMAS;   static { try { // Re-using Schema to parse and validate XML documents // create a SchemaFactory that conforms to W3C XML Schema SF = SchemaFactory.newInstance(javax.xml.XMLConstants.W3C_XML_SCHEMA_NS_URI);   final StreamSource sSoapEnv = new StreamSource(MY_XML_CONSTANTS.XSD_SOAP_ENVELOPE); final StreamSource sSoapenc = new StreamSource(MY_XML_CONSTANTS.XSD_SOAP_ENCODING); final StreamSource sMyStuf = new StreamSource(MY_XML_CONSTANTS.XSD_MY_STUF);   SCHEMAS = SF.newSchema(new Source[] {sSoapEnv, sSoapenc, sMyStuf }); VALIDATOR = SCHEMAS.newValidator(); } catch (Throwable e) { throw new ExceptionInInitializerError(e); } }   /** * Validates XML against a XSD. */ public static void validate(Source docSource) throws CustomXMLException {   try { VALIDATOR.validate(docSource, null); } catch (SAXException e) { throw new CustomXMLException(CustomErrorMessage.CUST_XML017, e); } catch (IOException e) { throw new CustomXMLException(CustomErrorMessage.CUST_XML017, e); } } }

As you might known, the class ‘Validator.java’ that is used here is NOT thread safe. This is told in the Javadoc of the class. So instead of pointing our fingers at the tools we were using we should be looking for the problem in our own code.
So actually there are two lessons here to be learned:
1. If there is found an error, please make sure it isn’t in your own code before pointing to others
2. If someone tells you it isn’t a fault in their code, don’t just take that for granted, but try to proove it with a little testcase.

And for the record here is the modified class that is thread safe:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

import java.io.IOException;   import javax.xml.parsers.DocumentBuilderFactory; import javax.xml.parsers.ParserConfigurationException; import javax.xml.transform.Source; import javax.xml.transform.stream.StreamSource; import javax.xml.validation.Schema; import javax.xml.validation.SchemaFactory; import javax.xml.validation.Validator;   public class SchemaUtils {   private static final SchemaFactory SF; private static final Schema SCHEMAS;   static { try { // Re-using Schema to parse and validate XML documents // create a SchemaFactory that conforms to W3C XML Schema SF = SchemaFactory.newInstance(javax.xml.XMLConstants.W3C_XML_SCHEMA_NS_URI);   final StreamSource sSoapEnv = new StreamSource(MY_XML_CONSTANTS.XSD_SOAP_ENVELOPE); final StreamSource sSoapenc = new StreamSource(MY_XML_CONSTANTS.XSD_SOAP_ENCODING); final StreamSource sMyStuf = new StreamSource(MY_XML_CONSTANTS.XSD_MY_STUF);   SCHEMAS = SF.newSchema(new Source[] {sSoapEnv, sSoapenc, sMyStuf }); } catch (Throwable e) { throw new ExceptionInInitializerError(e); } }   /** * Validates XML against a XSD. */ public static void validate(Source docSource) throws CustomXMLException {   try { SCHEMAS.newValidator().validate(docSource, null); } catch (SAXException e) { throw new CustomXMLException(CustomErrorMessage.CUST_XML017, e); } catch (IOException e) { throw new CustomXMLException(CustomErrorMessage.CUST_XML017, e); } } }

]]> http://www.redstream.nl/2007/08/14/could-it-be-true-a-bug-in-soap-ui/feed/ 7 http://www.redstream.nl/2007/07/11/another-common-issue-solved-with-soap-ui/ http://www.redstream.nl/2007/07/11/another-common-issue-solved-with-soap-ui/#comments Wed, 11 Jul 2007 04:43:00 +0000 Pascal Alma http://www.pascalalma.net/?p=43 Continue reading →]]>



Well, I think it is clear now I am a big fan of SoapUI. So here is another post about it. This time I explain how you can use it to perform a load test for your webservice and how to work around a common issue with this test. One of the business rules we have is that a message may only be processed succesfully once. To implement this, a unique referenceNumber is supplied in the body of the SOAP message (I know, it was better to use a policy for that by adding a SOAP header, but this is a piece of legacy I have to deal with). In the webservice (actually in a XFire handler) the referenceNumber is checked against all processed referenceNumbers in a database and if it already exists, a fault message is returned.
To avoid this fault message in our load test we added several steps to our Soap UI testcase that increases this referenceNumber, so it’s unique for every message.
Here is an example of how to do this. First I created a webservice that just echoes the inputted string. Here is the WSDL:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

<wsdl:definitions targetNamespace="http://net.pascalalma.services/EchoService"> <wsdl:types> <xsd:schema targetNamespace="http://net.pascalalma.services/EchoService" elementFormDefault="qualified" attributeFormDefault="qualified"> <xsd:element name="s" type="xsd:string"/> <xsd:element name="echoAnswer" type="xsd:string"/> </xsd:schema> </wsdl:types> <wsdl:message name="echoRequest"> <wsdl:part element="tns:s" name="s"/> </wsdl:message> <wsdl:message name="echoResponse"> <wsdl:part element="tns:echoAnswer" name="echoAnswer"/> </wsdl:message> <wsdl:portType name="EchoService"> <wsdl:operation name="echo"> <wsdl:input message="tns:echoRequest" name="echoRequest"/> <wsdl:output message="tns:echoResponse" name="echoResponse"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="EchoServiceHttpBinding" type="tns:EchoService"> <wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="echo"> <wsdlsoap:operation soapAction="urn:echo"/> <wsdl:input name="echoRequest"> <wsdlsoap:body use="literal"/> </wsdl:input> <wsdl:output name="echoResponse"> <wsdlsoap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="EchoService"> <wsdl:port binding="tns:EchoServiceHttpBinding" name="EchoServiceHttpPort"> <wsdlsoap:address location="http://localhost:8080/XFireTest/services/EchoService"/> </wsdl:port> </wsdl:service> </wsdl:definitions>

I then created a TestCase based on this WSDL and added four steps:

• A properties step

In this step a property is defined to be used in this TestCase.


• A Groovy Script step

This step has the logic to increase the property that is defined in the step before.


• A Transfer step

With this step we copy the value of the (modified) property into the SOAP request before we send it to our webservice.


• The SOAP request step

Final step is sending the request with the modified value.


Now when all this is in place you can run a simple loadtest like this:


In the server where my webservice is running you will get out put like this:

As you can see each call gets a unique number.

Now we change the LoadTest to have multiple threads accessing the webservice at the same time. When we do that like this:


the output becomes:


Now the generated numbers are no longer unique!

To fix this I have added a property and changed the Groovy Script Step so it adds the thread index to the unique part. The Property Step and the Groovy Step become like:

and


And the output now is:


Now that looks better, doesn’t it? All generated ID’s are unique again for every message.

]]> http://www.redstream.nl/2007/07/11/another-common-issue-solved-with-soap-ui/feed/ 16