Web Services

WSDL Documents

An WSDL document describes a web service. It specifies the location of the service, and the methods of the service, using these major elements:

Element	Description
<types>	Defines the (XML Schema) data types used by the web service
<message>	Defines the data elements for each operation
<portType>	Describes the operations that can be performed and the messages involved.
<binding>	Defines the protocol and data format for each port type

SOAP - (Simple Object Access Protocol)

SOAP - Message Structure

A SOAP message is an ordinary XML document containing the following elements −

Envelope − Defines the start and the end of the message. It is a mandatory element.

Header − Contains any optional attributes of the message used in processing the message, either at an intermediary point or at the ultimate end-point. It is an optional element.

Body − Contains the XML data comprising the message being sent. It is a mandatory element.

Fault − An optional Fault element that provides information about errors that occur while processing the message.

SOAP vs REST

SOAP (Simple Object Access Protocol) and REST (Representational State Transfer) are both web service communication protocols. SOAP was long the standard approach to web service interfaces, although it’s been dominated by REST in recent years, with REST now representing more than 70% of public APIs according to Stormpath. Understand the primary differences between SOAP vs. REST and how each can benefit your organization’s goals.

REST - REpresentational State Transfer

REST, or REpresentational State Transfer, is an architectural style for providing standards between computer systems on the web, making it easier for systems to communicate with each other.

REST is an architectural style, or design pattern, for APIs.

REST was defined by Roy Fielding, a computer scientist. He presented the REST principles in his PhD dissertation in 2000.

SOA

Service-oriented architecture(SOA): an architectural pattern in computer software design in which application components provide services to other components via a communications protocol, typically over a network.

Microservices

Microservices: a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs

The microservice architectural style involves developing single applications that can work together as a suite of small services, each running in its individual process and communicating with lightweight mechanisms such as an HTTP resource API. These services require bare minimum centralized management, use different data storage technologies, and can be written in different programming languages. These services, built around business capabilities, can also be deployed independently by machinery that supports fully automated deployment.

Microservices vs SOA

• The typical service oriented architecture (SOA) model usually has dependent enterprise service buses (ESBs), with microservices using faster messaging mechanisms.
• While SOA focuses on imperative programming, the microservices architecture uses a programming style that focuses on a responsive-actor as its base.
• While SOA models usually have an outsized RDBMS, microservices frequently use databases such as NoSQL or micro-SQL that can be connected to conventional databases.
• That said, the real difference lies in the architecture methods that are used for creating an integrated set of services.

Testing Microservices

A microservices architecture consists of focused, small services that together create a complete application or task. Every instance of a microservice represents a single responsibility within your application. The real advantage is that, these services are independent of one another, which makes them independently deployable and testable.

Unit Testing

The scope of unit testing is internal to the service. In terms of volume of tests, they are the largest in number. Unit tests should ideally be automated, depending on the development language and the framework within the service.

Contract Testing

Contract testing should treat each service as a black box and all the services must be called independently and their responses must be verified. Any dependencies of the service must be stubs that allow the service to function but do not interact with any other services. This helps avoid any complicated behavior that may be caused by external calls and turn the focus on performing the tests on a single service.

A “contract” is how a service call (where a specific result or output is expected for certain inputs) is referred to by the consumer-contract testing. Every consumer must receive the same results from a service over time, even if the service changes. There should be the flexibility to add more functionality as required to the Responses later on. However, these additions must not break the service functionality. If the service is designed in this manner, it will stay robust over longer durations and the consumers will not be required to modify their code to take into account the changes made later on.

Integration Testing

Verification of the services that have been individually tested must be performed. This critical part of microservice architecture testing relies on the proper functioning of inter-service communications. Service calls must be made with integration to external services, including error and success cases. Integration testing thus validates that the system is working together seamlessly and that the dependencies between the services are present as expected.

End-To-End Testing

End-to-end testing verifies that the entire process flows work correctly, including all service and DB integration. Through testing of operations that affect multiple services ensures that the system works together as a whole and satisfies all requirements. Frameworks like JBehave help automate Functional testing by taking user stories and verifying that the system behaves as expected.

UI/Functional Testing

User interface testing is the testing of the highest order as it tests the system as an end-user would use it. Testing of this level must feel like a user trying to interact with the system. All the databases, interfaces, internal and third-party services must work together seamlessly to produce the expected results.

ESB - Enterprice Integration Design Pattern

Enterprise Integration Design Pattern(EIP) focuses on messaging patterns for enterprise application integration (EAI). Messaging makes it easier for programs to communicate across different programming environments (languages, compilers, and operating systems) because the only thing that each environment needs to understand is the common messaging format and protocol.

Messaging patterns define the means by which different elements in a message-passing system connect and communicate to enable interaction among objects within programs and among various types of software -- which may be written in different languages and exist on different platforms in multiple locations.[1]

First of all we should define EIPs and why we should use them. As the name implies, these are tested solutions for specific design problems encountered during many years in the development of IT systems. And what is all the more important is that they are technology-agnostic which means it does not matter what programming language or operating system you use. Patterns are divided into seven sections:

• Messaging Systems,
• Messaging Channels,
• Message Constructions,
• Message Routing,
• Message Transformation,
• Messaging endpoints,
• System management.