![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.](https://image.slidesharecdn.com/soainpractice-chapter03-services-130330094715-phpapp01/85/Lecture-3-Services-6-320.jpg)
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/