In last article we learned about what web services is. In this tutorial we will try to understand some of the concepts associated with web services technology.
Let stat with the scenario, let us say I’m writing a java implementation class, if I want to share this implementation with other consumer class, then the best way to share the implementation class is through the interface
So Interface is a standard way in which you can share any contract (implementation class) to a consumer.
so now think about how this could work in case of web service
Now let’s say I have a web service implementation, I want to share the details of web service to the consumer through an interface,
In this case the consumer can be in any language and so the web service, So the interface that we are going to share with the web service consumer must be technology independent, it should be something that any technology can understand, so the concept of interface will not work here.
In order to cater to the need for a platform independent format for interaction, XML format was adopted for this purpose. Now when we create a web service, we will share its contract(implementation) as XML document.
This XML is called WSDL
WSDL stands for Web Service Definition Language or Web Service Description Language.
WSDL document will contain the contract of the web service. So when we create a web service we will share the WSDL to the consumer class.
WSDL for an existing web service can be generated either manually or automatically (through available tools)
Contents of WSDL:
3. Return type.
This is a high level representation of WSDL.
Therefore through WSDL we will get to know what information needs to be sent and its return type.
Now let us say that you are going to create your own application and you are about to call a web service
Now there occurs a question, how consumer is able to locate WSDL for a particular Web Services?
As we know that the one way to get web service information is through the WSDL, but now how do we get hold of the WSDL?
Solution : Here there are 2 solutions for this,
If Web Services knows the consumer, then it can directly give the WSDL to the consumer establish web services connection.
There is an registry called UDDI on internet. It is a directory, where all service providers who want to issue their web services would 1st need to register the web services with UDDI using WSDL and make themselves available through it for discovery.
Now consumer who is looking for a particular service would go and hit UDDI, and will search for a particular service that it is looking for. Now UDDI will return all service providers who offer that service. And then Consumer will choose one service provider from it, and get its WSDL, now with the help of WSDL, consumer will able to access web services.
UDDI stands for Universal Description Discovery and Integration.
Now we got the WSDL, so we know what information needs to be sent and its return type.
Now let us assume that you are writing a client application (in java) to call a web service (in C++), so now we can get the WSDL by querying the UDDI.
But now the question is how do we actually send the information and how the exchange happens?
The parameter sent from our consumer class (say, some complicated object) might not be recognized by the other language in the web service which we are about to call. Thus, the object passed will make no sense to the web services and hence the web services will not be able to process the input parameter.
For example I have a java String as input parameter which is needed to be sent to web service which is written in C++.
As we know a string in java is different from string in c++. So how do we exchange the data between client application and web server?
So the information passed (input arguments) and the information received (return types) should be in a common format. Again XML format comes to the rescue.
There is a protocol by which both sender and receiver understands this format (XML).
This protocol is known as SOAP.
SOAP stands for Simple Object Access Protocol.
SOAP is a way by which different technology can access objects.
Now you know what a web services is and you know what needs to be sent (WSDL) and how to send it (SOAP).
But now who does the conversion?
Referring to the above assumption, how to do the conversion from java objects to SOAP message takes place?
Well this conversion is done by an intermediate class in the client application which is SEI.
SEI stands for Service Endpoint Interface.
SEI acts as an interface to your web service endpoint. SEI takes care of converting client object to a SOAP message. And we don’t need to write this class ourselves, we can generate it automatically.
Note:When you are about to make a web service call, you don’t need to worry about where the web service is and where you need to call. All you have to do is to have this SEI generated/Created and you can call the method of SEI.
One good thing about SEI is that, you can actually have interface specific to what you are developing.
For example, if my client is in java application, then I can have a SEI specific to java application, which knows to convert java objects to soap objects. Similarly for dot net, SEI will be in dot net, which converts dot net code to SOAP messages.
I.e. SEI takes care of all web service call.
Web Service Design
There are two approaches in implementing a web service and they are bottom-up and top-down.
Top down is the reverse of bottom up approach. First the business logic is written up and then we create the WSDL. The complete business definition, message format, transport protocol, security and everything will be described in WSDL. Using that wsdl the skeleton code is generated automatically.
In this tutorial we have learnt 4 terminologies so far.
1. WSDL – describes what a web service is in an XML format.
2. UDDI – it is a directory where any publisher can publish their web services and a consumer can query and get access to all different web services.
3. SOAP – it’s basically a protocol that is used to encode and decode messages. When you make a call to web service, it ends up as SOAP message that gets transferred over the network.
4. SEI – it’s an interface to the service endpoint (web service), that provides a way for client application irrespective of the technology to call the web service. Depending on the technology you get a SEI for that technology. This can be generated out of the WSDL itself.
These are some of the important concepts about web service. We will see some more detail in the next tutorial.
In this article we will get an introduction about what an web services is. In case of web service there are primarily two different types
SOAP Web Service
RESTful Web Service
The java specification for SOAP IS JAX-WS and for REST is JAX-RS
In this tutorial we will concentrate about learning SOAP Web Service.
Now what is a web service?
Basically, we can say that everything available online are services. Difference between a standard website and a Web Services is, a website stands for human consumption but a Web Services stands for code consumption.
Let us try to understand that better..
Imagine your friend has an existing application which takes a particular day as input and returns the events that take place on that specific day. Lets say it has a method getEvents() which takes the input date and returns a List of Strings containing the events. For a general website, this application is present in MVC form and is deployed in an application server. This way, the functionality is available to the end users who can send their input to the application and get their desired result.
Suppose I have a completely different App server, and I wants to use the getEvents() functionality of my friend’s application into mine.
Then one way I can do it by Getting jar of original server.
The disadvantage of this method is,
1. My friend’s application may have different application server, database and have other business which I’m not interested in.
2. If my friend changes the jar, then I need to get it and build it again.
Then Solution of the above problem is to use Web Services
Web Services allows two different applications running on different machine to communicate with each other. But there should be a network connecting these two applications.
The best part of Web Services is inter operability, i.e. java can call .net and vice versa
In the above diagram, application (A1) calls a function in application (A2).
The application (A1) which gives a call to the function is called web service client; the application (A2) which gives services to the request is called the web service endpoint.
Note: In general words, “web service endpoint” is a service which published outside for user to access; where “web service client” is the party who access the published service.
Running functional tests from the command-line is straightforward and simple using the included testrunner.bat/.sh script, which takes a number of arguments to control which tests to run, output, etc:
e : The endpoint to use when invoking test-requests, overrides the endpoint set in the project file
h : The host:port to use when invoking test-requests, overrides only the host part of the endpoint set in the project file
s : The TestSuite to run, used to narrow down the tests to run
c : The TestCase to run, used to narrow down the tests to run
u : The username to use in any authentications, overrides any username set for any TestRequests
p : The password to use in any authentications, overrides any password set for any TestRequests
w : Sets the WSS password type, either ‘Text’ or ‘Digest’
d : The domain to use in any authentications, overrides any domain set for any TestRequests
r : Turns on printing of a small summary report (see below)
f : Specifies the root folder to which test results should be exported (see below)
j : Turns on exporting of JUnit-compatible reports, see below
a : Turns on exporting of all test results, not only errors
: Opens the generated report in a browser (SoapUI Pro only)
i : Enables SoapUI UI-related components, required if you use the UISupport class for prompting or displaying information
t : Sets the soapui-settings.xml file to use, required if you have custom proxy, ssl, http, etc setting
x : Sets project password for decryption if project is encrypted
v : Sets password for soapui-settings.xml file
D : Sets system property with name=value
G : Sets global property with name=value
P : Sets project property with name=value, e.g. -Pendpoint=Value1 -PsomeOtherProperty=value2
S : Sets to save the project file after tests have been run
I : Do not stop if error occurs, ignore them
R : Selects which report to generate for the test objects executed, for example if running the entire project, this could specify the name of a test-suite-level report that would be generated for each TestSuite. The report is saved as specified with the -F option to the folder specified with the -f option. (SoapUI Pro only)
F : Sets the format of the report specified with the -R option, for Printable reports this is one of PDF, XLS, HTML, RTF, CSV, TXT, and XML. For Data Export this is either XML or CSV (SoapUI Pro only)
g : Sets the output to include Coverage HTML reports ( SoapUI Pro only )
E : Sets which environment to use (SoapUI Pro only)
Launching the TestRunner from within SoapUI
Before getting started, with the command line testrunner, SoapUI includes a “Launch TestRunner” action available from Project, TestSuite or TestCase popup menus, which launches the bundled command-line tools from inside SoapUI.
The IDE plugins do not include these runners, you will need to download/install SoapUI seperately and point the “TestRunner Path” option in this dialog to the install directory).
The dialog looks as follows:
Here we’ve specified some initial settings to run the current TestCase, in the Report tab we can specify which reports to generate:
Now if we run the testrunner we get:
Scrolling back up in the opened window we can see the actual command issued at the command-line:
Copy and paste the below highlighted into your favorite automation tool for rerun these tests as configured.
SOAP uses WSDL for communication between consumer and provider, whereas REST just uses XML or JSON to send and receive data
WSDL Defines contract between client and service and is static by its nature. In case of REST contract is somewhat complicated and is defined by HTTP, URI, Media Formats and Application Specific Coordination Protocol. It’s highly dynamic unlike WSDL.
SOAP doesn’t return human readable result, while REST result is readable with is just plain XML or JSON
This is not true. Plain XML or JSON are not RESTful at all. None of them define any controls(i.e. links and link relations, method information, encoding information etc…) which is against REST as far as messages must be self contained and coordinate interaction between agent/client and service.
With links + semantic link relations clients should be able to determine what is next interaction step and follow these links and continue communication with service.
It is not necessary that messages be human readable, it’s possible to use cryptic format and build perfectly valid REST applications. It doesn’t matter whether message is human readable or not.
Thus, plain XML(application/xml) or JSON(application/json) are not sufficient formats for building REST applications. It’s always reasonable to use subset of these generic media types which have strong semantic meaning and offer enough control information(links etc…) to coordinate interactions between client and server.
REST is over only HTTP. HTTP is most widely used and when we talk about REST web services we just assume HTTP. HTTP defines interface with it’s methods(GET, POST, PUT, DELETE, PATCH etc) and various headers which can be used uniformly for interacting with resources. This uniformity can be achieved with other protocols as well.
REST permits many different data formats where as SOAP only permits XML.
While this may seem like it adds complexity to REST because you need to handle multiple formats, in my experience it has actually been quite beneficial. JSON usually is a better fit for data and parses much faster. REST allows better support for browser clients due to it’s support for JSON.
REST doesn’t add any specific functionality to HTTP but is an architectural style that was developed alongside HTTP and most commonly uses HTTP for its application layer protocol.
HTTP is an application protocol. REST is a set of rules, that when followed, enable you to build a distributed application that has a specific set of desirable constraints.
If you are looking for the most significant constraints of REST that distinguish a RESTful application from just any HTTP application, I would say the “self-description” constraint and the hypermedia constraint (aka Hypermedia as the Engine of Application State (HATEOAS)) are the most important.
The self-description constraint requires a RESTful request to be completely self descriptive in the users intent. This allows intermediaries (proxies and caches) to act on the message safely.
The HATEOAS constraint is about turning your application into a web of links where the client’s current state is based on its place in that web. It is a tricky concept and requires more time to explain than I have right now.