Thursday, December 21, 2017

Type of Virtual Services / Stubs / Mocks

Stubs and virtualized applications can be simple or rich. Many vendors provides different service virtualization tools to create stubs and virtualized applications to the level required for support with development and testing.

In this blog we will have a quick look at what are the different types of stubs or virtual services which are required to roll out a quality product early.

 

Stub Type

Description

Basic

There is a hard-coded single response for each specific input.

Non-deterministic

There are "n" hard-coded responses. A message switch is used to "switch" the response based on the input message.

Data-driven (parameterized)

There is input and/or output data specified in external data sources, for example, databases or spreadsheet files.

Data model-driven

There is input and/or output data in a data model that includes relationships among those data items.

Behavior-driven

Stubs can be extended with "behaviors" that are Java plug-ins that can respond to messages and proactively cause the stub to behave in a particular way.

All the major vendors like CA, IMB, Smartbear supplies some behaviors with their service virtualization tools but we can write our own. For example, a behavior can be used to make a stub act as a market data feed source.

Deterministic

This comprises a series of Receive Request/Send Response or Subscribe/Publish actions that are based on the message used to create the stub.

 

Hope this short blog gives you the details to get insight of types of Virtual Services or Stubs

 

Feel free to share your inputs / suggestions in the comment section below.

 

 

Friday, December 15, 2017

Microservices Integration Patterns - Catering Continuous Deployment Requirements

Hello All,
In this blog we will try to understanding what microservices are and what are the different integration patterns in which microservices are implemented.
Lets first understand what are microservices
Micro Service is independently deployable service modeled around a business domain. It is a method of breaking large software applications into loosely coupled modules, in which each service runs a unique process and communicates through APIs. It can be developed using messaging or event-driven APIs, or using non-HTTP backed RPC mechanisms.
Micro Services are designed to cope with failure and breakdowns of large applications. Since multiple unique services are communicating together, it may happen that a particular service fails, but the overall larger applications remain unaffected by the failure of a single module.
Now the question arises what is the need to implement microservices when we have integrated different systems for atleast a decade now.
The answer is in the below table

Gone are the days when we used to have 3-4 releases in a year. The current business demands us to roll out new features and application more frequently and with very minimal or no downtime.
In the example above, we can see how the releases have changes and now code can be deployed more frequently like the case of amazon where they deploy the code into production every 11.6 seconds
There are different integration patterns using which one can implement microservice and cater to the continuous changing business needs.
We will try to understand it with an banking example.

Let’s assume that we are responsible for building an application for managing a Banks day-to-day operations. Among the many things that our application will have to do, we’ll focus on:
  • Managing Debate and Credit cards transaction
  • Managing the net banking transaction
  • Managing lending transaction
Now, let’s say a customer swipes his debate card. What should our application do? It should certainly update the customers record. It should also initiate the transaction in net banking module. It also makes debate of the debate card transaction and update the available balance in the net banking module
In a monolithic architecture, using a single relational database for the whole application, would be straightforward. In the same process and transaction, we can update the customer record, mark any available balance changes, and insert the customers record into the corresponding table. In case of errors, we can rollback the transaction.




On the other hand, in a distributed microservices architecture, it can start to get complicated. Let’s assume that we have the following services:
  • transaction service from cards, which manages customers transactions records
  • creditCheck service, which manages the customers bankings operations
  • An lending service, which manages customers mortgage and lending's

Remember that each service manages its own data, so that when the transaction Service is triggered with a transaction when the customer swipes his card, it not only has to update its own database, but it also has to make sure that the other relevant services are also notified. This is critical for maintaining consistency in the application. But which is the best way for a service to notify other interested services of events or changes?

To understand it more, refer below example with pointers for the different transaction involved and different systems / applications which help implement it.




mS- > JDBC ->  MQ -> 3rd Party
  1. User initiates Transaction by swiping Card
  2. Card systems confirms the availability of fund with net banking
  3. Net banking send the confirmation to process transaction
  4. Net banking send request to process notification based on the preference given by user [SMS, eMail] to Notification system
  5. Notification system creates entry in audit tables and send notification message to outbound queue
  6. 3rd Party system consumes the message, process the message and returns acknowledge message to banking notification system by adding the acknowledge to its outbound queue
  7. Notification system updates the confirmation to Cards and Net banking system
  8. 3rd party delivers the message to end users with confirmation of transaction

      Database sharing is one the easiest and fastest way of sharing data across multiple services. In our case, we could create a new service, whose sole responsibility will be to keep the three databases in sync. The service could run a batch job every so often, in which it fetches from the Cards database the latest unprocessed transactions. Then, for each relevant record, it could update the other two services’ databases.
      You’ll notice that the new sync service has direct access to the three databases. This means that changes to any of the three services’ database schemas will also affect the new sync service. One of the fundamentals of microservices architectures is that each service/team owns its own data. This allows for development teams to make internal changes to their services without affecting any other services as well as enabling every team to deploy their services independently, with minimum coordination from other teams. By allowing other services to access their database, we’re increasing the coupling between services and teams and introducing friction into the release process. But what would happen to the other services if the shared tables’ schemas changes? And in any case who is responsible for those tables now anyway?
      These two factors alone are enough for rejecting this solution because as a general rule we want to avoid solutions in which multiple services access the same database. Especially when those services are owned by different teams. For example, you might consider having the transaction service update the other services’ databases directly. 
      Probably the most intuitive way of integrating our services would be using REST. Both the Cards, Net Banking and Lending Services can define a dedicated REST endpoint that other services can use to notify them of the transactions. In this case the Cards transaction Service will call these two endpoints when it processes a new transaction.
