Bob Nedwor

Ranch Hand
+ Follow
since Aug 17, 2005
Bob likes ...
Eclipse IDE Oracle Ubuntu
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Bob Nedwor

I agree with Deriko. Ejb certification is easier. Of course it depends on your geographic area, but I think the Web Services certification is more marketable, not just because is it more difficult, but also because more people are starting to use Web Services and Web Services-related skills are appearing as required and preferred in an increasing number of job postings. I am going for the Web Services cert, then maybe the EJB cert later.
Thanks to Milan Kuchtiak for the example previously referenced. I also changed my package from the default (none) to "name" like he did and I also added the ApplicationConfig class like he did (to demonstrate that not even a web.xml is necessary here). I rejarred and re-deployed.

What Milan does not show you is how to call these using curl (in case you do not want to go to the trouble of setting up NetBeans 6.8, etc). Here they are:

curl http://localhost:8081/restejb/resources/application.wadl
curl http://localhost:8081/restejb/resources/name
echo "New Name" > data
curl -T data http://localhost:8081/restejb/resources/name
curl http://localhost:8081/restejb/resources/name

There are quite a few different ways to do this. Please check out the "wsimport" options. As long as you have your Java 1.6 $JAVA_HOME/bin in your $PATH environment variable, just type
"wsimport" from your command prompt (I think it is %JAVA_HOME%\bin in your %PATH% in Windows). If you do not have JDK 1.6, then wsimport should be in the bin directory in your jaxws-ri or glassfish3/glassfish directory, depending on how you are learning java web services.

