We Keep Coding

Web service from WSDL

I want to generate service implementation from WSDL (Top down approach) in Java but I dont want to use any tool. For example If we want to create stubs we can use wsimport.
Please let me know if this is a duplicate question.
Thanks

If you don't want to use any tool to generate code or stubs, maybe you would like to use Spring WebServices. This way you only create an EndPoint able to process WS messages, that is, you only worry about implementing server logic.
With this approach you can define beans to marshalling, using jaxb2 (or another), and the EndPoint brings you functionality to receive not XML payload, but Java Objects instead.
If you don't want to genereta code or stubs, I think Spring WS is nice for you.
If you don't want to use any tool at all, then sorry for my answer, but I believed what you didn't want is to generate code.

Below is the Maven plugins which create Java from WSDL:
Axis :
Axis plugin
CXF
CXF plugin

Which feature make one to use Spring WS over JAX-WS

For SOAP Based Web Services, why one should choose Spring WS over JAX-WS.
I had gone through some article even Spring WS doc feature but still I am not clear.
If I need to convince someone to use Spring WS I can't.
So I want the difference in simple terms that any Web Service Developer can understand.
Thanks in advance.

I am not going into the details of JAX-WS versus Spring-WS.
You might want to refer to the link here for details on that and google it.
From my personal experience :
Spring-WS Advantages over JaxWS
You want to use a databinding other than JAXB (JibX, Castor or
others)
You want extreme fine grained control on the endpoint mapping strategy
You are choosing a WSDL first approach (though many argue that JAXWS also supports a WSDL first approach, it is generally accepted to be more flexible in spring-ws)
JaxWS over SpringWS
You want to go for a java first approach
You want to make your code flexible (since JAXWS is a specification you can have multiple implementations)
You want to use other annotation driven development of JAX-WS

Servlet vs REST

I need to create 5 methods on the server side, which will work with binary data. The remote clients are applet and JavaScript. The Client will send files to the server, and the server must parse these files and then return the response as XML/JSON.
So I am confused - is it good practice to use REST-service in this case? Or should I use a servlet?
My colleague told me:
"Creating REST-service that will be used only by one Application isn't
good. REST must be created only when it will be used by many apps. And
REST has some disadvantages over servlet: REST is slower than servlet;
it more difficult to write thread-safe REST than servlet"
However, I see some disadvantages with using Servlet: I need to send a function name that I want to call (i.e. as extra HTTP parameter send function name)
and then inside the doPost method perform the following switch:
switch(functionName) {
case "function1":
function1();
break;
case "function2"
function2();
break;
//.... more `case` statements....
}
In case of REST I can simple use different URLs for different functions.
Also, in the case of REST, it more convenient to return JSON/XML from server.

You are confusing two paradigms here:
REST is a software architecture “style”;
Servlet is a server-side technology.
You can, for example, implement REST-like services using Servlets.

