10 principles of SOA

• Explicit Boundaries - Everything needed by the service to provide its functionality should be passed to it when it's invoked. All access to service should be via its publicly exposed interface. Service invocations should be modeled as stateless. A service invocation isn't a remote procedure call.

• Shared Contract and Schema, not Class - Data is exchanged as XML documents validatable against one or more schemas.

• Policy-driven - The provider's functionality, syntax, and semantics must fit the consumer's requirements. The technical capabilities and needs must match.

• Autonomous - It must be possible to change a service's runtime environment, without affecting its consumers. Services can be changed and deployed , versioned, and managed independently of each other. A service provider can't rely on the ability of its consumers to adapt to a new version of the service quickly; some of them might not be able, or willing , to adapt to a new version of the service interface all.

• Wire Formats, not Programming Language APIs - Services are exposed using a specific wire format that has to be supported. A service must be accessible from any platform that supports the exchange of messages adhering to the service interface as long as the interaction conforms to the policy defined for the service.

• Document-oriented - To interact with services, data is passed as documents. It should be self-descriptive. It should be explicitly modeled. e.g. a customer ID might be included along with the customer's address information (although the customer ID would be enough). This redundancy is explicitly accepted since it serves to isolate the service interface from the underlying data model of both service consumer and service provider. When a document-oriented pattern is applied, service invocations become meaningful exchanges of business messages instead of context-free RPC calls. When messages are sent in a Distributed Objects or RPC infrastructure, client and server can rely on a set of proxy classes (stubs and skeletons) generated from the interface description document.

• Loosely coupled - There are multiple dimensions in which a system can be loosely or tightly coupled. Dimensions include -

• Time - When participants are loosely coupled in time, they don't have to be up and running at the same time to communicate. This requires some way of buffering/queuing in between them. When one participant sends a message to the other one, it doesn't rely on an immediate answer to continue processing.

• Location - If participants query for the address of other participants they intend to communicate with, the location can change without having to reprogram, reconfigure, or even restart the communication partners. This implies some sort of lookup process using a directory or address that stores service endpoint addresses.

• Type - A participant can either rely on all or parts of a document structure to do its work.

• Version - Service providers should be implemented to accept as many different versions as possible, and thus be liberal in what they accept, while service consumers should do their best to conform to exact grammars and document types.

• Cardinality - There may be a 1:1 relationship between service consumers and service providers especially in cases where a request/response interaction takes place or an explicit message queue is used.

• Lookup - A participant that intends to invoke a service can either rely on a name of a service provider to communicate with, or it can do a lookup operation first using a description of a set of capabilities instead. This implies a registry and/or repository that can match the consumer's needs to a provider's capabilities.

• Standards-compliant - Standards exist for technical aspects such as data formats, metadata, transport, and transfer protocols, as well as for business-level artifacts such as document types. Reliance should be on standards instead of proprietary APIs.

• Vendor-independent - It's unavoidable to decide on specific products, both commercial and free/open source software. None of these decisions must have implications on an architectural level. A participant can be built using any technology that supports the appropriate standards and not be restricted by any vendor roadmap.

• Metadata-driven - All of the metadata artifacts in the overall SOA need to be stored in a way that enables them to be discovered, retrieved, and interpreted at both design time and runtime.

Top 20 Web services interview questions

Web services interview questions are most asked questions if you are applying for software developer role.
In this post, we will see multiple web services interview questions.

1. What are web services?

Web services are ways of communication between two application over network. It allows you to expose business logic using API.

For example:
Lets say you are java developer, you can create web service and expose API over internet and any other developer (lets say .net developer ) can access it.

2. What are features of web services?

• Interoperability
• Reuse already developed(old) functionality into new software:
• Loosely Coupled
• Extensibility

3. What are different types of web services?

• SOAP
• Restful web services

4. What is SOAP?

SOAP stands for Simple object access protocol. It is protocol to exchange information using request and response in XML format over transport protocol such as HTTP, SMTP etc.

