More Services

Key Points

References

Key Concepts

Web Services framework overview

https://www.guru99.com/web-service-architecture.html

Web service summary

The client would invoke a series of web service calls via requests to a server which would host the actual web service.

These requests are made through what is known as remote procedure calls. Remote Procedure Calls(RPC) are calls made to methods which are hosted by the relevant web service.

As an example, Amazon provides a web service that provides prices for products sold online via amazon.com. The front end or presentation layer can be in .Net or Java but either programming language would have the ability to communicate with the web service.

The main component of a web service is the data which is transferred between the client and the server, and that is XML. XML (Extensible markup language) is a counterpart to HTML and easy to understand the intermediate language that is understood by many programming languages.

WS benefits

1. common protocol to pass messages – XML

2. exposes services to clients for reusable services

3. supports security options

4. uses existing TCP protocols

WS types

1. SOAP web services.

2. RESTful web services.
   
   

SOAP-messages

soap messages have an envelope with a header and body

• The header contains the routing data which is basically the information which tells the XML document to which client it needs to be sent to.

• The body will contain the actual message.

The header element can contain information such as authentication credentials which can be used by the calling application. It can also contain the definition of complex types which could be used in the SOAP message. By default, the SOAP message can contain parameters which could be of simple types such as strings and numbers, but can also be a complex object type.

<xsd:complexType>     
 <xsd:sequence>       
 	<xsd:element name="Tutorial Name" type="string"/>         
  	<xsd:element name="Tutorial Description"  type="string"/>
  </xsd:sequence>
</xsd:complexType>

SOAP frameworks marshal and unmarshal the messages

SOAP example in VB

https://www.guru99.com/soap-simple-object-access-protocol.html

WSDL

The WSDL file is again an XML-based file which basically tells the client application what the web service does. By using the WSDL document, the client application would be able to understand where the web service is located and how it can be utilized.

UDDI

UDDI is a standard for describing, publishing, and discovering the web services that are provided by a particular service provider. It provides a specification which helps in hosting the information on web services.

Agent - Broker - Service architecture

1. Provider - The provider creates the web service and makes it available to client application who want to use it.
2. Requestor - A requestor is nothing but the client application that needs to contact a web service. The client application can be a .Net, Java, or any other language based application which looks for some sort of functionality via a web service.
3. Broker - The broker is nothing but the application which provides access to the UDDI. The UDDI, as discussed in the earlier topic enables the client application to locate the web service.

Connecting client to a service

1. Publish - A provider informs the broker (service registry) about the existence of the web service by using the broker's publish interface to make the service accessible to clients
2. Find - The requestor consults the broker to locate a published web service
3. Bind - With the information it gained from the broker(service registry) about the web service, the requestor is able to bind, or invoke, the web service.

Web services features

1. xml based
2. soap message has a header and a body
3. loosely coupled
4. synch or asynch
5. supports rpc
6. supports document exchange
7. wsdl defines how to bind to a service

Web Services Security with SOAP

https://www.guru99.com/security-web-services.html

Client Server Interaction over HTTPS

In a standard HTTPS communication between the client and the server, the following steps take place

1. The client sends a request to the server via the client certificate. When the server sees the client certificate, it makes a note in its cache system so that it knows the response should only go back to this client.
2. The server then authenticates itself to the client by sending its certificate. This ensures that the client is communicating with the right server.
3. All communication thereafter between the client and server is encrypted. This ensures that if any other users try to break the security and get the required data, they would not be able to read it because it would be encrypted.

Security data stored in SOAP message header

The header element can contain the below-mentioned information

1. If the message within the SOAP body has been signed with any security key, that key can be defined in the header element.
2. If any element within the SOAP Body is encrypted, the header would contain the necessary encryptions keys so that the message can be decrypted when it reaches the destination.

SOAP authentication helps in the following way.

• Since the SOAP body is encrypted, it will only be able to be decrypted by the web server that hosts the web service. This is because of how the SOAP protocol is designed.
• Suppose if the message is passed to the database server in an HTTP request, it cannot be decrypted because the database does not have right mechanisms to do so.
• Only when the request actually reaches the Web server as a SOAP protocol, it will be able to decipher the message and send the appropriate response back to the client.

The credentials in the SOAP header is managed in 2 ways.

First, it defines a special element called UsernameToken. This is used to pass the username and password to the web service.

The other way is to use a Binary Token via the BinarySecurityToken. This is used in situations in which encryption techniques such as Kerberos or X.509 is used.

The below diagram shows the flow of how the security model works in WS Security

Below are the steps which take place in the above workflow

1. A request can be sent from the Web service client to Security Token Service. This service can be an intermediate web service which is specifically built to supply usernames/passwords or certificates to the actual SOAP web service.
2. The security token is then passed to the Web service client.
3. The Web service client then called the web service, but, this time, ensuring that the security token is embedded in the SOAP message.
4. The Web service then understands the SOAP message with the authentication token and can then contact the Security Token service to see if the security token is authentic or not.

