04/22/23 1

SOA in Action

Chapter 10B. Ramamurthy

04/22/23 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?

04/22/23 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)

04/22/23 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.

04/22/23 5

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.

04/22/23 6

Service-enablement

Monolithic application

Visualpart

Non-Visualpart

04/22/23 7

Service-enablement

Application frontend

Applicationlogic

Application frontend

Application interface!#1

ApplicationInterface#2

04/22/23 8

Service-enablement

Application frontend

Application interface!#1

ApplicationInterface#2

Observe data encapsulation

04/22/23 9

Services infrastructure (Ex: ESB)

Service-enablement (SCA: Services Component Architecture)

Application frontend

Service #2Service #1

04/22/23 10

Transform Granularity

Transform fine-granular interaction among distributed components into coarse-granular interaction pattern using facades.

See fig.10.5

04/22/23 11

Granularity of access

Traditional userinterface Application

frontend

Façade #2Façade #1

Ser

vice

s in

frast

ruct

ure

04/22/23 12

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

04/22/23 13

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.

04/22/23 14

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

04/22/23 15

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)

Service level agreements provides a mechanism for negotiation, guarantees, monitoring and enforcement of agreements. (See: web services standards WS-SLA)

04/22/23 16

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

04/22/23 17

Rich Client Example

Checkin Kiosk

Customer service Checkin service Ticket service

Luggage Scale

Card ReaderLuggage tag

printer

Boarding Passprinter

04/22/23 18

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 …

04/22/23 19

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) messing

instead of soap messaging until the gateway; gateway may translate into SOAP payload semantics to the actual service.

MMS (Multimedia Service)

04/22/23 20

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.

04/22/23 21

Multi-channel applications

PartnerVPN

Internet

WirelessAccess

Self-servicekiosk

Check-in desk

Agency

ServiceCenter

FunctionalCore

04/22/23 22

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)

A façade can be added at intermediary layer (fig. 10-17)

If every channel requires its own channel-specific processing add a process layer with one service per frontend (fig. 10-19)

04/22/23 23

Summary

Use scenario diagram (UML standard) to discuss semantic flows among services

Design the SOA based the application domain in which it needs to deployed.

Which of the SOA is applicable to our KJ world?