Meeting Minutes 2017 05 19
- Reference Architecture
- Goals
- Principles
- Practices
- Layers
- Potential Open Source Components
- Enable fine-grain modularity
- Promote reusability
- Promote interoperability
- Promote innovation
- Support migration path
- Establish trust framework for nationwide information exchange
-
possible?
- Something we should strive for
-
possible?
-
All data and functionality should be exposed through APIs
- Replace APIs with "service-oriented APIs"
- Standardize service boundaries (e.g. APIs), not internals
- Focus on data standards and resource definitions
- All service APIs must be designed to be able to expose the interface to the outside world
- Even if that is not the immediate intent
- Hide internal implementation details through APIs
- Keep APIs technology agnostic
- It doesn’t matter what technology is used in the service
- Make services simple for consumers
- Easier to use and replace
- Must be transparent and reusable
- Must use open standards
- (new) Public APIs shall be documented
- Services should strive to be small and do one thing well
- Services should be loosely coupled and have bounded contexts
-
Service APIs should be RESTful and stateless
- Needs further review - add SOAP?, legacy migration?
- API response codes must be correct and meaningful
-
Strive toward one data standard and set of resource definitions for each type of data
- Support no more than two
- More thought needed on this - will address again next week
- Smart endpoints and dumb pipes
- Open source with permissible license (e.g. Apache 2.0)
- Communication / Messaging
- Apache Kafka, RabbitMQ
- Registration / Discovery
- Consul, Hyperbahn, ZooKeeper
- Load Balancing
- AWS Elastic Load Balancer, Netflix Eureka, HAProxy, Nginx
- Security
- Heart Working Group, Argonauts, OAuth2, OpenID Connect, User Managed Access (UMA, Kantara), SAML