Well,
I wouldn't agree with your colleagues' opinion that isn't good to have rest used by only one application, since you may decide in the future to have different applications using the same rest api. If I were you I would choose the pure REST. Why?
If you're using some framework for rest implementation (let's say apache cxf or jersey) you get lots of stuff out of the box - you write POJO you get a rest, you get serialization and deserialization, to and from let's say, JSON object out of the box (eventually you will need to implement some JsonProviders but this is not a big deal).
It is intuitive to work (if you design your rest APIs well).
Very easily consumable by JavaScript clients (especially if you're using JQuery or something like that)
However, it strongly depends of what exactly do you want to do, if you have some strong transactional logic, the rest could be quite tricky. If you're only going to do POST requests (without using the other HTTP methods) you might want to use the Servlet since you won't have to work with additional frameworks and making more dependencies. Note that the REST is more or less an architectural concept and it does not contradict with the Servlet technology, if you're stubborn enough you can make a rest api only with servlets :-).
Hope I've helped.

First, you're speaking in terms of two different paradigms. It's kinda apples-and-oranges.
REST is a style of service that uses HTTP operations (GET, PUT, etc.) to read and write the state of resources. Think of resources as "nouns" and "things".
Servlet, on the other hand, is a software specification originally provided by Sun Microsystems for connecting HTTP requests to custom Java code. Servlets often speak in terms of method calls: "verbs" and "actions".
Since your question implies that you are looking to deal with input->output methods, just a plain servlet should do the job.

I cannot see any problems on using Jersey and create a REST service. I know that I'm a REST-taliban but it's really simple to implement this kind of architecture using JAX-RS, so... why not?
Your colleagues say: "REST must be created only when it will be used by many apps" but I cannot see how this can be true.Why I cannot create a REST service for a single app?

Sounds like your collegue is applying premature optimisation. If you can write it with a JAX-RS library quickly, do so... If it then proves to be the bottleneck only then do you take the time to rewrite as servlet.
In my experience the performance overhead of JAX-RS is not sufficiently big to justify the development and maintenance overhead of writing the equivalent in servlets directly where the problem maps well to JAX-RS

Depending on your container version, Jersey (or any other JAX-RS implementation) will still use a Servlet for dispatching requests to the appropriate handler.
If your application is truly RESTful, then JAX-RS will do what you want. Otherwise, consider using a FrontController to interpret the Request and forward it to the appropriate handler.
Also, don't confuse XML or JSON with REST. You will get these for free in most (if not all) JAX-RS implementations, but these implementations still delegate content marshalling to other libraries (e.g. JAXB).

Here is the similiar link. he has done it with simple servlet
http://software.danielwatrous.com/restful-java-servlet/

Java code to webservice

I have written a piece of Java code which I am suppose to expose as a webservice and then later it will be consumed by Coldfusion 9.
Could anyone please give me some pointer for how to convert my Java code as a webservice?

You have many options, among them are Axis2 with its java2wsdl. There is also springWS.
Personally I prefer axis2 for writing clients and SpringWS for writing the actual web service.

Please take a look here, it is pretty easy to annotate a façade to your service and expose it as a webservice:
http://cxf.apache.org/

Java Framework for integrating WSDL, REST, etc

At work, we currently have a WSDL interface as well as a semi-RESTful interface that we're looking to expand upon and take it to the next level.
The main application runs using Servlets + JSPs as well as Spring.
The idea is that the REST and WSDL are interfaces for an API that will be designed. These (and potentially other things in future) are simply a method through which clients will be able to integrate with the interface.
I'm wondering if there are any suggestions or recommendations on frameworks / methodologies, etc for implementing that under-lying API or does it make sense simply to create some Spring beans which is called either by WSDL or REST?
Hope that makes sense.

Have a look at Eunicate it is great . You are using spring , Spring has had support of SOAP for a while and Spring 3 has support of REST (Creating and Consuming).

Your approach makes sense. Probably the most important advice is to make the external API layer as thin as possible. You can use Axis, Apache CXF, Jersey, etc. to handle the implementation of the REST or SOAP protocols, but the implementation of those services should just load the passed in data into a common request object, and pass that into a separate service that handles the request and returns a response object which the external API layer will marshall into the correct format for you.
This approach works especially well when you have a competitor providing similar services and you want to make it easy for their customers to switch. You just build a new external API that mirrors the competitors, and simply translates their format to your internal api model and provided your services are functionally equivalent, you're done.

This is a really late response, but I have a different view on this topic. The traditional way as we know it is to unmarshall xml to java and marshall java to xml. However if the wsdl changes then it would effectively be a structural change in the code which would again require a deployment.
Instead of the above approach if we list the fields mentioned in the wsdl in a presistent store, load the mappings in memory and prepare our structures based on these mappings we would have to have many less changes for this..Thus IMO instead of using existing libraries a configurable approach to unmarshalling and marshalling should be taken.