Key Points

References

Reference_description_with_linked_URLs__________________________________	Notes_____________________________________________________________________

https://www.guru99.com/web-service-architecture.html	What are web services?
https://www.guru99.com/web-services-interview-questions.html	Web Services interview questions

SOA
https://www.guru99.com/soa-principles.html


SOAP	Simple Object Access Protocol

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



REST	Representational Event Services Listener

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

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

common protocol to pass messages – XML
exposes services to clients for reusable services
supports security options
uses existing TCP protocols

WS types

SOAP web services.
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

Provider - The provider creates the web service and makes it available to client application who want to use it.
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.
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

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
Find - The requestor consults the broker to locate a published web service
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

xml based
soap message has a header and a body
loosely coupled
synch or asynch
supports rpc
supports document exchange
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

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.
The server then authenticates itself to the client by sending its certificate. This ensures that the client is communicating with the right server.
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

If the message within the SOAP body has been signed with any security key, that key can be defined in the header element.
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

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.
The security token is then passed to the Web service client.
The Web service client then called the web service, but, this time, ensuring that the security token is embedded in the SOAP message.
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

see m REST

see m REST API design and tools

REST overview

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

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.
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.

Microservices	Monolithic Architecture
Every unit of the entire application should be the smallest, and it should be able to deliver one specific business goal.	A single code base for all business goals
Service Startup is relatively quick	Service startup takes more time
Fault isolation is easy. Even if one service goes down, other can continue to function.	Fault isolation is difficult. If any specific feature is not working, the complete system goes down. In order to handle this issue, the application needs to re-built, re-tested and also re-deployed.
All microservices should be loosely coupled so that changes made in one does not affect the other.	Monolithic architecture is tightly coupled. Changes in one module of code affect the other
Businesses can deploy more resources to services that are generating higher ROI	Since services are not isolated, individual resource allocation not possible
More hardware resources could be allocated to the service that is frequently used. In the e-commerce example above, more number of users check the product listing and search compared to payments. So, more resources could be allocated to the search and product listing microservice.	Application scaling is challenging as well as wasteful.
Microservices always remains consistent and continuously available.	Development tools get overburdened as the process needs to start from the scratch.
Data is federated. This allows individual Microservice to adopt a data model best suited for its needs.	Data is centralized.
Small Focused Teams. Parallel and faster development	Large team and considerable team management effort is required
Change in the data model of one Microservice does not affect other Microservices.	Change in data model affects the entire database
Interacts with other microservices by using well-defined interfaces	Not applicable
Microservices work on the principle that focuses on products, not projects	Put emphasize on the entire project
No cross-dependencies between code bases. You can use different technologies for different Microservices.	One function or program depends on others.

Microservice Challenges

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

SOA vs Microservices

Parameter	SOA	Microservices
Design type	In SOA, software components are exposed to the outer world for usage in the form of services.	Micro Service is a part of SOA. It is an implementation of SOA.
Dependency	Business units are dependent.	They are independent of each other.
Size of the Software	Software size is larger than any conventional software	The size of the Software is always small in Microservices
Technology Stack	The technology stack is lower compared to Microservice.	Microservice technology stack could be very large
Nature of the application	Monolithic in nature	Full stack in nature
Independent and Focus	SOA applications are built to perform multiple business tasks.	They are built to perform a single business task.
Deployment	The deployment process is time- consuming.	Deployment is straightforward and less time-consuming.
Cost - effectiveness	More cost-effective.	Less cost-effective.
Scalability	Less compared to Microservices.	Highly scalable.
Business logic	Business logic components are stored inside of single service domain Simple wire protocols(HTTP with XML JSON) API is driven with SDKs/Clients	Business logic can live across domains enterprise Service Bus like layers between services Middleware

Microservices Summary

Microservices is a service-oriented architecture pattern wherein applications are built as a collection of various smallest independent service units.
Microservice Architecture is an architectural development style that allows building an application as a collection of small autonomous services developed for a business domain.
Monolithic architecture is like a big container in which all the software components of an application are clubbed into a single package
In a Microservice, every unit of the entire application should be the smallest, and it should be able to deliver one specific business goal
In Monolithic architecture, large code base can slow down the entire development process. New releases can take months. Code maintenance is difficult
Two types of Microservices are 1) Stateless 2) Stateful
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
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
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
Wiremock, Docker, and Hystrix are some popular Microservices Tools

