When you run this class (and leave it running), you can point your browser to go to 'http://localhost:8181/echo?wsdl' and you receive the wsdl for the web service:

You can now test your tool/ product by using this web service.

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.

1. Create the Maven2 project

Issue the command: mvn archetype:create -DgroupId=net.pascalalma.ws -DartifactId=echo-service
This results in a standard Maven project. I removed the generated java files since we don't need them.

2. Setup the pom

The default pom that was created in the first step has to be modified. I added several things which I explain next:

PLAIN TEXT
XML:
1. <dependencies>
2.         ...
3.         <dependency>
4.             <groupId>com.sun.xml.ws</groupId>
5.             <artifactId>jaxws-rt</artifactId>
6.             <version>2.1.4</version>
7.         </dependency>
8.         <dependency>
9.             <groupId>javax.jws</groupId>
10.             <artifactId>jsr181-api</artifactId>
11.             <version>1.0-MR1</version>
12.         </dependency>
13.     ...
14.     </dependencies>

These are dependencies that are used by the JAXWS plugin, which is used to generate the Webservice interface based on the supplied WSDL.

PLAIN TEXT
XML:
1. <dependencies>
2.    ...
3.         <dependency>
4.             <groupId>glassfish</groupId>
5.             <artifactId>appserv-rt.jar</artifactId>
6.             <version>LATEST</version>
7.             <scope>system</scope>
8.             <systemPath>${glassfish.home}/lib/appserv-rt.jar</systemPath>
9.         </dependency>
10.         <dependency>
11.             <groupId>glassfish</groupId>
12.             <artifactId>javaee.jar</artifactId>
13.             <version>LATEST</version>
14.             <scope>system</scope>
15.             <systemPath>${glassfish.home}/lib/javaee.jar</systemPath>
16.         </dependency>
17.    ...
18.    </dependencies>

These dependencies are used to compile the generated code and the WebService implementation class.

Next there are some plugins to be configured:

PLAIN TEXT
XML:
1. <build>
2.         <plugins>
3.         ...
4.             <!-- Plugin to generate JAXB classes and webservice interface -->
5.             <plugin>
6.                 <groupId>org.codehaus.mojo</groupId>
7.                 <artifactId>jaxws-maven-plugin</artifactId>
8.                 <version>1.10</version>
9.                 <executions>
10.                     <execution>
11.                         <goals>
12.                             <goal>wsimport</goal>
13.                         </goals>
14.                     </execution>
15.                 </executions>
16.                 <configuration>
17.                     <wsdlDirectory>
18.                         src/main/resources/wsdl
19.                     </wsdlDirectory>
20.                     <sourceDestDir>
21.                         ${basedir}/generated/src/main/java
22.                     </sourceDestDir>
23.                 </configuration>
24.                 <dependencies>
25.                     <dependency>
26.                         <groupId>javax.jws</groupId>
27.                         <artifactId>jsr181-api</artifactId>
28.                         <version>1.0-MR1</version>
29.                     </dependency>
30.                 </dependencies>
31.             </plugin>
32.             ...
33.         </plugins>
34.     </build>

This plugin is used for the actual generation of the Java code. It will put the code in the 'generated' folder.
The next two plugins are used for compiling and cleaning the code. I have described the use of these plugins here.

