SOA

1
SOA

• Chapter 5
• Web Services and Primitive SOA

2
(No Transcript)
3
The Web Services Framework

• Web Service Framework is characterized by
• An abstract (vendor neutral) existence defined by
  standards organizations and implemented by
  proprietary platforms
• Core building blocks Web services, service
  descriptions, and messages
• A communications agreement based on WSDL service
  descriptions

4
The Web Services Framework

• Web Service Framework is characterized by
• A messaging framework comprised of SOAP
• A service description registration and discovery
  architecture (UDDI)
• A well-define architecture that supports
  messaging patterns and compositions
• A second generation of Web service extensions
• WS-I Basic Profile provides standards and best
  practices that govern WSDL, SOAO and UDDI features

5
Services (As Web Services)

• Web services can duplicate the functionality of
  proprietary distributed systems or they can be
  fully SOA compliant
• This flexibility explains their popularity
• For us, Service Web Service

6
Service Roles

• Web services assume different roles even during
  execution of a single business task
• Message Initiator
• Message Relayer
• Message recipient

7
Service Provider

• A Service is a provider under the following
  conditions
• The service is invoked via an External source
• The service provides a published service
  description offering information about its
  features and behavior

8
Service Provider Terminology

• Service Provider entity the organization
  providing the Web service
• Service Provider agent the Web service itself,
  acting as an agent of the entity

9
Service Requestor

• Any unit of logic that issues a request message
  that is understood by a service provider
• A Web service takes on the service requestor role
  when
• Web service invokes a service provider by sending
  it a message
• The Web service searches for and accesses the
  most suitable service provided by examining
  available service descriptions

10
Service Requestor Terminology

• Service requestor entity the organization of
  individual requesting the service
• Service requestor agent the Web service itself,
  acting as an agent of the entity
• Sometime service requestors are referred to as
  service consumer

11
RailCo Case Study

• RailCo no longer the TLS main vendor of airbrakes
• TLS now looks for B2B arrangements
• TLS dictates every supplier must programmatically
  interface with the TLS inventory control
• Suppliers must connect to accounting interface
  for submitting invoices

12
RailCo Case Study

• RailCo built a B2B extension for their accounting
• TLS submits electronic POs
• Upon shipping, electronic invoice is sent to TLS
  accounts payable

13
RailCo Case Study
Request
PO Service
Order Fulfillment Service
Response Request
Accounts Payable Service
Invoice Submission Service
RailCo
TLS
Response
14
Intermediaries

• Web service communications uses point-to- paths
• Messages can be processed by multiple
  intermediate routing and processing agents before
  arriving at destination
• Services and Agents that do this are
  intermediaries

15
Intermediaries

• Passive intermediary simply routes without
  modifying the message
• Active intermediary process and alter message
  contents before routing the message

16
RailCo Case Study
TLS Accounts Payable
RailCo Invoice
TLS Load Balancer
Passive intermediary acts first as provider for
Invoice system, and requestor for TLS Accounts
Payable
17
Active Intermediary
Ultimate Receiver
Initial Sender
Service Provider
Service Requestor
Active Intermediary
Active intermediary acts modifies messages by
altering, inserting, or deleting SOAP headers
18
TLS Case Study

• TLS uses Internal Policy Service (active
  intermediary) to examine messages
• Policy rule headers may be added to SOAP messages
• Messages are then forwarded for further processing

19
Service Compositions
Composite service (Assembly)
TLS Accounts Payable
RailCo Invoice
TLS Load Balancer
Services can be composed to make new
20
TLS Case Study
Accounts Payable Composite Service
1
Vendor Profile
Accounts Payable
2
3
Ledger Service
4
21
Service Models - Business

• Encapsulates a distinct set of business logic
• Ideally autonomous (can participate in
  compositions)
• Used within SOAs
• As fundamental building blocks for logic
• To represent a corporate entity or information
  set
• To represent business process logic
• As service composition members

22
Service Models - Utility

• Provides generic functionality usually not
  associated with business logic
• Used within SOAs
• As services that enable characteristic reuse
  within SOA
• As solution-agnostic intermediary services
• As services that promote intrinsic
  interoperability
• As the services with the highest degree of
  autononomy

