Service

The OASIS SOA Reference Model states:

The noun “service” is defined in dictionaries as “The performance of work (a function) by one for another.”

Service in SoaML

A Service represents a feature of a Participant that is the offer of a service by one participant to others using well defined terms, conditions and interfaces.

Contract

• 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.

SLA

• ABA (Abandonment Rate): Percentage of calls abandoned while waiting to be answered
• ASA (Average Speed to Answer): Average time (usually in seconds) it takes for a call to be answered by the service desk.
• TSF (Time Service Factor): Percentage of calls answered within a definite timeframe, e.g. 80% in 20 seconds.
• FCR (First Call Resolution): Percentage of incoming calls that can be resolved without the use of a callback, or without having the caller call back the helpdesk to finish resolving the case.
• TAT (Turn Around Time): Time taken to complete a certain task.
• Uptime

ServiceContract in SoaML

• A ServiceContract is the formalization of a binding exchange of information, goods, or obligations between parties defining a service.
• A ServiceContract is the specification of the agreement between providers and consumers of a service as to what information, products, assets, value and obligations will flow between the providers and consumers of that service – it specifies the service without regard for realization, capabilities or implementation.

Services and Business Functionality

• Services Represent Business Functionality
• SOA is focused on business processes
• “natural” step of business functionality
• self-contained (explained later)
• business people should be able to understand what a service does

Interfaces and Contracts

• Service is an interface for messages that return information and/or change the state of an associated entity (backend)
• “interface-oriented architecture.”

Interfaces in SoaML

• Provides the definition of a service.
• Defines the specification of a service interaction as the type of a «Service» or «Request» port.

Business vs Technically Driven Interfaces

Technically Driven Interfaces

 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

Business Driven Interface

 createCustomer(name,    // new customer name
              address, // customer address
              account) // customer bank account
 readCustomer(id)        // customer id
 changeCustomerAccount(id,      // customer id
                     account) // new customer bank account
 changeCustomerAddress(id,      // customer id
                     address, // new customer address
                     check,   // true: verify address
                     modify)  // true: fix address if possible
 deleteCustomer(id)      // customer id

Service Attributes

• Do services have to be stateless?
• Do they have to be implemented as Web Services?
• Should they be coarse-grained and/or composable?

Coarse-Grained

• Services are abstractions that hide implementation details from the consumers
• The price for the abstraction is performance
• There is no clear definition of “coarse-grained” service

Visible/Discoverable

• Services must be searchable
• Usually there is some kind of catalogue and taxonomy (see UDDI)

Stateless

There is always some state involved

• Technical state
• Business state

Idempotent

• Whether we can call the service many times (for example in case of no response) without risking doing the thing twice
• Idempotency is the ability to redo an operation if you are not sure whether it was completed
• Changing status function may be ideponent
• SwitchStatus() versus setActive()

Reusable

• Avoiding redundancy is a general goal of software development
• Ideally each functionality should be implemented only once
• It may cause performance issue
• As a result, reusability may be a goal, but not a rule

Composable

• Services can use/call other services
• Discussed further in BPM section

Other attributes

• Technical (reusing the infrastructure)
• QoS- and SLA-Capable
• Pre- and Post-Conditions
• Vendor-Diverse
• Interoperable

Questions

• What does the “well-defined interface” or “contract” contain?
• What does a typical SLA contain?
• What does it mean composable?
• What does it mean idempotent?