Principles of ServiceOrientation

1
Chapter 8

• Principles of Service-Orientation

2
Topics Covered in Chapter 8

• 8.1 Service-oriented and the enterprise
• 8.2 Anatomy of a service-oriented architecture
• 8.3 Common principles of service-orientation
• 8.4 How service-orientation principles
  inter-relate
• 8.5 Service-orientation and object-orientation
• 8.6 Native Web service support for
  service-orientation principles

3
Objective and Goals

• Understand how enterprise systems and
  Service-orientation are defined in relationship
  to each other
• Understand the anatomy of service-oriented
  architecture
• Understand the common principles of
  service-oriented architecture
• Understand how service-orientation principles
  inter-relate to one another
• Understand what Service-orientation and
  object-orientation is
• Understand Native Web service support

4
Introduction

• This chapter begins with a look at how
  service-orientation applies to the enterprise as
  a whole and them discusses individual principles
  in-depth.
• Primitive components of an SOA
• Services
• Descriptions
• Messages

5
Service-orientation and the enterprise

• 8.1

6
Service-orientation and the enterprise

• Enterprise logic is divided into two halves
• Business Logic
• Business Logic is a documented implementation of
  the business requirements that oriented from an
  enterprises business area.
• Application Logic
• Application logic is an automated implementation
  of business logic organized into various
  technology solutions.

7
Enterprise logic

• Services establish a high form of abstraction
  wedged between traditional business and
  application layers
• Services can encapsulate physical application
  logic as well as business process logic

8
Enterprise logic

• Individual services represent application logic
  originating from different platforms

9
Key Points

• Enterprise logic can be divided into two domains
  business logic and application logic.
  Service-oriented principles can be applied to
  both
• The service interface layer positions services to
  represent business logic and abstract application
  logic.

10
8.2 Anatomy of a service-oriented architecture

• 8.2.1 Logic components of the Web services
  framework
• 8.2.2 Logic components of automation logic
• 8.2.3 Components of an SOA
• 8.2.4 How components in an SOA inter-relate

11
Anatomy of a service-oriented architecture

• 8.2

12
Logic components of the Web services framework

• Web services contain one or more operations.
• Figure 8.4 as an example

13
Logic components of the Web services framework

• Each operation governs the process of a specific
  function the web service is capable of
  performing.
• Figure 8.5 gives an example of an operation
  sending and receiving SOAP messages

14
Logic components of the Web services framework

• Web services form an activity though which they
  can collectively automate a task.
• Figure 8.6 as an example

15
Logic components of automation logic

• Fundamental parts of the framework
• SOAP messages
• Web service operations
• Web services
• Activities

• Renamed terms
• Messages
• Operations
• Services
• Processes
• Activity has been changed because it uses a
  different context when modeling service-oriented
  business processes.

16
Logic components of automation logic

• Messages units of communication
• Operations units of work
• Services units of processing logic
• Processes units of automation logic

17
Logic components of automation logic

• The purpose of these views is to express the
  process, services and operations.
• Is also provides a flexible means of partitioning
  and modularizing the logic.
• These are the most basic concepts that underlies
  service-orientation.

18
Components of an SOA

• Message
• A message represents the data required to
  complete some or all parts of a unit of work.

19
Components of an SOA

• Operation
• An operation represents the logic required to
  process messages in order to complete a unit of
  work.

20
Components of an SOA

• Service
• A service represents a logically grouped set of
  operations capable of performing related units of
  work.

21
Components of an SOA

• Processes
• A process contains the business rules that
  determine which service operations are used to
  complete a unit of automation.
• A process represents a large piece of work that
  requires the completion of smaller units of work.

22
How components in an SOA inter-relate

• An operation sends and receives messages to
  perform work.
• An operation is therefore mostly defined by the
  message it processes.

23
How components in an SOA inter-relate

• A service groups is a collection of related
  operations.
• A service is therefore mostly define by the
  operations that comprise it.

24
How components in an SOA inter-relate

• A process instance can compose service.
• A process instance is not necessarily defined by
  its service because it may only require a subset
  of the functionality offered by the services.