PLAIN TEXT
XML:
1. <build>
2.         <plugins>
3.         ...
4.             <!-- Plugin to add delete path to build cycle -->
5.             <plugin>
6.                 <artifactId>maven-clean-plugin</artifactId>
7.                 <version>2.2</version>
8.                 <configuration>
9.                     <filesets>
10.                         <fileset>
11.                             <directory>generated/src/main/java</directory>
12.                             <includes>
13.                                 <include>**/*.java</include>
14.                             </includes>
15.                         </fileset>
16.                     </filesets>
17.                 </configuration>
18.             </plugin>
19.         </plugins>
20.     </build>
21.     ...
22.   </plugins>
23. </build>

And finally I add the necessary code to tell the compiler JDK 1.5 has to be used:

PLAIN TEXT
XML:
1. <build>
2.         <plugins>
3.         ...
4.              <!-- plugin to compile Java1.5 code -->
5.              <plugin>
6.                 <groupId>org.apache.maven.plugins</groupId>
7.                 <artifactId>maven-compiler-plugin</artifactId>
8.                 <version>2.0.2</version>
9.                 <configuration>
10.                     <source>1.5</source>
11.                     <target>1.5</target>
12.                 </configuration>
13.             </plugin>
14.         ...
15.        </plugins>
16.   </build>

The complete pom.xml can be found here.

3. Create the WSDL

As shown in the plugin configuration I have added a WSDL file to a 'wsdl' folder in the 'resource' folder. The WSDL looks like this:

PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2. <wsdl:definitions name="DoubleIt"
3.    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
4.    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
5.    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
6.    xmlns:tns="http://www.pascalalma.net/EchoIt"
7.    xmlns:types="http://www.pascalalma.net/EchoIt/types"
8.    targetNamespace="http://www.pascalalma.net/EchoIt">
9.     <wsdl:types>
10.         <xsd:schema targetNamespace="http://www.pascalalma.net/EchoIt/types">
11.             <xsd:element name="EchoIt">
12.                 <xsd:complexType>
13.                     <xsd:sequence>
14.                         <xsd:element name="textToEcho" type="xsd:string"/>
15.                     </xsd:sequence>
16.                 </xsd:complexType>
17.             </xsd:element>
18.             <xsd:element name="EchoItResponse">
19.                 <xsd:complexType>
20.                     <xsd:sequence>
21.                         <xsd:element name="echoedText" type="xsd:string" />
22.                     </xsd:sequence>
23.                 </xsd:complexType>
24.             </xsd:element>
25.         </xsd:schema>
26.     </wsdl:types>
27.     <wsdl:message name="EchoItRequest">
28.         <wsdl:part element="types:EchoIt" name="parameters" />
29.     </wsdl:message>
30.     <wsdl:message name="EchoItResponse">
31.         <wsdl:part element="types:EchoItResponse" name="parameters" />
32.     </wsdl:message>
33.     <wsdl:portType name="EchoItPortType">
34.         <wsdl:operation name="EchoIt">
35.             <wsdl:input message="tns:EchoItRequest" />
36.             <wsdl:output message="tns:EchoItResponse" />
37.         </wsdl:operation>
38.     </wsdl:portType>
39.     <wsdl:binding name="EchoItBinding" type="tns:EchoItPortType">
40.         <soap:binding style="document"
41.          transport="http://schemas.xmlsoap.org/soap/http" />
42.         <wsdl:operation name="EchoIt">
43.             <soap:operation soapAction=""/>
44.             <wsdl:input>
45.                 <soap:body use="literal"/>
46.             </wsdl:input>
47.             <wsdl:output>
48.                 <soap:body use="literal"/>
49.             </wsdl:output>
50.         </wsdl:operation>
51.     </wsdl:binding>
52.     <wsdl:service name="EchoItService">
53.         <wsdl:port name="EchoItPort" binding="tns:EchoItBinding">
54.             <soap:address
55.             location="http://localhost:8080/echoit/echoit"/>
56.         </wsdl:port>
57.     </wsdl:service>
58. </wsdl:definitions>
4. Generate the code

When all this is in place we can generate the Java code by simply issue the command:
mvn clean install
In Netbeans we can see the generated code in our project browser:


5. Create Web Service implementation

Next step is to create the implementation class for the web service. Please note that I will create a EJB Web Service endpoint. This way I don't need a web container nor any web deployment descriptor.
Here is the web service implementation:

PLAIN TEXT
JAVA:
1. package net.pascalalma.ws;
2.  
3. import javax.ejb.Stateless;
4. import javax.jws.WebService;
5.  
6. /**
7. * Hello world!
8. *
9. */
10. @WebService(targetNamespace = "http://www.pascalalma.net/EchoIt",
11.             portName="EchoItPort",
12.             serviceName="EchoItService",
13.             endpointInterface="net.pascalalma.echoit.EchoItPortType")
14. @Stateless
15. public class EchoServiceImpl
16. {
17.     public String echoIt(String it)
18.     {
19.         return "Echo " + it +"!";
20.     }
21. }
6. Deploy it to Glassfish

With the implementation in place rebuild the project so a ejb-jar is created. Again issue the command:
mvn clean install
The created jar file in the 'target' directory can then be deployed to Glassfish. This can be done by using a Maven plugin as described here or by using the Glassfish Admin Console. I used the last one in this case. It should look similar to this after successful deployment:


7. Test the service

The easiest way to test it is, if you already have the Glassfish Admin Console open, to click the 'test' button and fill in a text as input parameter. As result you should get something like:

Well, if you did the things as I described you have a big chance it will work in one time, but in my case there were some problems when trying to get this to work. Some of the Issues I ran into while building the projects:

1. Missing dependencies

Missing:
----------
1) com.sun.xml.ws:jaxws-tools:jar:2.1.5

I had to use another plugin version then the one that is recommended at the plugin homepage:

