OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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

On Feb 17, 2017, at 1:14 AM, rexbroo <rexb@starbourne.com> wrote:

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 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]