23
Case Study

• Accounts Payable Business Service
• Internal Policy Utility Service
• Invoice Submission Business Service
• Ledger Business Service
• Load Balancing Utility Service
• Order Fulfillment Business Service
• Purchase Order Business Service
• Vendor Profile Business Service

24
Service Models - Controller

• Assembles and coordinates other services to
  supply a business function
• Acts as a parent service to service composition
  members
• Used within SOAs
• To support and implement the principle of
  composability
• To leverage reuse opportunities

25
Master Controller
Business
Master Controller
Business
Business
Business
Sub-Controler
Business
26
Accounts Payable Business and Controller Service
Accounts Payable Composite Service
1
Vendor Profile
Accounts Payable
2
3
Ledger Service
4
27
Service Descriptions - WSDL

• Description documents are required to accompany
  any service wanting to act as ultimate receiver
• WSDL Web Service Description Language
• WSDLs enable loose coupling between services

28
WSDL
Complies with message format defined in
Complies with message format defined in
Service A
Service B
WSDL for Service B
WSDL for Service A
29
Case Study

• RailCo needs the TLS WSDL service description
  published by TLS for their Accounts Payable
  Service
• RailCo developers use WSDL to build
  SOAP-compliant messages
• RailCo provides TLS with a WSDL for the RailCo
  Order Fulfillment Service
• TLS add the WSDL to a list of vendor endpoints
  that will receive POs
• TLS defines the terms of message exchange and
  RailCo meets the terms

30
Service Endpoints and Descriptions

• WSDL describes the point of contact for a service
  provider (endpoint)
• WSDL provides a formal description of the
  endpoint interface
• Establishes a physical location of the service

31
WSDL Layout

• Contains two categories
• Abstract description
• Concrete description

WSDL
Abstract
Concrete
32
WSDL Abstract Description

• Three main parts
• portType high-level view of service interface.
  Sorts messages into groups of functions called
  operations
• Operation a specific action performed by the
  service. (Think public method for components in
  traditional distributed applications)
• Message parameters are represented as messages.
  An operation consists of a set of input and
  output messages

33
WSDL Concrete Description

• The abstract interface definition must be
  connected to a real, implemented technology
• The physical transport protocol is described in
  three parts
• Binding the requirements to esablish physical
  connection with the service (SOAP,)
• Port the physical address for the service
• Service the service represents a group of
  related endpoints

34
Case Study

• TLS Accounts Payable Service receives invoices
  submitted by many vendors
• WSDL has a simple abstract definition consisting
  of one interface definition containing a single
  operation SubmitInvoice
• Within the operation is one input message
  (accepts invoice data) and one output message
  (sends acknowledgement)
• The concrete part binds the operation to the SOAP
  protocol and provides a location address for the
  Accounts Payable Service

35
Metadata and Service Contracts

• WSDL definitions usually rely on XSD schemas to
  formalize the structure of messages
• Policies are supplementary information in a WSDL
• Policies provide rules, preferences, and
  processing details beyond what is expressed in
  the WSDL and schema

36
Service Contract
WSDL
Abstract
Metadata for Service
XSD Schema
Concrete
Policy
Legal Documents
37
Semantic Descriptions

• Most metadata focuses on technical information
  regarding data representation and processing
  requirements
• Other semantic data can also be provided
• How a service behaves under certain conditions
• How a service will respond to a specific
  condition
• What specific tasks the service is best suited for

38
Description Advertisement and Discovery

• As the number of services within and without
  organizations increases, advertising mechanisms
  may be needed
• UDDI formed the first generation of Web service
  standards. (Not commonly implemented)
• Central directories and registries allow humans
  and service requestors to
• Locate the latest versions of known service
  descriptions
• Discover new Web services

39
Registries

• Public Accept registrations from organizations
  with or without Web services they act as
  service provider entities
• Private Can be implemented within an
  organization to provide a central repository for
  descriptions of services

40
UDDI Components

• Business entities and business services records
  contain basic profile information about a
  business including service area
• Binding Templates and tModels templates
  separate physical information from registry
  records. tModels provide pointers to actual
  service descriptions

41
UDDI Business Entity Record
Web Service
Business Entity
Business service Binding template tModels
WSDL
42
Case Study

