Web Services - Revision history

Rasimsen at 00:06, 27 November 2018

2018-11-27T00:06:22Z

Rasimsen at 12:03, 21 July 2018

2018-07-21T12:03:48Z

Rasimsen: /* SOAP vs REST */

2018-07-21T12:00:18Z

‎SOAP vs REST

Rasimsen at 11:28, 21 July 2018

2018-07-21T11:28:45Z

Rasimsen at 11:21, 21 July 2018

2018-07-21T11:21:55Z

Rasimsen at 11:31, 11 July 2018

2018-07-11T11:31:04Z

Rasimsen: /* Microservices */

2018-07-03T00:18:19Z

‎Microservices

Rasimsen: /* SOA */

2018-07-03T00:17:26Z

‎SOA

Rasimsen at 00:03, 3 July 2018

2018-07-03T00:03:42Z

Rasimsen: /* ESB - Enterprice Integration Design Pattern */

2018-06-27T09:41:49Z

‎ESB - Enterprice Integration Design Pattern

← Older revision		Revision as of 00:06, 27 November 2018
Line 49:		Line 49:

	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'''.		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'''.
		+
		+	===[[API Gateway]]===
		+	The API Gateway '''encapsulates the internal system architecture and provides an API''' that is tailored to each client. It might have other responsibilities such as '''authentication, monitoring, load balancing, caching, request shaping and management, and static response handling'''.
		+

	==Microservices vs SOA==		==Microservices vs SOA==

← Older revision		Revision as of 12:03, 21 July 2018
Line 101:		Line 101:
	===[[Mule ESB]]===		===[[Mule ESB]]===
	===[[WSO2 ESB]]===		===[[WSO2 ESB]]===
		+
		+	==SSL - Secure Sockets Layer ==
		+	Secure Sockets Layer - SSL certificates have a key pair: a public and a private key. These keys work together to establish an encrypted connection. The certificate also contains what is called the “subject,” which is the identity of the certificate/website owner.
		+
		+	To get a certificate, you must create a Certificate Signing Request (CSR) on your server. This process creates a private key and public key on your server. The CSR data file that you send to the SSL Certificate issuer (called a Certificate Authority or CA) contains the public key. The CA uses the CSR data file to create a data structure to match your private key without compromising the key itself. The CA never sees the private key.

@@ Line 25: / Line 25: @@
 ==[[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.
+'''SOAP (Simple Object Access Protocol)''' and '''REST (Representational State Transfer)''' are both web service communication protocols.
 ==REST - REpresentational State Transfer==

@@ Line 11: / Line 11: @@
 </source>
-==[[SOAP]]==
+==[[SOAP]] - (Simple Object Access Protocol)==
 ===SOAP - Message Structure===
 A SOAP message is an ordinary XML document containing the following elements −
@@ Line 24: / Line 24: @@
+==[[SOAP vs REST]]==
@@ Line 33: / Line 34: @@
 REST was defined by '''[[Roy Fielding]]''', a computer scientist. He presented the REST principles in his PhD dissertation in 2000.
 ==SOA==

← Older revision		Revision as of 11:21, 21 July 2018
Line 25:		Line 25:


−	~~==[[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.[https://whatis.techtarget.com/definition/Enterprise-Integration-Patterns-EIP]
−
−	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.

−	~~===[[Mule ESB]]===~~
−	~~===[[WSO2 ESB]]===~~

	==REST - REpresentational State Transfer==		==REST - REpresentational State Transfer==
Line 89:		Line 71:

	http://connect.cd/wp-content/uploads/2017/09/Test%C2%B2-768x671.png		http://connect.cd/wp-content/uploads/2017/09/Test%C2%B2-768x671.png
		+
		+
		+
		+	==[[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.[https://whatis.techtarget.com/definition/Enterprise-Integration-Patterns-EIP]
		+
		+	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.
		+
		+	===[[Mule ESB]]===
		+	===[[WSO2 ESB]]===

← Older revision		Revision as of 11:31, 11 July 2018
Line 45:		Line 45:
	===[[WSO2 ESB]]===		===[[WSO2 ESB]]===

		+	==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==		==SOA==

← Older revision		Revision as of 00:18, 3 July 2018
Line 50:		Line 50:

	==Microservices==		==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'''.		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'''.

← Older revision		Revision as of 00:17, 3 July 2018
Line 47:		Line 47:

	==SOA==		==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==

← Older revision		Revision as of 00:03, 3 July 2018
Line 44:		Line 44:
	===[[Mule ESB]]===		===[[Mule ESB]]===
	===[[WSO2 ESB]]===		===[[WSO2 ESB]]===
		+
		+
		+	==SOA==
		+
		+	==Microservices==
		+	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.
		+
		+
		+	http://connect.cd/wp-content/uploads/2017/09/Test%C2%B2-768x671.png

@@ Line 27: / Line 27: @@
 ==[[ESB]] - Enterprice Integration Design Pattern==
-Editing 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'''.
+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.[https://whatis.techtarget.com/definition/Enterprise-Integration-Patterns-EIP]