The advantage of this approach is clear: the implementation details of each service remain private. As long as the REST interface is not changed, each team can make any internal change it needs to its service with minimum coordination with other teams. However, this approach doesn’t come without its own set of problems.
As you probably know, REST works synchronously. There two major downsides to using synchronous communication
Temporal Coupling
We’ll have a problem if either the Cards or Net banking Service happens to be unavailable when the transaction Service sends them a request. What should the Transaction Service do? Rollback? Try again? If that doesn’t work, then what?
The more external synchronous calls our service makes, the more dependencies it has and the less resilient it becomes.





Every time a service calls another service synchronously, it will block it until it receives a response. In our case, our transaction Service will have to wait for both the creditCheck and Credit history Services to complete their requests before it can return its own response to the calling service or client. This might not seem like much, but this extra latency can add up if you’re not careful.
Also beware of cascading effects: when there is long chain of services communicating with each other via REST, one slow-responding service can slow down all the other services up the chain.

Another issue with this approach is that the calling service has to be aware of any external service that might need to get notified when an interesting event happens. We’ll need to modify our credit service every time that a new service will want to get notified of a new transaction.



We can easily decouple the caller and callee services by putting a message broker in the middle. Every time it processes a new transaction, the transaction Service will publish an event to the message broker. On the other side, the Net banking and Lending Service will have subscribed to the message broker to receive events about transaction updates. Each service will receive and process those events independently and at its own pace
The key concepts here are:
The message broker will store the messages safely until they are processed. This means that the transaction Service will be able to process new transaction, even if the net banking or lending Services are unavailable. If they happen to be unavailable, messages will accumulate in the message broker and will be processed once the services are back up
The transaction Service doesn’t need to know about the net banking and lending Services, as it only communicates with the message broker. What’s more, we can add and remove subscribed services just by reconfiguring the message broker, without affecting the transaction Service. The message broker will receive the corresponding message and send it to all subscribed services. This pattern is called fan-out
Events are being processed asynchronously now, which means that the transaction Service can return a response as soon as it has published the event to the message broker. Other slow-working services won’t affect our service’s response time
Subscribed Services can process events at its own pace. If the Publisher Services sends more events than the subscribed service can process, the message broker will act as buffer, isolating both services.
Note that we can have asynchronous communication only when our Cards Service doesn’t need a response from the other two services. This is not the case in cards swipe and all the transaction happens at run time. This is possible in scenarios of Notification only as notification are of low priority compared to transaction of the customer.
As part of the decoupling that we get by using a message broker, the Publisher Service won’t know about the Subscribed Services (and vice-versa). While this brings about several advantages, like we just saw, it also means that the Subscribed Services cannot send a response back to the Publisher Service. It would also be remiss not to mention here that using asynchronous communication makes testing and troubleshooting more difficult .

   Another possible pattern that we haven’t considered here is using files for sharing data between services. If you have experience with ETL processes, you’ll probably find this approach familiar. Every X amount of time, the transaction service could write files containing the relevant events to a common directory (FTP, S3, HDFS, etc…). On the other side, the Net banking and Lending services can poll the directory for new files to process.
Since data is processed in batches, it has a considerably large delay compared to other approaches. In addition the testing of this pattern can be quite tricky .

Monday, December 4, 2017

Microservice Testing Tools

Microservice Testing Tools

 

SoapUI is an open source, cross-platform testing tool. It can automate functional, regression, compliance and load testing of both SOAP and REST web services.  It comes with an easy-to-use graphical interface and supports industry-leading technologies and standards to mock and stimulate behavior of web services

Key Features

       Provides printable, exportable, and HTML-based reports at Project, TestSuite, TestCase, or LoadTest level.

       Comes integrated with Hudson, Bamboo, Maven, ANT, and JUnit.

       Allows developing own set of features as SoapUI Plugins.

       Records, monitors, and displays all the data.

       Supports WS-Security and SSL decryption.

 

 

TestingWhiz is a codeless test automation tool which comes with API/web services testing capability. It lets you perform functional, compliance, load testing and mocking of REST and SOAP web services via WSDL interface over HTTP and FTP. It also let’s perform service denial and penetration checks to ensure the overall health of the web services. Plus, it also lets you perform end-to-end testing right from Web UI, business logic, to database and ETL without coding needs.

Key Features

       Supports String comparison to validate the API response.

       Helps log API defects through integrated bug tracking tools like JIRA, Mantis, and Fogbugz.

       Generates visual logs and reports of test execution with an emailing facility.

       Allows distributed and parallel execution across multiple machines and nodes.

       Provide Continuous Integration with Jenkins, Bamboo & Hudson.

       Supports data-driven and keyword-driven testing.

 

