Service

From Training Material
Revision as of 18:44, 8 November 2012 by Izabela Szlachta (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


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.

Soa-service-soaml.jpg


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

Soa-servicecontract.png

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

Soa-interfaces-soaml.png


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?