Hi Chaps,
For the Consumer Driven Contracts - 1) contracts with whome - Service Providers? Yes, it is possible and widely used in the Private Cloud and its variations. It is also obvious that such model of consumer-provider is not scalable at all. Also, this model is suitable for 'collaboration' where the Service Provider is ready to tune/modify existing service to the consumer needs. I think that this model is an anti-service model and can exist at the level of capabilities only: you have a problem with water in the bath and you call a plumber; the latter has no clue what he will be doing - changing a filter or diffing a whole to het to the pipe... and when he is busy with one consumer/customer, he cannot service others.
For the Newman's example - this "wonderful" example was addressed 10 years ago and SOA Services had Identified a type of Data Access Service that time. The Data Access Service (DAS) shilelds all other services from the access to the shared databases, but it is not only a DB Driver-on-steroids; the duties of such Service (and this is why it is the Service) are in working with the databases/sources schemas and mapping them to the data schemas used by the Services-consumers. Also, the DAS is responsible for the performance, relaiability of the DB connections, concurrency and stability. Thus, nobody needs to know about not only the shared database, but even where the DAS has got the data from. The DAS pattern, if you want, is usually coupled with a Mediation or Registry patterns, i.e. the ones that take care of what data is stored where.
IMHO, a SOA Service should know and care only about the data schema it uses/needs/works with. This is what it request from DAS and offers to its consumers.
If a SOA Service would be directly linked with a shared database, this will result in 1) inter-service coupling by implementation; 2) violations of a few SO Principles including Composability because such Service would be dependent on uncontrolled resource and may not ne easility participate in multiple compositions at ones as may be needed.
Cheers,
- Michael
Sent: Saturday, August 26, 2017 at 9:17 PM
From: "Ken Laskey" <klaskey@mitre.org>
To: soa-rm@lists.oasis-open.org
Subject: [soa-rm] interesting microservices video
This is another Sam Newman conference talk, but I think a fairly good one. I’m passing it around for a couple reasons:
1. One of his principles focuses on Consumer Driven Contracts, and I couldn’t help but think of points of concern to Michael. Are there elements of a solution here?
2. Tight vs. loose coupling. In the SOA-RM, we basically said this was a red herring because it was a buzzword with no useful definition nor useful examples. Newman provides a good example.
- Tight coupling: access data elements through use of s common (integration) database. To do this, everyone has to be exposed to all the implementation (e.g. schema) details.
- Loose coupling: access data element(s) you want/need through an API without exposing implementation details (e.g. data elements for which you have no interest).
Talk with you on Wednesday.
Ken
------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S H330 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-7996
McLean VA 22102-7508