5. What are important components for SOAP?

• Simple access object protocol (SOAP)
• Web Services Description Language (WSDL)
• Universal Description, Discovery and Integration(UDDI)

6. What is WSDL?

WSDL stands for Web Service Description Language. It is an XML file that describes the technical details of how to implement a web service, more specifically the URI, port, method names, arguments, and data types. You can understand following details using WSDL

•     Port / Endpoint – URL of the web service
•     Input message format
•     Output message format
•     Security protocol that needs to be followed
•     Which protocol the web service uses

7. What is UDDI?

UDDI stands for Universal Description, Discovery and Integration.It is a directory service. Web service provider can register themselves with a UDDI and make themselves available through it for discovery.

8. What is JAX-WS?

JAX-WS stands for Java API for XML Web Services. JAX-WS is standard XML based Java API which is used to create SOAP web services.

9. What are some important annotations for JAX-WS?

• @WebService
• @WebMethod
• @SOAPBinding

10. What do you mean by end point in terms of SOAP?

End point is nothing but URL which other application can use to access it.

for example:

end  point:http://localhost:8080/WS/HelloWorld

11. How can you access WSDL for web service?

You just need to put ?wsdl at the end of end point URL.

for example:

end  point:http://localhost:8080/WS/HelloWorld
WSDL url: http://localhost:8080/WS/HelloWorld?wsdl

12. What is wsimport?

wsimport is utility which generates java classes from WSDL. It is part of JDK 6.

13.What is sun-jaxws.xml file?

This file provides endpoint details about JAX-WS web service which is deployed on tomcat.It is available at WEB-INF directory.
For example:

<?xml version="1.0" encoding="UTF-8"?> <endpoints xmlns="http://java.sun.com/xml/ns/jax-ws/ri/runtime" version="2.0"> <endpoint name="HelloWorldWS" implementation="org.arpit.javapostsforlearning.webservice.HelloWorldImpl" url-pattern="/HelloWorldWS"/> </endpoints>

14. What are Restful web services?

In the web services terms, REpresentational State Transfer (REST) is a stateless client-server architecture in which the web services are viewed as resources and can be identified by their URIs. Web services client uses that URI to access the resource.

15.What are HTTP methods that can be used with Restful web services?

Mainly used HTTP methods are GET, POST, PUT, DELETE, HEAD and OPTIONS

16. What is JAX-RS?

Java API for RESTful Web Services (JAX-RS), is a set if APIs to create web service which supports REST architecture. JAX-RS is part of the Java EE6, and help developers to create REST web application easily.

17. What are some important annotations which you use to create Restful web services?

Some of important annotations which are used for creating web services are:

@Path : This is used to set path for URI at class level or method level
@GET,@POST,@PUT,@DELETE  : There are annotations corresponds to HTTP methods
@Produces(MediaType.TEXT_XML [, more-types ]): @Produces defines which MIME type is delivered by a method
@PathParam: Used to inject values from the URL into a method parameter.
@Consumes(MediaType.TEXT_XML) : @Cosumes defines which MIME type will be consumed by the method .

18.  What are ways to test SOAP web services?

For testing SOAP :
SOAPUI
For testing Restful web services:

• Postman for chrome browser
• poster for firefox

19. How to choose between REST and SOAP web services?

• If you want to implement web services in less time, go with REST
• If you know your client beforehand , then you can choose SOAP. If you are not aware about clients then go with REST.
• If you want to work with different format other than XML, go with REST. SOAP only supports XML format.

20. What are differences between SOAP and REST web services?

You can refer to difference between SOAP and REST web services for more details.

That’s all about Web services interview questions.

What is Web Service?

we will see the introduction of web service tutorial and some jargons of web services.

Web services are used everywhere nowadays. When human interacts with any web page, it involves request and response via HTML. When you interact with the webpage, browser sends a request and then renders response and shows in form of HTML. Similarly, web services also involve request and response but in the form of XML or JSON or plain text. It generally used for other applications or programs to consume and make use of information.