SOAPSonar provides comprehensive web services testing for HTML, XML, SOAP, REST, and JSON. It provides functional, performance, compliance, interoperability and security testing with out-of-the-box support for OASIS and W3C standards.

Key Features

       Supports vulnerability tests with XSD-mutation.

       Provides comprehensive WSDL and Schema parsing.

       Performs load testing with behavior modeling and multiple simultaneous loading transactions.

       Provides reports in XML, DOC, XLS, PDF, RTF, and RPT formats.

       Integrates with HP Quality Center.

 

SOAtest is an enterprise-grade tool by Parasoft for testing and validating APIs and API-driven apps. It provides robust support for the functional unit, integration, security, simulation, mocking, compliance and load testing of technologies like REST, JSON, MQ, JMS, TIBCO, HTTP, and XML.

Key Features

       Provides end-to-end testing

       Supports 120+ protocols/message types.

       Comes with an easy-to-use interface.

       Helps create sophisticated, extensible and reusable tests without coding.

       Supports continuous integration testing.

 

 

TestMaker is an open source tool to test and monitor the performance of the web, web services and SOA application by PushtoTest. It runs on Jython (Python written in Java). TestMaker can repurpose Selenium tests, SoapUI tests, Sahi tests or any tests written in Groovy, Java, Python, PHP, Ruby and Perl into functional, load and performance tests.

Key Features

       Uses command-line prompt for functional, load and performance testing.

       Features an intuitive look and feel with a standard multi-windowed IDE.

       Provides a monitoring dashboard to run tests and display live results.

       Allows accessing all Java libraries and classes due to Jython language.

 

Postman is yet another API/ web services testing tool which comes with powerful HTTP client support. It has an easy-to-use request builder that allows you to write test cases and manage response data and response time for efficient testing and management of API test cases.

Key Features

       Allows collecting and organizing APIs in a feature called Postman Collections.

       Facilitates collaboration and sharing of API data and controls with the team.

       Comes with pasting text feature for hassle-free test creation on command line window.

       Allows writing Boolean tests within Postman Interface.

 

vRest is a tool exclusive for testing, mocking, and validation of REST APIS and web services. It also supports testing of web, mobile, and desktop applications that interact with third-party APIs or HTTP services.

Key Features

       Comes with a mock server functionality to create API mock within minutes.

       Provides a Chrome extension to record and play test cases.

       Supports integration with Jenkins for continuous server integration and Jira for bug tracking.

       Facilitates roles and permissions management.

       Allows exporting and importing test cases and reports from external tools such as Postman Collections, Swagger 2, and more

 

HttpMaster is another exclusive tool for REST web services testing. It helps testers to test the behavior of REST APIs and validate output data in formats like XML, JSON, and HTML.  With its universal HTTP tool, HttpMaster also helps developer simulate client activity and response behavior of an API application.

Key Features

       Comes with an easy-to-use and elegant user interface that doesn’t require advanced technical skills.

       Uses HTTP methods such as GET, POST, DELETE etc.

       Provides different validation types and expressions to ease testing.

       Utilizes command-line interface for test creation and execution

       Allows storing all information – API calls and project data at a single place.

 

Runscope is a simple tool to test and monitor the performance of the API. It helps you verify whether the web service or API returns the correct data and also prompts when things go wrong with the API. Runscope also supports API and backend service testing of mobile apps.

Key Features

       Allows creating tests with dynamic data for even complex cases.

       Displays visually-rich metrics and analytics to identify problems.

       Integrates with tools like HipChat, Webhooks, Slack and PagerDuty to notify when the APIs are down.

       Allows reusing and executing tests across multiple locations.

       Facilitates managing tests centrally for better team collaboration.

 

Rapise is a robust automation tool with powerful and extensible features. It is based on an open and flexible architecture for rapid functional testing of REST/SOAP web services. Rapise also provides support for testing web applications built in Java, .NET, Ajax, Silverlight, and Flash.

Key Features

       Uses HTTP standard methods such as POST, GET, PUT, and DELETE.

       Allows storing prototyped requests against a specific web service.

       Contains built-in REST definition builder and object library.

       Comes with powerful, integrated reporting capabilities.

       Supports cross-browser testing and parallel execution.

 

WebInject is a free tool for automated functional, acceptance, and regression testing of web and web services. It is a command-line tool and is based on Perl, which simplifies the execution of tests since it doesn’t require one to spend time at the command prompt. Further, it has no IDE like user interface which means, the tests are written outside of the WebInject UI. It can run on platforms that have Perl interpreter.

Key Features

       Provides real-time results display.

       Monitors system response time.

       Supports different usage – as a complete test framework and as a standalone test runner.

       Generates reports in HTML and XML formats.

       Allows integration with other system as a plugin for external monitoring.

 

Storm is another open source tool by CodePlex for testing web services written in Java or .NET. It currently supports only SOAP web service.

Key Features

       Allows testing multiple web services from a single UI.

       Helps edit raw SOAP requests.

       Allows invoking web service methods that contain complex data types.

       Supports testing of WCF apps.