ASP example for Secure Web Service

https://www.guru99.com/security-web-services.html

REST services

https://www.guru99.com/restful-web-services.html

REST is used to build Web services that are lightweight, maintainable, and scalable in nature. A service which is built on the REST architecture is called a RESTful service. The underlying protocol for REST is HTTP, which is the basic web protocol. REST stands for REpresentational State Transfer

REST elements

The key elements of a RESTful implementation are as follows:

Resources –
to access an employee record resource via REST, one can issue the command http://demo.guru99.com/employee/1 - This command tells the web server to get the details of the employee whose employee number is 1.

Request Verbs -
These describe what you want to do with the resource. A browser issues a GET verb to instruct the endpoint it wants to get data. other verbs like POST, PUT, UPDATE and DELETE.

Request Headers –
These are additional instructions sent with the request. These might define the type of response required or the authorization details.

Request Body -
Data is sent with the request. Data is normally sent in the request when a POST request is made to the REST web service. In a POST call, the client tells the service it wants to add a resource to the server.

Response Body –
This is the main body of the response. So in our example, if we were to query the web server via the request http://demo.guru99.com/employee/1 , the web server might return an XML document with all the details of the employee in the Response Body.

Response Status codes –
codes are returned with the response from the web server.

REST methods

• POST – This would be used to create a new employee using the RESTful web service
• GET - This would be used to get a list of all employee using the RESTful web service
• PUT - This would be used to update all employee using the RESTful web service
• DELETE - This would be used to delete all employee using the RESTful web service
• PATCH - Update a resource

Why REST?

• Heterogeneous languages and environments – This is one of the fundamental reasons which is the same as we have seen for SOAP as well.
• It enables web applications that are built on various programming languages to communicate with each other
• With the help of Restful services, these web applications can reside on different environments, some could be on Windows, and others could be on Linux.

RESTful Architecture

1. State and functionality are divided into distributed resources – This means that every resource should be accessible via the normal HTTP commands of GET, POST, PUT, or DELETE. So if someone wanted to get a file from a server, they should be able to issue the GET request and get the file. If they want to put a file on the server, they should be able to either issue the POST or PUT request. And finally, if they wanted to delete a file from the server, they an issue the DELETE request.
2. The architecture is client/server, stateless, layered, and supports caching –
   1. Client-server is the typical architecture where the server can be the web server hosting the application, and the client can be as simple as the web browser.
      Stateless means that the state of the application is not maintained in REST.
   2. For example, if you delete a resource from a server using the DELETE command, you cannot expect that delete information to be passed to the next request.

REST example in .Net

https://www.guru99.com/restful-web-services.html

Microservices Tutorial

https://www.guru99.com/microservices-tutorial.html

Microservices is a service-oriented architecture pattern wherein applications are built as a collection of various smallest independent service units. It is a software engineering approach which focuses on decomposing an application into single-function modules with well-defined interfaces. These modules can be independently deployed and operated by small teams who own the entire lifecycle of the service.

Microservice Challenges

1. MicroServices rely on each other, and they will have to communicate with each other.
2. Compared to monolithic systems, there are more services to monitor which are developed using different programming languages.
3. As it is a distributed system, it is an inherently complex model.
4. Different services will have its separate mechanism, resulting in a large amount of memory for an unstructured data.
5. Effective management and teamwork required to prevent cascading issues
6. Reproducing a problem will be a difficult task when it's gone in one version, and comes back in the latest version.
7. Independent Deployment is complicated with Microservices.
8. Microservice architecture brings plenty of operations overhead.
9. It is difficult to manage application when new services are added to the system
10. A wide array of skilled professionals is required to support heterogeneously distributed microservices
11. Microservice is costly, as you need to maintain different server space for different business tasks.

SOA vs Microservices

Microservices Summary

1. Microservices is a service-oriented architecture pattern wherein applications are built as a collection of various smallest independent service units.
2. Microservice Architecture is an architectural development style that allows building an application as a collection of small autonomous services developed for a business domain.
3. Monolithic architecture is like a big container in which all the software components of an application are clubbed into a single package
4. In a Microservice, every unit of the entire application should be the smallest, and it should be able to deliver one specific business goal
5. In Monolithic architecture, large code base can slow down the entire development process. New releases can take months. Code maintenance is difficult
6. Two types of Microservices are 1) Stateless 2) Stateful
7. Microservices rely on each other, and they will have to communicate with each other. Helps you to give emphasizes on a specific feature and business needs
8. Service-oriented architecture shortly known as SOA is an evolution of distributed computing based on the request or reply design model for synchronous and asynchronous applications
9. In SOA, software components are exposed to the outer world for usage in the form of services whereas Micro Service is a part of SOA. It is an implementation of SOA
10. Wiremock, Docker, and Hystrix are some popular Microservices Tools

Potential Value Opportunities

Potential Challenges

Candidate Solutions

Step-by-step guide for Example

sample code block

Recommended Next Steps

Related articles