F6 Flashcards
Förklara Discoverability
Provide support for a searchable registry of services, this is sometimes referred to as a
“Service catalog”,
Let the developers retrieve service interface descriptions via the registry/catalog. Make
it easy to discover and connect to services.
Sometimes the existing/running services in an organisation is referred to as a service
inventory.
Förklara Composability
Design services such that they can be used together!
As more services are built, add them to the inventory/registry/catalog (see
discoverability principle).
Use some basic design methods:
– Create basic services for common concepts (customers, orders)
– Create process services to mirror common business processes
Förklara Autonomy
The services should share as few resources as possible – to avoid failure in one
resource to affect the other services
Förklara Abstraction
Hide all information that is not absolutely required to use the service.
Functional: Operations/methods
Programmatic: How the service carry out the work
Technology: The technology that are being used to implement the service
Förklara Loose coupling
”Loosen up” the dependencies between interconnected services. This can be achieved in several ways, for example:
Physical decoupling - do not “hardcode” connections between services - lookup service
addresses instead.
Asynchronous messaging - Use asynchronous calls instead of synchronous, otherwise
the system might become unresponsive while waiting for a response.
Standards - Use standard interconnection techniques (XML, HTTP, SOAP,…) that are
independent of vendors
Interface design - Do not let technologies affect the methods and messages structure
of the service – See also the Abstraction principle
Förklara Statelessness
Stateless means there is no record of previous interactions and each interaction request has to be handled based entirely on information that comes with it.
Remove internal state to make the services stateless. This usually makes the service
scalable = able to handle many concurrent requests
Förklara service design problem BDUF
Big Design Up Front
(SOA can be ”Counter agile” according to [Erl16])
How do we know which service features/properties to invest in? – If we don’t know we
will waste money.
Förklara service design problem Cost
Förklara de technical contract
Description of the service methods/operations (WSDL = Web Service Description Language)
Description of the information structures that the service use
(XML Schema)
Basic rules, governing that parameters etc are used correctly
(WS Policy = A standard describing requirements on services.)
Förklara de Business contract
SLA – Service Level Agreement, General rules on useage, for example up-time, performance
Vad är design-by-Contract (DbC)
The central idea of DbC is a metaphor on how elements of a software system collaborate
with each other, on the basis of mutual obligations and benefits. The metaphor comes from business life, where a “client” and a “supplier” agree on a “contract” which defines for example that:
- The client must pay the fee (obligation) and is entitled to get the product (benefit).
- The supplier must provide a certain product (obligation) and is entitled to expect that
the client has paid its fee (benefit).
When using software modules, such as services, the obligation can be seen as a precondition and the benefit as a post-condition for service use.
Vad är de centrala principer för microservices?
Autonomy: each micro service manages its own database.
Composability: make is easy to send request and receive
responses from microservices
Statelessness: … for scalability