For example:
You are creating a website which shows weather information of important cities in the world. You can actually consume already exposed web services and get the data for the cities. You will get the response in form of XML or JSON, you can parse it and show it on your website.

Let’s go to more formal definition now:

Web service is a way of communication that allows interoperability between different applications on different platforms, for example, a Java based application on Windows can communicate with a .Net based one on Linux. The communication can be done through a set of XML messages over HTTP protocol.Web services are browsers and operating system independent service, which means it can run on any browser without the need of making any changes. Web Services take Web-applications to the Next Level.

The World Wide Web Consortium (W3C) has defined the web services. According to W3C, “Web Services are the message-based design frequently found on the Web and in enterprise software. The Web of Services is based on technologies such as HTTP, XML, SOAP, WSDL, SPARQL, and others.”
Let’s say, you are a Java developer and you can publish your functions on internet or LAN through java web service so any other developer(let’s say .Net developer) can access your function.

You can go through web services interview questions for interview questions on web services.

Why you need to learn web services:

Reuse already developed(old) functionality into new software:

Let’s understand with the very simple example.Let’s say you are developing a finance software for a company on java and you have old .net software which manages salary of employees.So rather than developing new software for employee part, you can use old software and for other parts like infrastructure, you can develop your own functionalities.

Usability :

Web Services allow the business logic of many different systems to be exposed over the Web. This gives your applications the freedom to chose the Web Services that they need. Instead of re-inventing the wheel for each client, you need only include additional application-specific business logic on the client-side. This allows you to develop services and/or client-side code using the languages and tools that you want.

Interoperability :

This is the most important benefit of Web Services. Web Services typically work outside of private networks, offering developers a non-proprietary route to their solutions.Web Services also let developers use their preferred programming languages. In addition, thanks to the use of standards-based communications methods, Web Services are virtually platform-independent.

Loosely Coupled:

Each service exists independently of the other services that make up the application. Individual pieces of the application to be modified without impacting unrelated areas.

Ease of Integration:

Data is isolated between applications creating ’silos’. Web Services act as glue between these and enable easier communications within and across organizations.

Deployability :

Web Services are deployed over standard Internet technologies. This makes it possible to deploy Web Services even over the firewall to servers running on the Internet on the other side of the globe. Also thanks to the use of proven community standards, underlying security (such as SSL) is already built-in.

Some jargons used in Web services:

Simple Object Access Protocol(SOAP):

SOAP is a protocol specification for exchanging structured information in the implementation of Web services in computer networks. It relies on XML as its message format.

Web Service Description Language(WSDL):

WSDL stands for Web Service Description Language. It is an XML file that describes
the technical details of how to implement a web service, more specifically the URI,
port, method names, arguments, and data types. Since WSDL is XML, it is both
human-readable and machine-consumable, which aids in the ability to call and bind to
services dynamically.

Elements of WSDL are:

Description:
It is the root element of a WSDL 2.0 file. It usually contains a set of namespace declarations which are used throughout the WSDL file.  

Types:
The WSDL types element describes the data types used by your web service.Data types are usually specified by XML schema.It can be described in any language as long as your web services API supports it.

Binding:
The WSDL binding element describes how your web service is bound to a protocol. In other words, how your web service is accessible. To be accessible, the web service must be reachable using some network protocol. This is called “binding” the web service to the protocol.

Interface:
The WSDL interface element describes the operations supported by your web service.It is similar to methods in programming language.The client can only call one operation per request.

Service:
It describes the endpoint of your web service. In other words, the address where the web service can be reached.

Endpoint:
The endpoint element describes the address of the web service. The endpoint binding attribute describes what binding element this endpoint uses.i.e. protocol with which you will access web service. The address attribute describes the URI at which you can access the service.

Message:
The message element describes the data being exchanged between the Web service providers and consumers.

