www.s-cube-network.eu

VU University Amsterdam (VUA),

Patricia Lago

S-Cube Learning Package

Service Identification

Learning Package Categorization

S-Cube

Service Engineering and Design

Service discovery and identification

Service Identification

Learning Package Overview

Problem Description

Service Identification Method

Summary

Problem Description

Q) How to identify services out of requirements

– How to guide the reasoning to identify candidate services

out of requirements

– What modeling methods can help such analysis

Italian restaurant analogy: Understanding Basic Concepts

– Restaurant provides food: a service

– After the order is taken, food is produced, served, …: service may

consist of other services (service composition)

– The menu indicates the service provided: a service description (contract)

– The order is written down, or yelled at the cook: services communicate

through messages

Main ingredients

– Services ⇒ functionality

– Service contracts ⇒ qualities (e.g. reliability, security, performance),

other non-functional properties (e.g. platform characteristics, legal

constraints), tacit design decisions (e.g. insurance companies might

assume 1st January = starting date of policy contracts)

– Messages ⇒ properties of data exchanges (e.g. data structures,

protocols)

Other example: on services

– Municipality supporting the citizen in looking for an apartment:

- Check personal data ⇒ service (of provider) X

- Check tax history ⇒ service (of provider) Y

- Check credit history ⇒ service (of provider) Z

- Search rental agencies ⇒ services (of providers) A, B

- …

Other example: on messages

Order

processing

Place order

E-payment

Delivery

basket info

basket info

credit card data

sync

status update

status

update

sync

Learning Package Overview

Problem Description

Service Identification Method

Summary

Terminology /1

Conceptual service

– service that is not yet implemented (implementation agnostic), can be either a

software service or not

Service candidate

– conceptual service identified during analysis and candidate for design

Service operation candidate

– a service operation identified from functional requirements; it might become a service

candidate itself, or be composed (i.e. aggregated) in a (more complex) service

candidate

Business service

– is an (ideally) self-contained, stateless business function that accepts one or more

requests and returns one or more responses through a well-defined, standard

interface.

– During service identification, the elicited business services become the service

candidates of the design phase. They might be service operation candidates.

Terminology /2

Service types

– task service

– entity service

– utility (or infrastructure) service

– (hybrid service - mix of task and entity)

Atomic service vs. Composed service

Track

delivery

Manage

Basket

E-payment

Place order

T

E

U

H

Terminology /2 exemplified

task service

entity service

utility (or infrastructure) service

(hybrid service - mix of task and entity)

?

?

?

?

Assign

nurse

Arrange

transport

Inform family

doctor

Inform local

social services

Inform

patient ?

What are the service types here?

Service Oriented (SO) analysis

The process of determining how

business requirements can be

represented through services

The process of modeling a

service inventory and/or reusing

it to compose a service oriented

application

Service oriented

analysis

Service oriented

design

Steps of SO analysis

1. Identify business services and service operation candidates

– from the target business domain: this can be the list of functional requirements (top-down

development) or directly the list of provided business functions

– from functional models of pre-existing systems (SO migration)

2. Model service candidates

– aggregate service operation candidates into service candidates

- to do so, recognize overlaps (see next slides)

UML activity diagrams (behavior), UML use case diagrams (decomposition); UML class

diagrams (data)

Steps of SO analysis

Service operation

candidates

Service candidates

(self-contained)

A) gluing service operations to define self-contained business logic

Service modeling guidelines

Task service candidates

– reusability of common business logic across different processes

B) reusability of common business logic across different processes

Service modeling guidelines

Task service candidates

– reusability of common business logic within

a process

Order Fulfillment Process - running example

Step 1: Identify service candidates

(XML -> native format)

(currently custom

component)

service candidate

(into accounting system)

(currently custom legacy)

service candidate

(to accounting clerk's

work queue)

service candidate

same

as previous

same

as previous

PO

processing

service

(task

service)

Step 2: Model service candidates - excerpt

PO processing

service

Receive PO

document

Validate PO

document

(If PO document is

invalid)send rejection

notification (and end

process)

Transform PO document

into native electronic PO

format

<<include>>

<<include>>

<<include>>

<<include>>

...

Model service candidates: business process logic

Not service operation candidates (from the Order Fulfillment

Process example):

– if PO document is valid, proceed with the step “transform PO document”

– if the PO document is invalid, “end process”

This belongs to the respective task services

Model service candidates: data model

Summary of SO analysis diagrams

identify business services and service operation candidates

– UML activity diagrams

model service candidates

– UML use case diagrams (task services)

– UML class diagrams (entity services)

Learning Package Overview

Problem Description

Service Identification Method

Summary

Summary of Service Identification Method

Step 1: Business service identification.

– The business services are elicited by means of business process

models and conceptual data models.

– These two models can be determined either from functional models of

pre-existing systems (i.e. bottom-up SOA migration), or from the target

business domain, as the list of functional requirements (i.e. top-down

service development).

– Conceptual data models, instead, facilitate identification of the

business services addressing the functionality of business entities

Step 2: Business service decomposition.

– Given the identified business services, this step elicits the candidate

services and their constituent service operations.