If the cold fusion service that you are talking about is up and running and working as a real SOAP Web Service, then there should be a navigable WSDL you can see in your browser somehow ( http://localhost:8080/mycoldfusionservice?wsdl or something like that) that describes the operations, ports, messages, etc., of your service.

Once you know what it is, just create two folders, "src" and "bin", then say:
wsimport -keep -s src -d bin http://localhost:8080/mycoldfusionservice?wsdl (you might need to try this a few times using the -p option with the right package name before you actually get what you need).

Once this works, you have nearly everything you need for your client, but your class with the main method. You have to build that yourself, using a few lines of code that create an instance of the generated ?* class that wsimport gave you, then call its "get?Port()" method. See for an example of how to do this.

I hope this helps.

It seems that at least part of the answer is here .

My NameBean needs @Singleton and some other things.

More on this later.

Thanks if anyone has any other answers.
I would stay away from "J2EE Web Services: XML SOAP WSDL UDDI WS-I JAX-RPC JAXR SAAJ JAXP" because it sounds like it is based on the old jax-rpc standard.

Starting with JEE 5, jax-rpc was replaced witth jax-ws and jaxb.

Java Web Services: Up and Running by By Martin Kalin is much more useful for OCPJWSD 6 certification. I have that book and I really like it.
Also, please get "SOA Using Java Web Services" by Mark Hansen, which I also have and like that one even better.

I think I might be doing something wrong.
I am trying to get the NameService example from to work on Glassfishv3 and I am not sure I am deploying correctly.
I cannot seem to find the code for the NameBean class, so I made up my own.
When I deploy, the server log seems to indicate that everything is going OK, but I am not sure what URLs to try with my curl command.
(I run Glassfish on 8081).

curl http://localhost:8081/restejb
just gives me my prompt back.
Pretty much everything else gives me: HTTP Status 404 The requested resource () is not available.

Thanks to anyone who can help me with this. Here is what I am doing:

$ cat src/

$ cat src/

$ mkdir WEB-INF
$ mkdir WEB-INF/classes
$ export GL4=/bapps/glassfish3/glassfish/modules
$ javac -cp WEB-INF/classes:$GL4/javax.ejb.jar:$GL4/jersey-core.jar -d WEB-INF/classes src/*.java
$ jar cvf restejb.war WEB-INF
added manifest
adding: WEB-INF/(in = 0) (out= 0)(stored 0%)
adding: WEB-INF/classes/(in = 0) (out= 0)(stored 0%)
adding: WEB-INF/classes/NameBean.class(in = 394) (out= 249)(deflated 36%)
adding: WEB-INF/classes/NameService.class(in = 894) (out= 527)(deflated 41%)
$ cp restejb.war /bapps/glassfish3/glassfish/domains/domain1/autodeploy/restejb.war

Server log then says:

[#|2011-04-18T09:50:27.606-0700|INFO|glassfish3.1||_ThreadID=63;_ThreadName=Thread-1;|[AutoDeploy] Selecting file /bapps/glassfish3/glassfish/domains/domain1/autodeploy/restejb.war for autodeployment.|#]

[#|2011-04-18T09:50:27.937-0700|INFO|glassfish3.1||_ThreadID=63;_ThreadName=Thread-1;|Portable JNDI names for EJB NameService : [java:global/restejb/NameService, java:global/restejb/NameService!NameService]|#]

[#|2011-04-18T09:50:28.048-0700|INFO|glassfish3.1||_ThreadID=63;_ThreadName=Thread-1;|WEB0671: Loading application [restejb] at [/restejb]|#]

[#|2011-04-18T09:50:28.090-0700|INFO|glassfish3.1||_ThreadID=63;_ThreadName=Thread-1;|restejb was successfully deployed in 434 milliseconds.|#]

[#|2011-04-18T09:50:28.097-0700|INFO|glassfish3.1||_ThreadID=63;_ThreadName=Thread-1;|[AutoDeploy] Successfully autodeployed : /bapps/glassfish3/glassfish/domains/domain1/autodeploy/restejb.war.|#]

After looking at this more closely, it seems that there are two ways to do this without having to create a BindingProvider, manually messing with SOAP elements, etc, like I mentioned in my previous post. But neither one results the namespace being defined in the header of the Envelope like in Dan's 03/29/2011 11:02:32 AM example above. Instead the namespace is defined within the individual elements. Also, neither one results in a MessageID element being created - just "To" and "Action."

a) On your server-side implementation class, use this annotation:, required=true)
and in your client code, pass an instance of, true)
into your getXXXXXport() method.

b) On your server-side implementation class, use this annotation:, required=true)
and in your client code, pass an instance of, true)
into your getXXXXXport() method.

One difference between a) and b) is that in order to compile the classes in option a) you need to add to your classpath a jar from either your jaxws-ri or glassfish apps whereas in option b) you do not (if you are on JDK 6).

The other big difference is that in option a), your "To" and "Action" elements in your SOAP header are using the namespace where as in
option b), they are using the namespace which seems to be more recent.

I am not sure which option a) or b) above is considered more "WS-Addressing Compliant," but I suspect that I am still missing something and I would appreciate advice as to how to get the MessageId element in along with the other two, and get my namespace defined once up in the header of the Envelope and still not have to create a BindingProvider, etc, like I mentioned in my previous post. One further note is that I did not tweak my WSDL, in either option, and it has no WS-Addressing-related items in it.

I was able to get it to work, but it was more than a couple tweaks to the WSDL. To get my request side SOAP message (inbound to the service) to look like this, I needed to hack up my client quite a bit, including casting my service to a BindingProvider, create a SOAPHandler and mess around with the SOAPHeader, SOAPEnvelope, etc. Is there a faster way to build WS-Addressing into your client side that you know of off hand? Thanks for your advice.

Thanks, that is great, Dan!

Can you show us the related WSDL? Or at least the portType and binding sections of it?

1. Is it a valid include since in first include has targetNamespace="" and the WSDL's targetNamespace="". Same is the case with second include as well.

This is valid. You are using xs:include and xs:import (as they are defined in
The example is NOT using the WSDL version of import. So I do not understand the nature of the first response.
The example comes from Mark Hansen's Great book,, so as long as you did not alter it, you can bet it is valid.

2. I checked this WSDL is working fine with wsimport tool so wondering, how is the targetNamespace="" being referenced here. Is it because of the enclose <xs:schema> element which defined targetNamespace is also importing it?

This is a good question. I am not certain, but it looks like you are right. It appears that a new <schema> enclosure requires us to
import the namespace, even though xmlnsms="" is already defined up in the header of the main WSDL.

Part of the problem could very well be that when running your client program, your current JAVA_HOME is pointing to Java 6 SE, which now has a version of WebFault WITHOUT the messageName element ( see the SE version of the API here .

But the program needs the EE version of WebFault that DOES have the messageName element (see the EE version of the API here ) .

Consider trying to change your client JAVA_HOME to a 1.5 version of SE and see if it works.
As far as material about REST, I enjoyed Chapter 3 of Mark Hansen's "SOA Using Java Web Services." The chapter was called "Basic SOA Using REST." Furthermore, Martin Kalin's "Java Web Services Up and Running" has a 70 page long chapter on REST I found interesting.

But I did not take the Beta exam, so I am not sure how much these would help us or if we need to go out and buy another book like ReSTful Web Services or something else. Can anyone else tell us?
Thank you.
Yes. Sorry. I should have asked if anyone agrees. Or is it simply my lack of experience with Java Web Services?
I have both books! They are both very helpful. I think SOA Using Java Web Services is better overall, but Java Web Services Up and Running provides more on security. I think they are both enjoyable to read if you like learning Java Web Services. Although neither are close to a real study guide for this exam, they sure give you a good head start.
I certainly hope that not too many (preferably none) of the questions on the SCDJWS 6 exam pertain to ReST services that use the HTTP POST method. In fact, even as more of a SOAP fan, I can understand why some services are better off as ReST, when using the HTTP GET method.

But trying to code a decent client that sends and receives an HTTP POST to a ReST Service, using Dispatch<source>.invoke() seems overly complex, error prone, not to mention the handling of the request on the server side.