good afternoon
I am reviewing the concepts of SOA and I have this question.
SOA-> COVERS in 2 technologies, SOAP(xml) AND REST(xml,json,txt,etc)
Microservices that is based on SOA, uses SOAP or is only based on REST?
obs: if it is clear that the microservice goes by the level of decoupling, independence and only specific tasks, but my question is if I can have microservices based on SOAP?
I have read a lot of documentation, I have that doubt.
Thanks a lot.
Microservices are more of a concept/software architecture style where you have independently and scalable services.
If your organisation/project requires soap protocol (which often happens in legacy projects when you want to switch from soa to microservces) you can also do microservices with it.
Related
Is it good idea to separate out implementation of each http verb in different micro service?
For example
GET books/{id} - micro service A
POST books/{id} - micro service B
This appears to be overkill for "books" api but in a typical enterprise an api resource/verb do a lot more than a hello work api.
Is it good idea to separate out implementation of each http verb in
different micro service?
The boundaries of microservices are usually drawn by separable business concerns. The main reason to do that is for enabling separate teams to be responsible for the complete lifecycle of a service, with minimal external dependencies. This allows for a faster release cycle of services in a complex system.
For understanding the microservices architectural style I recommend reading the material from Martin Fowler.
The closest I got to finding the actual difference is this article.
But I didn't understand what would make me choose one over the other and if microservices can also use a REST API and communicate via http.
I mainly didn't understand what a microservice is and if it can come instead of a webservice, other than the purpose of
breaking large software applications into loosely coupled modules
A microservice is a software architecture, which can be implemented with webservices.
A webservice is just a technology (one of many) for providing services over "web" or HTTP.
The main point is: a web service is (as the name announces) something that you would expect to "deal" with HTTP - in other words it does something in the context of the world wide web.
Whereas a microservice is not subject to the WWW context. At its core a microservice is supposed to provide one specific service - but there is no restriction to the http protocol for example.
Often a microservice implements a restful "web service" - but it doesn't have to be that way!
Beyond that, microservices are often meant as counter model to a huge monolithic application that serves many different kind of requests.
I got simple answer here that says :
Microservices is a new software architecture. It is based on web services. But it can be any service implemented as an independent feature that has its own database and can be deployed independently.
Microservices is an architecture wherein all the components of the system are put into individual components, which can be built, deployed, and scaled individually.
Microservices are the extension of web services.
Web services are typically vertical in nature(Provider-Consumer communication) whereas microservices are horizontal in nature
Microservices are seen as architecture due to the following.
microservices have belonged to one specific application.
microservices are addressing specific concern so that can be said as lightweight.
Changes are isolated in nature because the change in one microservice doesn't affect other (Ex. Changes done in login microservice does not affect the payment microservice)
Scaling individual microservices are easy.
Microservice usually has its own database.
Microservices : -
Microservice is a software architecture that can be used alongside web services. This method involves the splitting of large software applications into decoupled modules where microservices run unique processes and communicate through APIs. Its development can be through the use of either messaging, event-driven APIs, or using non-HTTP backed RPC mechanisms.
Microservices architecture saves the day when large applications fail or are down. If a particular service fails in communication, the overall application cannot be affected by the failure of a single module. The combination of microservices in Java, C#, Python, and mobile software development languages is possible. It can be independently deployed in service models for a business domain.
Web Services :-
A web service is just one of several technologies that can provide services over “web” or HTTP. As a specific type of service-oriented architecture (SOA), web services represent a web application’s functionality.
It defines a mechanisms interaction between an API and the main code by using standard HTTP protocol and universal formats of data representation such as XML, JSON, and so on. This allows software applications developed by different technologies to communicate with each other.
Web services are not involved with frontend development. They are not connected to any development languages or user device software platforms. The combination of different web services into a single one is also possible if written in different languages and for separate operating systems, just like in microservices.
Microservice is a subset of web services. Also used to name Architectures like "Architecture based on microservices"
Microservice is an artifact, not an architecture. Several world class companies know that
https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environments-cfg-alb-shared.html
Before the microservice artifact, we had the classic web service or rest api. Even before this we had the Soap web services with XML.
So, as a summary when someone talk about microservice, he means a subset of web service with some characteristics that differentiate it from classic web services or rest api.
One main characteristic is a unique database or Database per Service
Here another characteristics from the goods like AWS. Some of them apply to rest apis or soap services. I will mark with bold some very specific for microservices.
https://aws.amazon.com/microservices/
Agility
Flexible Scaling
Easy Deployment
Technological Freedom
Reusable Code
Resilience
https://microservices.io/
Highly maintainable and testable
Loosely coupled
Independently deployable
Organized around business capabilities
Owned by a small team
https://www.baeldung.com/cs/microservices-db-design
Database per Service
CQRS
https://learn.microsoft.com/en-us/azure/architecture/microservices/design/data-considerations
Microservice is a piece of autonomous application that performs for a larger application architecture.
Web service is an approach to make the application available to other applications by web ui.
As per Service-Oriented Architecture (SOA) definition, an architectural style that supports service-orientation.
Does that mean only web services (SOAP and REST) are treated as part/backbone of SOA? What about messaging services?
No and yes.
A webservice can be designed in a service orientated way, but a "service" (SOA) describes functionality, a bundle of business logic.
Service orientated architecture means, you have different systems, different users, and the way you implement your business focuses on the whole beeing a service.
The former (SOA) is something abstract, a paradigm, a commitment on how to implement something, the latter is technology (REST, SOAP, ...).
In conjunction with webservices, the "how to" is often described using WS-Business Process Execution Language (short: BPEL). It is used to orchestrate providers and consumers and allows high-traffic processes to scale in the cloud.
Consider your bank, processing many business steps per second in a very standardized fashion; using standard services like transfering money from one account to another.
Talking about Java and JMS, Oracle has a tutorial up: This example shows the steps to create a simple JMS queue in WebLogic Server 11g for testing purposes.
The project I'm currently involved requires that business logic must be implemented in Web Service that will be consumed by the Presentation Tier Components (i.e. Web Applications).
The company has an Enterprise Service Bus, and up-to-date almost every Web Service developed is exposed through this bus. I asked some colleagues around about when to expose Service through ESB and I got this answers:
If there's an ESB, expose everything through it: There are several benefits like Load-Balancing and location transparency
If the ESB will only act as a Proxy -i.e no message transformation- just don't use it: You'll overload the ESB and lose performance. You'll better do a point-to-point connection.
You should expose a component through ESB if there's a protocol transformation (like exposing a Stored Procedure as a SOAP Service). If this isn't present you better go Point-to-Point.
So I'm curious if there's a general agreement or best-practice of when to expose a Web Service through it or not. Any reading/reference would be a great help.
From my point of view and after 4 years of experience with SOA technologies, using an ESB will always overload the system since you are adding a new layer and making all your communications go through it. Transformation (either messaging or protocol) and routing aren't to hard to accomplish without an ESB and point to point communication will have a bit higher throughput. Same happens also with business process automation, there are ways to get there without the need of an ESB.
In the other hand, the use of an ESB has several benefits in the scope of a corporation but it must be within a vision and strategy. One of the best examples is a company that has been working for a long time with a wide range of tools, each of them for a specific purpose and that made the company be distributed in teams which work in silos, ones isolated from the others. After a long time that makes interaction between teams complex and slow. A well planned SOA strategy will help to integrate all those tools and start replacing them for more meaningful lightweight items.
So, IMHO, Using an ESB just to solve a couple of "issues" in a single project without a corporate strategy isn't a good idea and, eventually, the word SOA will be banned in your company, when the problem isn't SOA by itself by rather the lack of vision and corporate strategy.
The only rule of thumb that I found regarding the use of ESBs is: The requirement of transformation, routing, business process automation (with or without human interaction), etc. in a single project is not a symptom of going SOA (almost every project has to perform transformations, routing and business process automation), but when those needs are the ones for a whole corporation then it's worth to think about it from a business point of view, never a technical one. If there isn't a business perspective, then SOA will fail.
This is a really wide topic and discussion can last for ages, I will suggest you a couple of links for further reading:
Some SOA Case Studies
Top 10 Reasons why SOA fails
I consider a self-described / auto-descriptive service as a good thing in a SOA architecture, since (almost) everything you know to call the service is present in the service contract (such a WSDL).
Sample of a non self-described service for me is Facebook Query Language (FQL http://wiki.developers.facebook.com/index.php/FQL), or any web service exchanging XML flow in a one String parameter for then parsing XML and performing treatments.
Last ones seem further more technically decoupled, since technically you can switch implementations without technical impact on the caller, handling compatibility between implementations/versions at a business level. On the other side, having no strong interface (diluted into the service and its version), make the service tightly coupled to the existing implementation (more difficulty to interchange the service and to ensure perfect compatibility).
This question is related to How to Implement Loose Coupling with a SOA Architecture
So, are self-described / auto-descriptive services loosely or tightly coupled in a SOA architecture ? What are the impacts regarding ESBs ?
Any pointer will be appreciated.
The thing is that loosely coupled SOA services will tend to interact with each other using publish/subscribe semantics not supported by WSDL (which only supports request/response).
When you introduce an ESB like NServiceBus, it focuses on messages and ownership rather than the method invocations that tools generate from WSDL. Those messages can then be represented either as classes in code or in an XSD for interoperability.
The transportation of XML messages from one endpoint to another when done with standard web services does look quite silly as the contract doesn't appear in the WSDL, and that's one of the places where ESBs come in.
Hope that helps.