7083T - Service Oriented Architecture

Week 6 – Topic 07
Design Service Interface
0815.1335.7316 WA
suryadi@binus.edu
D1026
• An Enterprise Service Bus (ESB) implements a communication system between
mutually interacting software applications in a service-oriented architecture.
Customer Management,
Marketing, Pricing, Logistic

Account Service, Loan Service,

Credit Service, Other services
Department of Motor Vehicles.
Service Characteristic
A service provides capabilities that
are accessed through its interface.
The interface describes how those
capabilities are presented and the
rules and protocols for using them.
The service is implemented
through a variety of mechanisms,
such as components, composition,
and integration.
 Characteristics in the design of service interfaces.
Three characteristics of services are particularly important
in the design of service interfaces.

8
05/03/2021 Unit 1
 Granularity
• Service granularity describes the amount of business
functionality performed by a single interaction
(message exchange) with a service operation.
• Often, larger services are created by combining
multiple smaller services. In addition to distribution
and data, it is important that the granularity of a
service interface match the functional modularity
of the expected service consumers.

9
05/03/2021 Unit 1
 Large
Granularity

Small

Business process expects to call services with granularity that corresponds to that of a
process activity.
Source : Applied SOA, Mike Rosen
Integration Service Pattern
 Visibility

• Visibility describes the range of users that are

allowed to see the existence of a service, and
subsequently to use it.
• Visibility is often described as either public or
private.
– Public visibility means that all users within the
intended scope are able to see the service.
– Private means that the service is not discoverable, but
rather must be known about a priori. 12
05/03/2021 Unit 1
 Scope
• Scope describes the intended range of users of a service.
• The largest scope is enterprise-wide, meaning that the
service is intended to be used across the enterprise or
across organizational boundaries.
• A smaller scope, such as a single solution, means that the
service is intended to support only a specific solution.
• The importance of scope is that it
provides the context within which
the service interface must be defined,
specifically regarding the scope of
responsibilities and information
13
05/03/2021 Unit 1
 Style Interaksi
• Parameter Response = service operation (parameter1, parameter2, ...);
• Dokumen Response document = service operation (request document);
• Data Response data = get operation (entityID);

• Request and Reply

Style Request and Reply

 Design Guideline
The primary design principles for services.
• Isolating Responsibilities Loose coupling
is important in reducing dependencies
between services so that they can be
used in different scenarios or to isolate
the effects of changes.
• The order-processing service coordinates
all of these activities and then uses
other services to help accomplish the
order processing. So, obviously, the order-
processing service is dependent on
(coupled to) the customer service,
inventory service, and billing
Sourceservice.
: Applied SOA, Mike Rosen
18
05/03/2021 Unit 1
 Design Guideline

• Understanding Overall Context, To achieve these goals

within the intended scope of the SOA you must
understand more than a single process, scenario, or use
case. You must understand the overall context to which
the SOA applies. The overall set of services within this
context is referred to as the service inventory.

19
05/03/2021 Unit 1
 Design Guideline
Understanding Overall Context, The SOA business model asks
and answers the following questions:
• What business are you in?
• What are the goals and objectives of this particular business?
• What outcomes are needed to achieve those goals?
• How will they be measured?
• What capabilities and information are needed to achieve
those outcomes?
• What processes, services, entities, and rules are needed to
implement those capabilities?
• What existing applications provide basic capabilities and
20
information that can support these?
05/03/2021
• The service inventory describes the overall set of services
necessary to support SOA within a context. In doing so, the
inventory must identify:
• The overall scope
• Areas of service responsibilities
• Groupings of related services
• Entity (information management) services
• Functional and rule services
 Design Guideline
