microservicesnginxsoaweb services
When I was reading about microservices on this site, I came across the below statement. What is meant by a canonical schema? Isn't it same as domain model?
The Microservices Architecture pattern also rejects other parts of
SOA, such as the concept of a canonical schema.
I would use a central, unified authentication system and have separate permissions/stats for each microservice (sort of like how I can't yet upvote on this stack exchange site but I can in stack overflow while using the central stack exchange authentication system). One of my current projects will involve this approach in the near future, which will be nice; the previous development work involved creating a HIPPA compliant system, necessitating a second level of authorization/authentication, and it is a time consuming annoyance to daisy chain authorizations from legally separate but functionally inseparable components of the system. The debugging process involves a lot less joy than a simple oauth login or an api with appid and x-auth headers.
Which to use depends upon the specific requirements of a development roadmap, but I would choose the simpler approach where possible to avoid excessive overhead and development time/effort.
Repeat after me:
REST and asynchronous events are not alternatives. They're completely orthogonal.
You can have one, or the other, or both, or neither. They're entirely different tools for entirely different problem domains. In fact, general purpose request-response communication is absolutely capable of being asynchronous, event-driven, and fault tolerant.
As a trivial example, the AMQP protocol sends messages over a TCP connection. In TCP, every packet must be acknowledged by the receiver. If a sender of a packet doesn't receive an ACK for that packet, it keeps resending that packet until it's ACK'd or until the application layer "gives up" and abandons the connection. This is clearly a non-fault-tolerant request-response model because every "packet send request" must have an accompanying "packet acknowledge response", and failure to respond results in the entire connection failing. Yet AMQP, a standardized and widely adopted protocol for asynchronous fault tolerant messaging, is communicated over TCP! What gives?
The core concept at play here is that scalable loosely-coupled fault-tolerant messaging is defined by what messages you send, not how you send them. In other words, loose coupling is defined at the application layer.
Let's look at two parties communicating either directly with RESTful HTTP or indirectly with an AMQP message broker. Suppose Party A wishes to upload a JPEG image to Party B who will sharpen, compress, or otherwise enhance the image. Party A doesn't need the processed image immediately, but does require a reference to it for future use and retrieval. Here's one way that might go in REST:
POST request message to Party B with Content-Type: image/jpeg201 Created response message to Party A with a Content-Location: <url> header which links to the processed imageContent-Location headerThe 201 Created response code tells a client that not only was their request successful, it also created a new resource. In a 201 response, the Content-Location header is a link to the created resource. This is specified in RFC 7231 Sections 6.3.2 and 3.1.4.2.
Now, lets see how this interaction works over a hypothetical RPC protocol on top of AMQP:
Do you see the problem here? In both cases, Party A can't get an image address until after Party B processes the image. Yet Party A doesn't need the image right away and, by all rights, couldn't care less if processing is finished yet!
We can fix this pretty easily in the AMQP case by having Party B tell A that B accepted the image for processing, giving A an address for where the image will be after processing completes. Then Party B can send A a message sometime in the future indicating the image processing is finished. AMQP messaging to the rescue!
Except guess what: you can achieve the same thing with REST. In the AMQP example we changed a "here's the processed image" message to a "the image is processing, you can get it later" message. To do that in RESTful HTTP, we'll use the 202 Accepted code and Content-Location again:
POST message to Party B with Content-Type: image/jpeg202 Accepted response which contains some sort of "asynchronous operation" content which describes whether processing is finished and where the image will be available when it's done processing. Also included is a Content-Location: <link> header which, in a 202 Accepted response, is a link to the resource represented by whatever the response body is. In this case, that means it's a link to our asynchronous operation!Content-Location header to determine if processing is finished. If so, Party A then uses the link in the async operation itself to GET the processed image.The only difference here is that in the AMQP model, Party B tells Party A when the image processing is done. But in the REST model, Party A checks if processing is done just before it actually needs the image. These approaches are equivalently scalable. As the system gets larger, the number of messages sent in both the async AMQP and the async REST strategies increase with equivalent asymptotic complexity. The only difference is the client is sending an extra message instead of the server.
But the REST approach has a few more tricks up its sleeve: dynamic discovery and protocol negotiation. Consider how both the sync and async REST interactions started. Party A sent the exact same request to Party B, with the only difference being the particular kind of success message that Party B responded with. What if Party A wanted to choose whether image processing was synchronous or asynchronous? What if Party A doesn't know if Party B is even capable of async processing?
Well, HTTP actually has a standardized protocol for this already! It's called HTTP Preferences, specifically the respond-async preference of RFC 7240 Section 4.1. If Party A desires an asynchronous response, it includes a Prefer: respond-async header with its initial POST request. If Party B decides to honor this request, it sends back a 202 Accepted response that includes a Preference-Applied: respond-async. Otherwise, Party B simply ignores the Prefer header and sends back 201 Created as it normally would.
This allows Party A to negotiate with the server, dynamically adapting to whatever image processing implementation it happens to be talking to. Furthermore, the use of explicit links means Party A doesn't have to know about any parties other than B: no AMQP message broker, no mysterious Party C that knows how to actually turn the image address into image data, no second B-Async party if both synchronous and asynchronous requests need to be made, etc. It simply describes what it needs, what it would optionally like, and then reacts to status codes, response content, and links. Add in Cache-Control headers for explicit instructions on when to keep local copies of data, and now servers can negotiate with clients which resources clients may keep local (or even offline!) copies of. This is how you build loosely-coupled fault-tolerant microservices in REST.
Best Answer
Apologies in advance for relying on the @ArseniMourzenko comment, but once I started to read the Wikipedia I immediately understood what Canonical Schema means.
Here OP's comment that focuses on the real doubt
Some data model yes, but seems that the article is referring to a "shared" or "common" data models between 2 or more services.
The Canonical Schema is a pattern meant to save services from in runtime data transformations. It also saves you from duplicating code. But you are then coupling your service to an external data model too.(See diagrams at the Wikipedia's page linked above)
It's a sort of common "language" between services.
So looks like the article is emphasising on the total independence of the MS from the "ecosystem" where it lives at.
Take for example the mention it does to ESB.
ESB usually demands an enterprise data model (messages) which is going to be common for everyone attached to the bus.
So, back to the article, seems that the author is pointing to the fact that MS rejects to be attached to any external system (and their constraints).