Re: [soa-rm] Re: more on API Gateways

[rexbroo <rexb@starbourne.com>]

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