soa in action
DESCRIPTION
SOA in Action. Chapter 10 B. Ramamurthy. 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 - PowerPoint PPT PresentationTRANSCRIPT
04/20/23 1
SOA in Action
Chapter 10
B. Ramamurthy
04/20/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/20/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/20/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.
Sequence Diagram for Airline Checkin Web Application
04/20/23 5
<<Serv ice>>Catering
Caller <<Serv ice>>CheckIn
<<Serev ice>>TicketServ ice
<<Serv ice>>CustomerInf o
getTicket
return Tickets
chkin(ticket)
check(ticket)
ticketOk
getCustPref s
assignSeats
setCheckedIn(ticket)
returnBoardingPass()
requestMeal()
04/20/23 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.
04/20/23 7
Service-enablement
Monolithic application
Visualpart
Non-Visualpart
Separate visual and non visual parts
04/20/23 8
Service-enablement
Application frontend
Applicationlogic
Application frontend
Application interface!#1
ApplicationInterface#2
Vertical slicing
04/20/23 9
Service-enablement
Application frontend
Application interface!#1
ApplicationInterface#2
Observe data encapsulation
04/20/23 10
Services infrastructure (Ex: ESB)
Service-enablement (SCA: Services Component Architecture)
Application frontendApplication frontend
Service #2Service #2Service #1Service #1
04/20/23 11
Transform Granularity
Transform fine-granular interaction among distributed components into coarse-granular interaction pattern using facades.
See fig.10.5
04/20/23 12
Granularity of access
Traditional userinterface Application
frontend
Applicationfrontend
Façade #2Façade #2Façade #1Façade #1
Ser
vice
s in
fras
truc
ture
04/20/23 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
04/20/23 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.
04/20/23 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
04/20/23 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)
04/20/23 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
04/20/23 18
Rich Client Example
Checkin KioskCheckin Kiosk
Customer serviceCustomer serviceCheckin serviceCheckin service Ticket serviceTicket service
Luggage Scale
Card ReaderLuggage tag
printer
Boarding Passprinter
04/20/23 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 …
04/20/23 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
04/20/23 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.
04/20/23 22
Multi-channel applications
PartnerVPN
Internet
WirelessAccess
Self-servicekiosk
Check-in desk
Agency
ServiceCenter
FunctionalCore
04/20/23 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
04/20/23 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.