Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Key Points


References

Reference_description_with_linked_URLs__________________________________Notes_____________________________________________________________________


https://www.guru99.com/web-service-architecture.htmlWhat are web services?




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




SOAPSimple Object Access Protocol


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






RESTRepresentational Event Services Listener


https://www.guru99.com/restful-web-services.htmlREST 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

  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.


MicroservicesMonolithic 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 quickService 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 ROISince 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 developmentLarge 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 interfacesNot applicable
Microservices work on the principle that focuses on products, not projectsPut 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

  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

ParameterSOAMicroservices
Design typeIn 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.
DependencyBusiness units are dependent.They are independent of each other.
Size of the SoftwareSoftware size is larger than any conventional softwareThe size of the Software is always small in Microservices
Technology StackThe technology stack is lower compared to Microservice.Microservice technology stack could be very large
Nature of the applicationMonolithic in natureFull stack in nature
Independent and FocusSOA applications are built to perform multiple business tasks.They are built to perform a single business task.
DeploymentThe deployment process is time- consuming.Deployment is straightforward and less time-consuming.
Cost - effectivenessMore cost-effective.Less cost-effective.
ScalabilityLess compared to Microservices.Highly scalable.
Business logicBusiness 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

  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


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:

  1. Helps you to accelerate Application Delivery while mitigating business risks
  2. 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.
  3. Allows the teams to work in parallel
  4. Allows you to Test Early and often which expose defect when they are faster, easiest and least costly to resolve
  5. Facilitates better test coverage
  6. Virtual services offer rich tools for editing and managing which help you improve productivity, cut down on maintenance time and development costs.
  7. It is useful for anyone involved in developing and delivering software applications.
  8. Access to more systems and services
  9. It supports test-driven development.
  10. Gives you an isolated environment for testing


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

TutorialWeb Service Testing: A Beginner's Guide
TutorialIntroduction to SOAPUI
TutorialSOAP UI Installation and Configuration: Complete Guide
TutorialSoapUI Tutorial: Create a Project, Test Suite, TestCase
TutorialAssertions in SoapUI: Complete Tutorial
TutorialSOAPUI Interview Questions & Answers
Tutorial15 Rest API Interview Question & Answers
Tutorial19 Best SoapUI Alternatives



Potential Value Opportunities



Potential Challenges



Candidate Solutions



Step-by-step guide for Example



sample code block

sample code block
 



Recommended Next Steps



  • No labels