• A process instance invokes a unique series of
  operations to complete its automation.
• Every process instance is therefore partially
  defined by the service operation it uses.

25
How components in an SOA inter-relate
26
Key Points

• The logical parts of an SOA can be mapped to
  corresponding components in the basic Web
  services framework.
• By viewing a service-oriented solution as a unit
  of automation logic, we establish that SOA
  consists of a sophisticated environment that
  supports a highly modularized separation of logic
  into differently scoped units.
• SOA further establishes specific characteristics,
  behaviors, and relationships among these
  components that provide a predictable environment
  in support of service-orientation.

27
Common principles of service-orientation

• 8.3

28
Common principles of service-orientation

• Services are reusable
• Services share a formal contract
• Services are loosely coupled
• Services abstract underlying logic
• Services are composable
• Services are autonomous
• Services are stateless
• Services are discoverable

29
Services are reusable

• Regardless of weather immediate reuse
  opportunities exist, services are designed to
  support potential reuse.
• Service-oriented encourages reuse in all
  services.
• By applying design standards that require reuse
  accommodate future requirements with less
  development effort.

30
Services are reusable
31
Case Study

• RailCo created the Invoice Submission Service
  which contains two operations
• SubmitInvoice
• GetTLSMetadata
• SubmitInvoice - Allows RailCo send electronic
  invoices to TLS Account Payable Service
• GetTLSMetadata checks periodically for changes
  to TLS Account Payable Service

32
Case Study

• In Plain English
• Business License Office provides a distinct
  service
• Issuing business licenses
• Renewing business licenses
• Provides service to all customers
• Classifies this service as reusable

33
Services share a formal contract

• For services to interact, they need not share
  anything but formal contract that describe each
  service and define the terms of information
  exchange.

34
Services share a formal contract

• Service contracts provide a formal definition of
• The service endpoint
• Each service operation
• Every input and output message supported by each
  operation
• Rules and characteristics of the service and its
  operations
• Service contacts define almost all of the primary
  parts of an SOA.

35
Services share a formal contract
36
Case Study

• RailCo and TLS agreed to a service contract that
  allow the two companies to communicate
• TLS defined the definition of the associated
  service description documents
• TLS ensures a standardized level of conformance
  that applies to each of its online vendors
• TLS can change the service at any time

37
Case Study

• In Plain English
• Application form is needed obtain or renew a
  business license
• Application formalizes the request in a standard
  format for the Business License Office
• Application is a contract between the business
  and Business License Office

38
Services are loosely coupled

• Services must be designed to interact without the
  need for tight, cross-service dependencies.

39
Services are loosely coupled
40
Case Study

• TLS services are designed to communicate with
  multiple online vendors make it loosely coupled
• RailCo service are designed to communicate only
  with TLS B2B system so is considered less loosely
  coupled

41
Case Study

• In Plain English
• Once the Application is submitted no further
  action is required on the business
• Business and Business License Office remain
  independent
• Application is the only requirement to
  communicate with Business License Office

42
Services abstract underlying logic

• The only part of a service that is visible to the
  outside world is what is exposed via the service
  contract. Underlying logic, beyond what is
  expressed in the descriptions that comprise the
  contract, is invisible and irrelevant to service
  requestors.

43
Services abstract underlying logic
44
Case Study

• RailCo Web services hide the underlying legacy
  code need to produce the invoices that are needed
  to sent to TLS
• TLS Web services hide the underlying services
  that process the invoices from multiple online
  vendors
• Neither service requestor require any knowledge
  of what processes are working on the others
  service providor

45
Case Study

• In Plain English
• Business License Office tasks are hidden from the
  business
• Business does not care what Business License
  Office does, it just wants a license

46
Services are composable

• Services may be compose other services. This
  allows logic to be represented at different
  levels of granularity and promotes reusability
  and the creation of abstraction layers.

47
Services are composable
48
Case Study

• TLS accounts Payable Service is composed on three
  services
• Accounts Payable Service
• Vendor Profile Service
• Ledger Service

49
Case Study

• In Plain English
• Other government agencies can use the Business
  License Office for their license tasks