Understanding Overall Context, in SOA Context has some issues :
• What capabilities and information are needed to achieve those outcomes?
• What processes, services, entities, and rules are needed to implement those
capabilities?
• What existing applications provide basic capabilities and information that can
support these?
• The service inventory describes the overall set of services necessary to support
SOA within a context. In doing so, the inventory must identify:
• The overall scope
• Areas of service responsibilities
• Groupings of related services
• Entity (information management) services
• Functional and rule services
22
05/03/2021 Unit 1
Figure shows a sample template for a service inventory. This
sample shows how services might be organized according to
service type
 Design Guideline
Identifying Granularity, During design, as you narrow
down the responsibilities of a service, you need to
decide on the granularity of the service operations. In
other words, how much of that responsibility is
performed in a single interaction with the service?
Should it be broken into smaller units to promote reuse,
consistency, and loose coupling?

24
05/03/2021 Unit 1
 Design Guideline
Stateless Interfaces, An important characteristic of service
interfaces is to be as stateless as possible.
This means that a service does not maintain state on
behalf of its consumer between requests. Any given
request can act on the state of particular information,
but a subsequent request does not rely on the service
maintaining the state from a previous request.

25
05/03/2021 Unit 1
• State berada pada myAccount
myAccount = account service.getAccount (myID);
myBalance = myAccount.getBalance ();
myTransactionHistory = myAccount.getTransactionHistory ();

• Stateless:
myBalance = account service.getAccountBalance (myID);
myTransactionHistory = account service.getTransactionHistory (myID);
• Bisa saja request1 dilayani oleh ServerKe7
dan request2 dilayani oleh ServerKe19
 Design Guideline
Exception, This is undoubtedly true with computers, and even
more so with service-oriented solutions.
Exceptions are an integral part of service interface design. We’ll
discuss three key aspects of exception design here. First, all
exceptions have to be defined at the interface level. Second,
like data, common exceptions should be defined the same
across all services. And third, exceptions need to report
correlation information.
Application exceptions: Insufficient funds, Out of stock, etc
System exceptions: Access denied, System unavailable,
Communications error, etc
27
05/03/2021 Unit 1
 Design Guideline
Designing Documents, One goal of the information model is
to identify information that must be common and shared
among services. It follows then that the information passed
through the service interface should conform to the information
model.
So, how is this accomplished? The concept is actually fairly
simple. If you use the document-passing style interface (which is
what you generally use for business and domain services),
that implies that a document contains the shared
information that is passed between services, and that the
definition of that document is described in a document schema.
28
05/03/2021 Unit 1
 Interface Design Illustrated
This section describes the interface design process by using
an example of an automobile insurance–quoting
process. It can be divided two parts
The problem model, which describes the problem in detail
in business terms, independent of the potential IT
systems,
The solution model, which describes the design of the
solution in terms of SOA concepts.

29
05/03/2021 Unit 1
Source : Applied SOA, Mike Rosen
 Problem Space Model
Is describing the problem in business terms to verify that all the
requirements are framed in the appropriate context.
• Use Case Diagrams and actors
• Actors
• Initial Scenario Diagram
• Detailed Scenario Diagrams
• Service Specification

31
05/03/2021 Unit 1
 Illustration ACME Insurance
(Use Case Diagrams )

• Use case is a series / description of a group of interrelated and

form a system of regularly performed or supervised by an actor.
• Use case is used to shape the behavior of the object / thing in a
mode as well as realized by a collaborator, generally use case is
described by an ellipse with a solid line, usually containing the
name.
• Use case describes the process system (system requirements
from the perspective of the user).
In general use case is:
• The pattern of behavior of the system
• The sequence of transactions that relate performed by actor
32
05/03/2021 Unit 1
 Illustration ACME Insurance
(Use Case Diagrams )
• For this example, we are using
four business use cases:
– request a quote for insurance (BU01)
– purchase an insurance policy (BU02)
– change the coverage on a policy
(BU03), and
– cancel insurance (BU04).
• Actors represent the system’s
interaction/interface with users
and/or other systems and are
involved in the value exchange that
happens in the use case.

Source : Applied SOA, Mike Rosen 33