Service Virtualization

https://www.guru99.com/service-virtualization-tools.html

Service Virtualization is a method that helps you to emulate (virtual services) the behaviors of the component in a Service Oriented Architecture (Microservice). Practically the software development, testing, and operations teams do not work in synch, and each team has to wait for others to have components ready. This causes delays in workflows and may deliver an inferior product. With Service Virtualization, DevOps teams use virtual services instead of production services, so they can test the system even when key components are not ready. With Service Virtualization, integrating of applications takes place early in the development cycle thereby reducing time and cost to fix errors.

Mountebank for testing virtual services

Mountebank is an open source tool which can execute multi-protocol tests. The codebase is Node JS. It is easy to create stubs and mocks.

Features:

Mountebank tool aims to be fully cross-platform, with native language bindings
It is non-modal and multi-protocol solution. It can test SMTP, HTTP, TCP, and HTTPS
This tool provides service virtualization service free of cost without any platform constraints
Frequently updated, mature, and stable tool.

Learn More:http://www.mbtest.org/

reasons for using service Virtualization for your business:

Helps you to accelerate Application Delivery while mitigating business risks
It helps you to simulates the behavior of select components within an application to enable end-to-end testing of the application as a whole.
Allows the teams to work in parallel
Allows you to Test Early and often which expose defect when they are faster, easiest and least costly to resolve
Facilitates better test coverage
Virtual services offer rich tools for editing and managing which help you improve productivity, cut down on maintenance time and development costs.
It is useful for anyone involved in developing and delivering software applications.
Access to more systems and services
It supports test-driven development.
Gives you an isolated environment for testing

Microservices Design Patterns and Frameworks

https://microservices.io/

Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of services that are

Highly maintainable and testable
Loosely coupled
Independently deployable
Organized around business capabilities
Owned by a small team

The microservice architecture enables the rapid, frequent and reliable delivery of large, complex applications. It also enables an organization to evolve its technology stack.

How to apply the patterns

Application architecture patterns

Decomposition

Refactoring to microservicesnew

Data management

Transactional messaging

Testing

Deployment patterns

Cross cutting concerns

Communication style

External API

Service discovery

Reliability

Circuit Breaker

Security

Access Token

Observability

UI patterns

Managing data consistency in a microservice architecture using Sagas

This presentation is a more in depth look at using sagas to maintain data consistency in a microservice architecture.

https://microservices.io/presentations/index.html

https://www.slideshare.net/chris.e.richardson/saturn-2018-managing-data-consistency-in-a-microservice-architecture-using-sagas

SOAPUI test tool tutorial

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

SoapUI is the market leader in API Testing Tool. You can do functional, load, security and compliance tests on your API using SoapUI. This class covers basics of SoapUI

Tutorial	Web Service Testing: A Beginner's Guide
Tutorial	Introduction to SOAPUI
Tutorial	SOAP UI Installation and Configuration: Complete Guide
Tutorial	SoapUI Tutorial: Create a Project, Test Suite, TestCase
Tutorial	Assertions in SoapUI: Complete Tutorial
Tutorial	SOAPUI Interview Questions & Answers
Tutorial	15 Rest API Interview Question & Answers
Tutorial	19 Best SoapUI Alternatives

Messaging Concepts

#todo

API End Point Management Concepts

#todo

IBM API Connects creates and manages API's for IIB ( IBM Integration Bus )

DataPower API Gateway Appliance

https://www.ibm.com/products/datapower-gateway

IBM DataPower® Gateway helps organizations meet the security and integration needs of a digital business in a single multi-channel gateway. It provides security, control, integration and optimized access to a full range of mobile, web, application programming interface (API), service-oriented architecture (SOA), B2B and cloud workloads.

The new DataPower Gateway IDG X2 physical appliance delivers up to 2X the performance of IBM DataPower Gateway (IDG) with next generation hardware architecture. It also provides a flash drive with 2X higher capacity than IDG and 2X 10GbE network ports. IDG X2 accelerates application responsiveness and increases workload capacity, which is critical for higher performance and/or for running additional tenants with governance and a lower TCO.

Potential Value Opportunities

Potential Challenges

Candidate Solutions

Step-by-step guide for Example

sample code block

sample code block

Recommended Next Steps

Related articles

Browser not supported