• TLS is actively developing new services for
  current development and integration
• A year-end review indicated that several teams
  built Web services with similar functionality
• A private registry was established to help with
  this problem. Teams must register services in
  the registry as part of the standard development
  lifecycle
• Some larger companies form Service Review Boards
  that establish policy for services and provide a
  review forum for company-wide issues with services

43
SOAP Messaging

• The most fundamental action within SOA and the
  sole action that initiates service-oriented
  automation is message receipt
• Message frameworks must be flexible and reliable
• SOAP is the univerally accepted standard for Web
  services

44
SOAP

• Original name Simple Object Access Protocol
• SOAP is now a standalone term
• SOAP parts
• Envelope encloses the entire message
• Header An area for metadata.
• Body contains the message body (payload)

45
Message Structure
Message Envelope
Header Blocks
Body
46
Header Blocks

• Header blocks outfit a message with information
  needed by all the services which process the
  message
• This relieves services from having to store
  message-specific logic
• Almost all WS- extensions are implemented with
  header blocks

47
Message Features with Headers

• Processing instructions that may be executed by
  service intermediaries or ultimate receiver
• Routing or workflow information
• Security measures implemented in the message
• Reliability rules related to the delivery of the
  message
• Context and transaction management information
• Correlation information to associate request and
  response messages

48
Case Study

• Invoices sent to TLS are required to contain a
  standard header block
• The header blocks include
• A correlation identifier extended with the date
  and time of transmission
• Organization-level security credentials for
  authentication. Each vendor has a security
  account with TLS

49
Message Styles

• SOAP was originally designed to replace
  proprietary RPC protocols
• RPC-style is contrary to SOA practice
• SOA relies on document-style messages with larger
  payloads, coarser interface operations, and
  reduced message transmission volumes

50
Case Study

• Submitting an invoice between RailCo and its
  customer includes
• Generation and mailing of invoice
• Generation and mailing of account statement for
  currently outstanding amounts
• Generation and mailing of discount reminder to
  explain RailCos pricing and to show the customer
  how close they are to a discount
• All three of these documents needed to be
  included in the same SOAP message

51
Attachments

• For data that is not easily formatted into XML,
  the use of SOAP attachment technologies exist
• Each technology provides a mechanism for bundling
  data in native format with a SOAP message

52
Case Study

• TLS accounting policy requires that all issued
  purchase orders in excess of 100,000 have a
  signature of a senior manager
• For large POs, signatures are scanned at TLS and
  the scanned document is included as a SOAP
  attachment on the invoice message

53
Faults

• SOAP messages offer the ability to add exception
  handling logic by providing an optional fault
  section within the body
• The fault area typically contains a message used
  to deliver error condition information for
  exceptions
• In the previous case study, a fault is included
  with a message to govern delivery problems for
  the attachment

54
Nodes

• Programs that services use to transmit and send
  SOAP messages are SOAP nodes
• SOAP nodes must conform to SOAP specification, as
  a result SOAP messages are vendor-neutral

55
Node Types

• SOAP sender a SOAP node that transmits a
  message
• SOAP receiver a SOAP node that receives a
  message
• SOAP intermediary a SOAP node that receives and
  transmits a message with optional processing
• Initial SOAP sender the first SOAP node to
  transmit the message
• Ultimate SOAP receiver the last SOAP node to
  receive a message

56
Case Study
Invoice Submission
Accounts Payable
SOAP Receiver
SOAP Sender
SOAP Message Via HTTP
57
SOAP Intermediaries
Service Requestor
Service Provider
Intermediate Service
SOAP Receiver
SOAP Intermediate
SOAP Sender
58
Message Paths

• A message path is the route taken from being sent
  to ultimate arrival
• Message path modeling is becoming increasingly
  important for large SOA
• The use of header blocks can alter the path
  dynamically

59
Case Study

• For RailCo, the message path is always the same
• RailCo Submission Service is the initial
  requestor.
• The first service provider is the TLS Load
  Balancer intermediary
• The message is forwarded to the Accounts Payable
  Service provider
• Finally, the Web service becomes the ultimate
  receiver
• The path consists of three services

60
SOAP Intermediaries