PLAIN TEXT
XML:
1. <plugin>
2.                 <groupId>org.codehaus.mojo</groupId>
3.                 <artifactId>jaxws-maven-plugin</artifactId>
4.                 <version>1.10</version>
5.      ...
6.    </plugin>
2. More missing libraries

I then ran into this one:

org.apache.maven.lifecycle.LifecycleExecutionException: Error executing: wsimport [-s, /Users/pascal/projects/metro-service/echo-service/target/generated, -d, /Users/pascal/projects/metro-service/echo-service/target/classes, /Users/pascal/projects/metro-service/echo-service/src/main/webapp/WEB-INF/wsdl/echo-it.wsdl]
...

See also this thread.

It appears it has something to do with JDK1.5 instead of JDK1.6. I solved it by adding the dependencies for the JSR181.

I hope that this posts avoids the exceptions which I encountered and make the use of JAXWS with Maven more smoothly because in the end it is a very nice solution!

java.lang.IllegalArgumentException
at
com.sun.xml.registry.uddi.bindings_v2.impl.runtime.UnmarshallerImpl.unmarshal(Unknown
Source)
at com.sun.xml.registry.common.util.MarshallerUtil.jaxbUnmarshalObject(Unknown
Source)
at com.sun.xml.registry.uddi.Processor.processResponseJAXB (Unknown Source)
at com.sun.xml.registry.uddi.Processor.processRequestJAXB(Unknown Source)
at com.sun.xml.registry.uddi.UDDIMapper.findOrganizations(Unknown Source)
at com.sun.xml.registry.uddi.BusinessQueryManagerImpl.findOrganizations(Unknown
Source)

And although the error is found a lot on the internet I haven't been able to found a solution for it, other then just try the newer version of jUDDI.

When you have installed all components (Tomcat, jUDDI and MySQL, for example) you can run the jUDDI validation page to see if everything is configured well and working.

Here are some sample classes I used when playing around with JAXR. I have inserted one record in the UDDI database by hand:

This way I can identify myself with JAXR as an existing publisher so I am allowed to register stuff in the UDDI. To create an organization in the UDDI registry:

To search for registered organizations:

The result of the last program is (after successful registration of the organization:

run:
Requesting data...
Successfully queried the registry for organization matching the name pattern: "PALMA IT"
Results found: 1

Organization Name: PALMA IT
Organization Key: 298B4970-FC6A-11DD-8970-BE836B4D6233
Organization Description: My Company
Service Name: PALMA's JAXR Service
Service Key: 29A05810-FC6A-11DD-9810-848A3849CC94
Service Description: Services of XML Registry
BUILD SUCCESSFUL (total time: 1 second)

Now I can play around and hoping I remember enough of this stuff when taking the exam :-)

Lateron we'll see that Maven uses the Glassfish 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:

and its implementation:

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

As you can see I am referring to the libraries of Glassfish of my local installation. It appears that the libraries you get from the global Maven repositories only contain the interfaces and no implementation so these can not be used when you want (unit) test your beans outside the container.

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):

With all this in place we are able to build the EJB3 project with the command:
mvn clean install
and to package and deploy the EAR project with:
mvn clean package glassfish:deploy
In the Admin Console of Glasfish you will see the deployed project if everything went well:

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:

and the implementation class:

That's it! Now rebuild and redeploy the packages and it is done!
To test the webservice I 'll use the Admin Console of Glassfish again. You will see under the heading 'Web Services' that there is added a web service:

Now select that web service and you will get a screen where you can enter the Test page for this service:

After clicking the button we can enter a value as input parameter for our service:

And the Admin Console will show the result of our call by showing the soap messages (request+ response):

Of course, this test functionality is much more limited then we have in SoapUI but to quickly check if the service is running it will do just fine.

• In chapter 4 you will start with using Oracle WSM by registering your first service in it. But you can only do that after you have registered the gateway first (I would suggest to start with the Oracle WSM Starters guide of Oracle first).
• The description of testing the setup in chapter 6 is not correct. The test as described sends an unsigned request and checks if the response is signed. But in the configuration of the web service in this chapter the incoming request must be signed, so the test will always fail. The quick workaround is of course to disable the checking of incoming request. But a nicer solution would be to send in a signed request. To do this I used SoapUI as described here.

One thing I miss in the book is (high level) information about keystores and how to create these, but this might be caused by the fact that I am not using .Net so I don't have the default keystore they use in the book. But with this addition you make the examples better accessible for others like me who don't have .Net available.
Overall it is a nice books with lots of screenshots showing you how to deal with Oracle WSM and it gives you a good insight in how you can secure your web services.

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:

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:

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:

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):

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

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):

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

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.