more implementations can have one common interface
a service is defined from different points of view (no universal definition):
business view: a service is a components that provides value to a service customers
conceptual view: component that serves as black box, could be reused, has loose coupling etc.
logical view: service has interface, description, implementation
software architecture view: we have two main kinds of services:
business/application service - exposes functionality of an application
middleware service - provides internal support, processing of requests etc.
technical view:
which technologies are being used (REST, GraphQL, SOAP, gRPC, WebSocket etc.)
my words:
It’s a standalone component that provides a certain functionality. It has an interface which is a set of instructions on how to use it. We can have more implementations of the service, but all of them have to share the same interface.
RESTful service means that the service interface conforms to the REST rules and uses HTTP protokol
architecture of enterprise systems, where a service is the base building block
serviced are integrated together to form business functionalities
Integration
when working in enterprise systems, we have to make sure that all applications are able to communicate with each other
with integration, we aim to “integrate” them all together, so they can easily exchange data, functions, information etc.
interoperability = an ability of two or more applications to understand each other
types of integration:
one-to-one integration = each service/application talks to all other services/applications separately
multiple protocols problem, multiple vendor problem, very chaotic, difficult to maintain
many-to-many integration = uses middleware (Enterprise service bus) as central integration technology
this is an example of Service Oriented Architecture (SOA)
all apps communicate with the central middleware, which mediates the communication between the apps
data transformation can get messy within ESB (spagetti code) - no universal solution exists today
another types of integration:
data-oriented integration - apps could access database of other applications directly using SQL and knowing it’s structure and complexity
it has complexity and integration problems
use case for ETL (Extract, Transform, Load) operations between applications
service-oriented integration - happens on the application level, implementation details are hidden behind interfaces, only exposed interfaces are available
data exchange is limited to defined input/output objects
Integration patterns for ESB
message broker - handles different multiprotocol messaging between services and clients
location transparency
the location of individual services can be changed
ESB can reroute clients (clients don’t have to know the exact locations of services)