| Thanks, Rex. Too much to read for one person, so I look forward to your processing.
One thing when Bob Natale and I spoke with NGINX was they agreed that berating SOA by holding up the Web Services paper tiger was inaccurate because it ignores the whole community that argued for RESTful interfaces from day one. And a lot of people who understood this already argued for tooling that provided the sparse functionality that you needed rather than the expensive behemoth you’d likely underuse.
Also, re the canonical schema, (1) you need to declare the schema (or other vocabulary representation) you are using or you can’t have confidence that you understand what the incoming message is asking you to do or the outgoing message is telling you what happened, and (2) you can almost guarantee failure in coming up with the one true schema, et al, that would satisfies everyone’s needs.
Finally, be careful with “The API Gateway ... provides each of the application’s clients with a custom API.” This gets to the Netflix architecture we discussed several weeks ago. There seems to be need for a teasing out of what constitutes an appropriate generic interface vs. one that gets unwieldy because it tries to do too much vs, the other end of the spectrum where you get a proliferation of interfaces that become unmanageable. Throw in a concern for chattiness for a little extra icing on the cake.
Got to run now.
Ken
P.S. Also to read the link you provided.
------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
This topic led me to
yet more reading, specifically NGINX articles supporting their
API Gateway product line. In their Introduction to
Microservices, https://www.nginx.com/blog/introduction-to-microservices/?utm_source=building-microservices-using-an-api-gateway&utm_medium=blog
they say this: ... On the
surface, the Microservices Architecture pattern is similar to SOA.
With both approaches, the architecture consists of a set of
services. However, one way to think about the Microservices
Architecture pattern is that it’s SOA without the
commercialization and perceived baggage of web
service specifications (WS-*) and an Enterprise
Service Bus (ESB). Microservice-based applications favor simpler,
lightweight protocols such as REST, rather than WS-*. They also
very much avoid using ESBs and instead implement ESB-like
functionality in the microservices themselves. The Microservices
Architecture pattern also rejects other parts of SOA, such as the
concept of a canonical schema..."
I don't recall specifying WS-* or a canonical schema, but I did
find their decomposition of the Microservices Architecture in
their diagrams quite apt. However, since the the following article
in their series, Building Microservices Using an API Gateway, https://www.nginx.com/blog/building-microservices-using-an-api-gateway/
concludes that
"...For most microservices‑based applications, it makes sense to
implement an API Gateway, which acts as a single entry point into
a system. The API Gateway is responsible for request routing,
composition, and protocol translation. It provides each of the
application’s clients with a custom API. The API Gateway can also
mask failures in the backend services by returning cached or
default data...." I suspect that API Gateways are very much like
ESBs were. I have yet to read all of their articles, but I look
forward to reading Event-Driven Data Management for Microservices
https://www.nginx.com/blog/event-driven-data-management-microservices/?utm_source=building-microservices-using-an-api-gateway&utm_medium=blog
Rex
On 11/23/2016 11:55 AM, Martin Smith wrote:
Ken, Rex, Mike, and all-- Didn't get a chance to
bring this up today but maybe we can discuss next time . ..
This was also partly in response to Mike's comment that he
believes that in Microservices API interfaces are
typically/often exposed directly to end-users vs only to other
MS components within an application container.
Martin
--
Martin F Smith, Principal
BFC
Consulting, LLC
McLean,
Va 22102
703
506-0159
703
389-3224 mobile
--
Rex Brooks
Starbourne Communications Design
Email: rexb@starbourne.com
GeoAddress:
1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: 510-898-0670
|