Sample WSDL file:

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://webservices.javapostsforlearning.arpit.org" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://webservices.javapostsforlearning.arpit.org" xmlns:intf="http://webservices.javapostsforlearning.arpit.org" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!--WSDL created by Apache Axis version: 1.4
Built on Apr 22, 2006 (06:55:48 PDT)-->
<wsdl:types>
<schema elementFormDefault="qualified" targetNamespace="http://webservices.javapostsforlearning.arpit.org" xmlns="http://www.w3.org/2001/XMLSchema">
<element name="sayHelloWorld">
<complexType>
<sequence>
<element name="name" type="xsd:string"/>
</sequence>
</complexType>
</element>
<element name="sayHelloWorldResponse">
<complexType>
<sequence>
<element name="sayHelloWorldReturn" type="xsd:string"/>
</sequence>
</complexType>
</element>
</schema>
</wsdl:types>
<wsdl:message name="sayHelloWorldRequest">
<wsdl:part element="impl:sayHelloWorld" name="parameters"/>
</wsdl:message>
<wsdl:message name="sayHelloWorldResponse">
<wsdl:part element="impl:sayHelloWorldResponse" name="parameters"/>
</wsdl:message>
<wsdl:portType name="HelloWorld">
<wsdl:operation name="sayHelloWorld">
<wsdl:input message="impl:sayHelloWorldRequest" name="sayHelloWorldRequest"/>
<wsdl:output message="impl:sayHelloWorldResponse" name="sayHelloWorldResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="HelloWorldSoapBinding" type="impl:HelloWorld">
<wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="sayHelloWorld">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="sayHelloWorldRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="sayHelloWorldResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="HelloWorldService">
<wsdl:port binding="impl:HelloWorldSoapBinding" name="HelloWorld">
<wsdlsoap:address location="http://localhost:8080/SimpleSOAPExample/services/HelloWorld"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

Universal Description, Discovery and Integration(UDDI):

UDDI stands for Universal Description, Discovery, and Integration.It is a directory service. Web services can register with a UDDI and make themselves available through it for discovery

Web service design approaches:

Contract last or Bottom-up approach:

When using contract last approach, you first write your Java code then you create web service contract(WSDL).There are various kinds of tools which can generate WSDL on the basis of Java code.

Contract first or Top Down Approach:

It is reverse of contract first.Here you first define web service contract.You define all the elements of WSDL first then after that you create your java logic.

Types of web services:

There are mainly two types of web services.

• REST
• SOAP

You can read about differences and usage of REST and SOAP web services.

That’s all about the web services tutorial.

Difference between SOAP and REST web services in java

We have already seen SOAP web services and RESTful web services in detail before. In this post, we are going to see differences between SOAP and REST web services.

SOAP vs REST web services

Parameter	SOAP	REST
Acronym	SOAP stands for simple object access protocol	REST stands for REpresentational State Transfer
Protocol vs Architectural style	SOAP is a standard protocol to create web services	Rest is architectural style to create web services.
Contract	Client and Server are bind with WSDL contract	There is no contract between client and Server.
Format Support	SOAP supports only XML format	REST web services supports XML, json and plain text etc.
Maintainability	SOAP web services are hard to maintain as if we do any changes in WSDL , we need to create client stub again	REST web services are generally easy to maintain.
Service interfaces vs URI	SOAP uses Service interfaces to expose business logic	Rest uses URI to expose business logic
Security	SOAP has its own security : WS-security	Rest inherits its security from underlying transport layer.
Bandwidth	SOAP requires more bandwidth and resources as it uses XML messages to exchange information	REST requires less bandwith and resources. It can use JSON also.
Learning curve	SOAP web services are hard to learn as you need to understand WSDL , client stub	REST web services are easy to understand as you need to annotate plain java class with JAX-RS annotations to use various HTTP methods.

This is all about Difference between SOAP and REST web services in java. If you find more differences, please comment, so that I can include them in post.