05/03/2021 Unit 1
 (Initial Scenario Diagrams )

• Each use case has one or more scenarios, which are

described in a scenario diagram. In UML terms, the
scenario diagram is a partitioned activity diagram.
• Partitions are assigned to actors.

For Illustration there are scenarios to represent the use

case :
• Request Quote Scenario
• Purchase Insurance Scenario

34
05/03/2021 Unit 1
 Request Quote Scenario

Source : Applied SOA, Mike Rosen 35

05/03/2021 Unit 1
 Request Quote Scenario
• Figure shows the initial scenario for BU01, Request
Quote. Notice that the first two partitions are associated
with the primary actors of the use case,Customer and
Agent.
• The next partition is assigned to the primary business
worker for the use case, Quoting. This is an example of an
actor appearing in the scenario but not the use case
diagram.
• The last partition is assigned to a secondary actor of the
use case, Underwriting.

36
05/03/2021 Unit 1
 Purchase Insurance Scenario

37
05/03/2021 Source : Applied SOA, Mike Unit 1
Rosen
 Request Quote Scenario
• Figure shows the scenario diagram for the Purchase Insurance
scenario based on business use case BU02.
• The primary business worker, Purchasing, as an actor in the
scenario. Also, this time you have included Pricing in the
scenario.
• The first step is identifying candidates for business services.
• Pricing is common to all three use cases and, therefore, is a likely
candidate for a business service.
• If you have not already identified a business worker to be responsible
for the behavior, you would add it now to the set of actors.
• Of course, Pricing was already identified as a secondary actor in the
use case. This is also an indication that it is a good candidate for a
business service.
38
05/03/2021 Unit 1
 Information Model
• Like the scenarios, the
high-level information
model is constructed
from information provided
in the use case
descriptions and from
basic information that you
know about the business
domain.
• From reading through the
use cases, you identify
several major business
entities such as agency,
customer, application, Source : Applied SOA, Mike Rosen
policy, binder, and quote.
05/03/2021 Unit 1
39
 Service Specification
• A service specification specifies everything that a
consumer of the service needs to know to decide if
they are interested in using the service, as well as exactly
how to use it if they are.
• It also specifies everything a service provider needs to
know to implement the service.

40
05/03/2021 Unit 1
 Service Specification
The service specification includes:
• Service name
• Provided and required interfaces
• Protocol (rules for how the functions are used and in
what order)
• Constraints that reflect what successful use of the service
accomplishes
• Qualities that service consumers should expect such as
cost, availability, performance, and the like
• Policies for using the service, such as security and
transaction scopes
41
05/03/2021 Unit 1
 Illustration of Service Specification
Service Name — AutoQuoting.
Description — The AutoQuoting Service provides quotes for automobile insurance. It accepts a quote
request as input. ACME underwriting and pricing rules are applied to determine the acceptability of
risks and insur ance premium options, and a variety of different quotes with different coverages and
deductibles are returned. The service implements business use case BU01.
Provided interfaces — AutoQuoting provides the quoting interface with the following operations:
quote createQuote (quoteRequest);
quote getQuote (quoteID);
quote quotePolicyChange (quoteRequest);
alternateQuoteProposal createAlternateProposal
(riskAssessment);
Required interfaces — AutoQuoting requires the use of the Pricing and CustomerManager interfaces.
Protocol — AutoQuoting follows a standard request/reply protocol. There are no callbacks.
Constraints — AutoQuoting must be called on behalf of an agency that is authorized to see insurance in
the requested state.
Qualities of service — AutoQuoting has 99.9% availability, except between 02:00 and 03:00 EST when
maintenance may be performed. A reply will be returned within 15 seconds 95% of the time. The
service can handle up to 10 requests per second.
Policies — Requests for quotes can be submitted by company representatives or independent agents. For
details see the run-time policy UserIsAgent.
42
05/03/2021 Unit 1
Thank You