Databases Reference
In-Depth Information
Functional services : Are used to implement raw business logic, for example,
business rules, pricing algorithms, and so on. It is quite common to embed
rules directly within task-based (or even entity) services, often leading to
the same rule being implemented in multiple locations and not always
consistently.
By separating out this logic as a standalone service, you not only ensure that
it's used in a consistent fashion, but also make it simpler to modify (that is,
you only have to do it once), thus increasing the agility of your solution.
Functional services typically don't use entity services (except maybe to
look-up reference values used by the algorithm); if you have a functional
service that does, then in reality, you have a task-based service with
functional logic embedded within it.
In many cases this may be fine. However, it will limit how reusable the
service is and could result in the same functionality being reimplemented
in other task-based services.
Task-based services : They are modeled to carry out a specific set of related
activities, often within the context of a business process. By their nature, they
will often act across one or more entity services, and may also make use of
other task-based or functional services.
For example, if we look at the operation placeBid , this would very much
form part of a task-based Auction service, as it supports the task of placing
a bid. However, it is likely to use an entity service (that is, Bid ) to store the
received bid in the underlying database, and it may use a functional service
(that is, AuctionEngine ) to calculate the result of placing the bid.
Service consumer
A key design point that needs to be considered is who will be consuming our
business services? It could be other business services, business processes, or an
external consumer such as the user interface layer, partners, or other parts of the
organization, though a service could potentially be called by all types of consumers.
Knowing who will call a service will impact on areas such as service granularity,
validation, and security.
Granularity is a key consideration in service design. Current industry wisdom
tends to encourage the use of more coarse-grained services, but it's important to
understand why when considering the granularity of an individual service.
Granularity is essentially the number of operations we need to call on a service in
order to achieve the desired result. The more fine-grained a service is, the more
operations you will typically need to call, the coarse-grained the less.
 
Search WWH ::




Custom Search