Lecture 3 - Services

1. Book Author: Nicolai M. Josuttis
Chapter Three: Services
IT-Slideshares http://it-slideshares.blogspot.com/

2. 3.1 Services (in SOA) definition
 A "Service" is (ideally) a self-contained, stateless
business function that accepts one or more requests
and returns one or more responses through a well-
defined, standard interface. Services can also perform
discrete units of work such as editing and processing a
transaction. Services should not depend on the state of
other functions or processes. The technology used to
provide the service, such as a programming
language, does not form part of this definition.

3. 3.1.1 Services Represent Business
Functionality
 Technically Driven Business Interface
 customerOP(action, // "create", "read", "change", "delete"
id, // customer id or null
name, // new customer name or null
address, // new customer address or null
account) // new customer bank account or null
 It is a business interface because it allows you to create a new customer, read or modify his/her data, or delete that data. However, this
interface is technically driven, probably by a direct mapping to a corresponding database interface.
 In contrast, a business-driven interface might look like this:
 createCustomer(name, address, account)
 readCustomer(id)
 changeCustomerAccount(id, account)
 changeCustomerAddress(id, address, check, modify)
 deleteCustomer(id) // customer id
 Note the following differences:
 Instead of having one signature, you have five. Each operation's name describes the basic functionality from a business point of view. In
addition, there are no parameters that do not make sense for each particular functionality (for example, for the deletion of a customer, you
only need the customer ID).
 Operations for reading and writing have different levels of granularity. In this case, you have the ability to change a customer's address or
bank account independently, but when you read customer data, you get both. Such differences are typical for business processes.
 Specific operations might have additional parameters. In this case, the operation for changing an address has additional attributes that
specify whether an address check should be performed and whether the address might even be modified according to the address check
(e.g., replacing "NewYork" with "New York").
 In fact, if you let business people design interfaces on a case-by-case basis, they'll look different from interfaces driven, for example, by the
underlying database design. Service orientation clearly prefers business-driven over technically driven interfaces, although this does not
mean that you should not think about possible synergy effects. Start the design based on the requirements, not based on the implementation.

4. 3.2 Interfaces and Contracts
 A service is an interface for (multiple) messages that return
information and/or change the state of an associated entity
(backend).
 SOA could be better named “Interface-oriented
architecture”.
 Interface should be well-defined
 Signature (input, output, possible exception)
 Contracts and QoS are non-functional commitments
 Message exchange patterns (MEPs)
 Notification/Escalation in change of States
 Peak hours handling

5. 3.3 Additional Service Attributes
 Attributes that “may”, “should”, “must” have
 Self-Contained Services (independent, autonomous) but still have some dependecies
 Coarse-grained services balance between dependencies and performance (OASIS SOA Reference
Model) – by building abstraction layer < slower runtime.
 Visible/Discoverable (where services are hosted)
 Stateless (where/how long the business states exists ? Is it technical or business )
 Idempotent (ability to redo or resend messages when in doubt of states)
 Reusable (performance vs. reusing same service – bottlenecks)
 Composable (use/call other services) leads to BPModeling
 Technical services (autonomous, QoS-enabled, vendor diverse, interoperability, discoverable, and
potential reusable services, implemented as web services)
 QoS and SLA-Capable (service contract runtime performance, reliability…etc)
 Pre- and Post-Conditions (specify the semantic behavior of services – designed by contract)
 Vendor-Diverse – large distributed systems  many vendors to provide platforms, middlewares …
 Interoperable (see def) – core requirement for SOA
 Implemented as Web Services
 Web Services might be an (obvious) way to implement SOA, but SOA as a concept is not tied to any
specific technology.

6. 3.3.1 Self-contained Services Def.
 A "Service" has a definition. This definition consists of:
 An explicit and detailed narrative definition supported by a low
(but not detailed [not implementation specific]) level process
model.
 A set of performance indicators that address measures/performance
parameters such as availability (when should members of the
organization be able to perform the function), duration (how long
should it take to perform the function), rate (how often will the
function be performed over a period of time), etc.
 A linkage to the organization's information model showing what
information the "Service" owns (creates, updates, and deletes) and
which information it references and is owned by other "Services."
 A listing of known downstream consumers (other "Services" that
depend upon its function or information) and the documentation
of their requirements.

7. 3.3.2 Coarse-Grained Services
 The noun "service" is defined in dictionaries as "The performance of work (a
function) by one for another." However, service, as the term is generally
understood, also combines the following related ideas:
 The capability to perform work for another
 The specification of the work offered for another
 The offer to perform work for another
 These concepts emphasize a distinction between a capability and the ability to
bring that capability to bear. While both needs and capabilities exist
independently of SOA, in SOA, services are the mechanism by which needs
and capabilities are brought together.
 ...
 The consequence of invoking a service is a realization of one or more real world
effects. These effects may include:
 information returned in response to a request for that information,
 a change to the shared state of defined entities, or
 some combination of (1) and (2).

8. 3.3.12 Interoperable
 From a business perspective, services are IT assets that
correspond to real-world business activities or
recognizable business functions and that can be
accessed according to the service policies that have
been established for the services.
 ...
 From a technical perspective, services are coarse-
grained, reusable IT assets that have well-defined
interfaces (a.k.a. service contracts) that clearly
separate the services' externally accessible interface
from the services' technical implementation.

9. 3.4 Summary
 Here is my summarizing definition of "service" in the context of SOA:
 A service is the IT realization of some self-contained business functionality.
 By focusing on the business aspects, a service hides technical details and allows business
people to deal with it.
 Technically, a service is an interface for (multiple) messages that are exchanged between
provider(s) and consumer(s).
 The complete description of a service from a consumer's point of view (signature and
semantics) is called a "well-defined interface" or "contract." A contract is agreed
individually between a certain provider, and a certain consumer, and usually includes
nonfunctional aspects such as SLAs.
 There are several attributes that services may (or, according to some definitions, must)
have. According to my understanding, they are situation-dependent; services will almost
always have different attributes, and should be classified according to those attributes.
IT-Slideshares http://it-slideshares.blogspot.com/