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
|