Yes, I've read those
and that is what I'm working on implementing with protocol buffers
providing the means to translate messages, including event
notifications and database updates between systems that use
different languages/protocols or even different database types
such as MongoDB for key-value stores at the Microservice level
with relational SOA-level persistent datastores so that one is
not tightly coupled to any given solution stack. That's what I
meant by saying that this kind of interservice communication
will represent slightly smart pipes, but lighter weight and less
restrictive than ESBs, and perhaps without the need for API
Gateways, if they can be avoided. Whether that works out or not
remains to be seen.
Rex
On 2/18/2017 2:23 PM, Ken Laskey wrote:
See the NGINX Design and Deploy eBook and the microservices.io Event
link http://microservices.io/patterns/data/event-driven-architecture.html.
These discuss using events for synching data.
Ken
So far I haven't run across much in the
literature about notification of changes. Most of
what I've read so far seems to be more concerned
about the advantage of continuous delivery for the
programming team and the MSA owners. I think that
the rule of caveat emptor applies here. If you lose
a client's trust, it is hard to get it back, so we
all must have a care.
Cheers,
Rex
On 2/17/2017 1:08 PM, Ken
Laskey wrote:
My assumption in terms of
choreography is REST and HATEOAS. But, yes, that
requires coordination between the calling service and
the one being called, and this is often seen as done
through the UI. For example, a (micro)service
available through a mobile device takes a coffee order
and responds with a receipt that has a link to check
status and a link to cancel the order. The developer
of the receipt response needs to know that status and
cancel are available and the format of their
interfaces. Once that is set up, the team in charge
of the status microservice could change what was
displayed and maybe functionality — the receipt may
include accessing a coupon for a future purchase.
I think I noted elsewhere that SOA
always had the question of when it was allowable to
change a service without telling the consumer, and
that question remains with microservices. Sometimes
the change really is just cosmetic or just adds
optional benign behavior, but if I get a different
results this week from a service I used last week,
it may be important to know what caused the
difference.
Ken
I hope Ken meant that
each MS knows the next MS in the MSA
chain or ecosystem not the 'pipeline',
which I would prefer to reserve for the
devops development-deployment
pipeline--that automated continuous
delivery pipeline. But even then a MS
may have close choroeography-mediated
interservice communications with two to
(maybe) four other microservices.
An example could be
customer id <-> customer auth
<-> customer creditcheck <->
customer order ensemble which could each
be be connected to all of the others
mediated by a set of event-triggered
choreography rules hard-coded into their
interservice communications messaging.
Each microservice should have its own
mini-database riding along with each
instance with all of those [DB+MS]s
publishing their transactions up to
their persistent enterprise datastores
for updating to achieve the eventual
consistency we're so rightly concerned
about. Of course that choreography has
to be very well thought out and I would
guess that is what Martin is referring
to as another
infrastructure tool for choreography.
I agree that this "this
strongly suggest very close coordination
among the developers of the MS that make
up an app." I also agree with the rest of
Martin's comment, and this is exactly what
I'm working toward, through a slightly
smart protocol buffer pipe. The trick is
making its only smarts be the capability
of translating between different
application programming languages through
binary libraries. If it can do that, there
is more room for the kind of loose
coupling that obviates the danger of
contract/technology coupling, thus
allowing those different devops teams to
maintain their continuous delivery without
having to check with other teams or
account execs to go-between devops teams.
Yup, it'll be a neat trick if we can pull
it off.
Cheers,
Rex
On 2/16/2017
7:09 PM, Martin F Smith, BFC Consulting
wrote:
On 2/16/2017 9:59 PM, Ken Laskey wrote:
each
service knows the next service in the
pipeline and choreography is used for
control.
Umm . . knows how? Control by what?
Sounds like a reference to another
infrastructure tool for choreography.
Plus, this strongly suggest very close
coordination among the developers of the
MS that make up an app. On the one hand,
that's not surprising in that MSA seems
not to be aimed at re-use of a MS by
multiple application or across
enterprises. On the other hand, it seems
to undercut one of the "principles" we ran
across earlier, i.e., that MS lets each
development team operate very
independently. The statement above seems
to imply a significant body of shared
knowledge of the overall application and
agreement on constraints imposed by the
application's overall flow.
Martin
---------------------------------------------------------------------
To unsubscribe from this mail list, you
must leave the OASIS TC that generates
this mail. Follow this link to all your
TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
Rex Brooks
Starbourne Communications Design
Email: rexb@starbourne.com
GeoAddress:
1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: 510-898-0670
--
Rex Brooks
Starbourne Communications Design
Email: rexb@starbourne.com
GeoAddress:
1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: 510-898-0670
--
Rex Brooks
Starbourne Communications Design
Email: rexb@starbourne.com
GeoAddress:
1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: 510-898-0670
|