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
|