SOA in Action

1
SOA in Action

• Chapter 10
• B. Ramamurthy

2
Motivation

• Different usage models for the same service
  different protocols for access, different
  granularity, different access methods and
  endpoints
• Different design considerations are needed
• Typically multiple services are at work
• Consider these does a service need to
  idempotent? Is it aggregation-friendly? Is it
  transaction-based or compensation-based?
  Asynchronous or asynchronous?

3
Topics

• Different application models dictate different
  requirements
• Web application (10.1)
• EAI integration (10.2)
• B2B model (10.3)
• Fat client model (10.4)
• Small mobile device such cellular telephone
  access to services (10.5)
• Multi-channel access to services (10.6)

4
Web Application

• General interaction pattern (fig.10-1)
• Browser /web server security model state
  maintained by web application (fig. 10-2)
• One time transaction (OTT) pattern (fig.10-3)
• While layer diagram was good for architectural
  model, semantics or logic for services
  interaction cannot be explained using the layer
  diagram
• We will look at sequence diagram and features
  provided by BPEL for this.

5
Sequence Diagram for Airline Checkin Web
Application
6
Enterprise Application Integration (EAI)

• Classify the applications as service providers
  and service consumers. Pattern service provider/
  service consumer
• Single sign-on, quality of service should be
  explicitly addressed.
• Service enablement strategies create a service
  encapsulating the functionality provided by an
  existing application.
• Consider the transformation of a monolithic
  application into a service-oriented application.

7
Service-enablement
Separate visual and non visual parts
8
Service-enablement
Vertical slicing
9
Service-enablement
Application frontend
Application interface!1
Application Interface2
Observe data encapsulation
10
Service-enablement (SCA Services Component
Architecture)
Services infrastructure (Ex ESB)
Application frontend
Service 2
Service 1
11
Transform Granularity

• Transform fine-granular interaction among
  distributed components into coarse-granular
  interaction pattern using facades.
• See fig.10.5

12
Granularity of access
Application frontend
Traditional user interface
Façade 2
Façade 1
Services infrastructure
13
EAI ? SOA

• EAI can drive an SOA
• EAI is excellent driver for service enabling
  applications
• From business perspective EAI is introduced to
  simplify application infrastructure and to foster
  reuse.
• This is good motivation for resorting to SOA

14
Stability and Upgradeability

• Service stability and upgradeability are two of
  the most desirable features in an EAI
  environment.
• User and provider in different domains
• Backward compatibility
• Different versions are supported (see fig 10-6
  and 10-7)
• EAI requires repositories to ensure stability and
  upgradeability.

15
Business-to-Business (B2B)

• In a B2B environment a corporation offers some
  service to another company over the public
  networks.
• Service consumer and provider benefit greatly
  from standardized protocols.
• Standards such as ebXML (UN/CEFACT), and
  RosettaNet are examples of standardization
  effort.
• Business process can be stateful, but services
  invocations can be stateless by using token
  identifying an interaction.
• Typical characteristics stateless, location
  transparency, trusted domains

16
B2B

• Stateless enables interaction with remote
  customers over connections with high network
  latency. Much fewer constraints on the caller
  applications.
• Location transparency real location transparency
  using service repositories. Change is a location
  of a service need to be updated only in the
  registries, caller need not be aware of this.
• Consider airline ticket with multiple legs of
  journey (Scenario is explained very nicely
  pp218-219)
• Send to the request to trusted airline partner
  (Apply when weak connectivity)
• Frequent synchronization with partners
  (infrequent usage)
• Partner 1 is service consumer of services offered
  by partner 2 ( stable connectivity, frequent
  usage)
• Service level agreements provides a mechanism for
  negotiation, guarantees, monitoring and
  enforcement of agreements. (See web services
  standards WS-SLA)

17
Fat Clients (Better Rich Clients)

• Rich Interface Applications (no need to install
  an .exe/xyz.war file to run an application)
• Ex Google maps, mapquest
• Clients trusted by the local environment
• Check-in kiosk is a fine example

18
Rich Client Example
Checkin Kiosk
Luggage Scale
Boarding Pass printer
Luggage tag printer
Card Reader
Customer service
Checkin service
Ticket service
19
Designing for smaller devices

• How do you define a small device? Small footprint
  operating system, small screen (150X100 pixels),
  limited processing capability, small memory
  256KB, limited data entry, connectivity to enable
  periodic synchronization with base and facilitate
  participation in an SOA.
• Lightweight security information available on an
  identifier embedded in the device such as

20
Smaller devices in an SOA

• Decouple the service invocation in the device
  from the actual service using an adapter that
  resides at a gateway server.
• Ex SMS (short message service) messaging instead
  of soap messaging until the gateway gateway may
  translate into SOAP payload semantics to the
  actual service.
• MMS (Multimedia Service) is a successor of SMS

21
Multi-channel Applications

• A multi-channel application is characterized by a
  functional core that can be accessed through
  different channels by either humans or other
  programs.

22
Multi-channel applications
23
Multi-channel application

• Start with fundamental SOA only two layers
  Enterprise layer with all the application
  frontends for the various channels and basic
  functional layer (fig. 10-16)
• Lean service approach
• A façade can be added at intermediary layer (fig.
  10-17)
• Façade manages the heterogeneity of underlying
  layers
• If every channel requires its own
  channel-specific processing add a process layer
  with one service per frontend (fig. 10-19)
• Every channel requires its own process

24
Summary

• Use scenario diagram (UML standard) to discuss
  semantic flows among services
• We discussed scenarios where an SOA can be
  beneficial.
• Provide a service with a number of interfaces and
  protocols and design the service with the
  requirements specified by the customer.