The idea behind the web service was to create an RPC that would be stuffed into HTTP packets. That’s how the development of the standard started. What are the basic concepts of this standard:

• SOAP. Before you can call a remote procedure, you need to describe that call in a SOAP XML file. SOAP is just one of the many XML markups that are used in web services. Anything we want to send somewhere via HTTP is first turned into an XML description of SOAP, then stuffed into an HTTP packet and sent to another computer on the network over TCP/IP;
• WSDL. There is a web service, i.e., a program whose methods can be remotely invoked. But the standard requires that this program be accompanied by a description that says “yes, you are not mistaken – this is indeed a web service and you can call such and such methods from it”. Such a description is represented by another XML file that has a different format, namely WSDL. That is, WSDL is just an XML file describing a web service and nothing else.

So, in Java, there is such an API as JAX-RPC. In case you don’t know, when people say that Java has such and such an API, it means that there is a package with a set of classes that encapsulate the technology in question. JAX-RPC took a long time to evolve from version to version and eventually evolved into JAX-WS. WS obviously stands for WebService and one might think that this is a simple renaming of RPC into the now popular buzzword. This is not the case, as Web Services have now moved away from the original idea and allow not just calling remote methods, but simply sending SOAP-formatted messages-documents. Why this is needed I don’t know yet, the answer here is unlikely to be “just in case you need it”. I myself would like to know from more experienced comrades. And lastly, then there is also JAX-RS for so-called RESTful web services, but this is the topic of a separate article.

General approach

In web services there is always a client and a server. The server is our web service and is sometimes called the endpoint (like, the endpoint where SOAP messages from the client go). What we need to do is the following:

• Describe the interface of our web service;
• Implement this interface;
• Run our web service;
• Write a client and remotely call the required method of the web service.

You can run a web service in different ways: either describe a class with the main method and run the web service directly as a server, or you can depopulate it on a server like Tomcat or any other server. In the second case, we don’t start a new server ourselves and don’t open another port on the computer, we just tell the Tomcat servlet container that “we’ve written the web service classes here, please publish them so that everyone who comes to you can use our web service”.

The post What is a web service and how to work with it? appeared first on Asjava.

The REST paradigm has been around for a few years now and still attracts a lot of attention.

The RESTful API can be implemented in Java in a number of ways: you can use Spring, JAX-RS, or just write your own servlets if you’re good and brave enough. All you need is the ability to expose HTTP methods – the rest depends on how you organize them and how you direct the client when calling your API.

As you may realize from the title, this article will focus on JAX-RS. But what does “just an API” mean? It means that the focus here is on clearing up the confusion between JAX-RS and its implementations and offering an example of what a proper JAX-RS web application looks like.

Incorporating it into Java EE

JAX-RS is nothing more than a specification, a set of interfaces and annotations offered by Java EE. And then, of course, we have implementations; some of the best known are RESTEasy and Jersey .

Also, if you ever decide to build a JEE-compatible application server, the folks at Oracle will tell you that, among other things, your server must provide a JAX-RS implementation for use by deployed applications. That’s why it’s called the Java Enterprise Edition Platform .

Another good example of specification and implementation is JPA and Hibernate.

Lightweight wars

So how does all this help us developers? The help is that our deployable components can and should be very thin, allowing the application server to provide the necessary libraries. This applies to RESTful API development as well: the final artifact should not contain any information about the JAX-RS implementation being used.

Of course, we can provide the implementation ( here’s a tutorial on RESTeasy). But then we can no longer call our application a “Java EE app”. If someone comes tomorrow and says ” Ok, it’s time to move to Glassfish or Payara, JBoss has gotten too expensive! ” We might be able to do that, but it will be hard work.

If we provide our own implementation, we have to make sure that the server knows to exclude its own – this usually happens by having a proprietary XML file inside the deployment. Of course, such a file should contain all sorts of tags and instructions that nobody knows anything about except the developers who left the company three years ago.

Always know your server

So far we have said that we should take advantage of the platform we are offered.

Before deciding which server to use, we should look at what JAX-RS implementation (name, vendor, version and known bugs) it provides, at least for production environments. For example, Glassfish comes with Jersey and Wildfly or Jboss comes with RESTEasy.

This of course means a small amount of research time, but this is only supposed to be done once, at the beginning of a project or when migrating it to another server.

Just keep in mind that JAX-RS is a powerful API, and most (if not all) of what you need is already implemented on your web server. You don’t need to turn a deployable module into an unmanageable pile of libraries.

The post JAX-RS is just an API appeared first on Asjava.

Start developing a simple web service

Software requirements:

• Java SE 1.6 or higher;
• JAX-WS Reference 2.2.5 implementation (available here);
• Apache Tomcat version 6 or higher.

The web service can be developed in two ways

Top-down approach

In this approach, the service interface is created first, and the implementation is provided later.

Bottom-up approach

In this approach, the service implementation is created first and the interface is defined on that basis. This approach is easy for beginners unfamiliar with web services.

We follow the second, bottom-up approach, for reasons of simplicity and to have a faster, ready-to-use working example.

What you need to do.

Create a POJO class (an old Java object) and annotate it with WebService as follows

package com.accrd.blog.blog.ws.jaxws.sample;
import javax.jws.WebService;
@WebService(name="SimpleWebService")
public class SimpleWebService {
public String sayHello (String name){
return "Hello, "+ name + "!" ;
}

Now the web service has a task, and the available operation does this: you pass a name (“web service”), and it returns a hello message with the specified name (“Hello, web service!”).

That’s it. The web service is ready to be deployed.

You can deploy it in two ways,

1. standalone deployment. In this approach, you just need to have a main method and call Endpoint.publish (url, provider) . This is mentioned below. This creates the web service runtime environment that comes with Java SE 6 and deploys it to a lightweight http server. The service is accessible from the URL specified as input to the publish method.
2. Deployment in a servlet container. In this approach, we can deploy a web service by creating a standard .war file of a java web application and deploy it to a web server that has servlet container support, such as Tomcat or Jetty.

The post Working with JAX-WS Web Services appeared first on Asjava.