Service oriented architecture

1. Service Oriented Architecture
Dr. V. Prasanna Venkatesan
Professor
Department of Banking Technology
Pondicherry University
Pondicherry, India – 605 014
prasanna _v@yahoo.com

2. Outline
Introduction to SOA
SOA Concepts
SOA Security
SOA & Organization
Case study: E-Banking
Future State of SOA

3. Introduction to SOA
“Information technology and business are
becoming inextricably interwoven. I don't
think anybody can talk meaningfully about one
without the talking about the other.”

4. Business – The Current Scenario

5. Business – The Current Scenario
Results in

6. Business – The Current Scenario

7. Current IT Infrastructure
 Lacks agility to keep up with business
objectives
 Places limitations on Business
 Requirements change
 Interpretations often inaccurate or limited
 Lengthy development cycles inflexible to
change
 Implementations “cast in concrete”

8.  Majority of solutions have been created by
 identifying the business tasks
 defining their business requirements
 building the corresponding solution logic
 Change in requirements
 modify existing solution
• Not Efficient
• Results in Complex Infrastructures and
complicated Enterprise Architectures
• Integration becomes a Challenge
Current IT Infrastructure

9.  majority of solutions have been created by
 identifying the business tasks
 defining their business requirements
 building the corresponding solution logic
 Change in requirements
 modify existing solution
 build a new application altogether
Current IT Infrastructure
• Highly Wasteful
• Inflates an Enterprise

10. The Way out is to…
 Go with an enterprise technology solution that
promises agility and flexibility
 Leverage integration process through composition
of services spanning multiple enterprises

11. The Way out is to…
Think about business outcomes as
a set of composed services
instead of monolithic applications

12. SOA Concepts
“SOA will be a prevailing software
engineering practice, ending the 40-year
domination
of monolithic software architecture.”

13. The Solution is…ServiceOrientation
 SO is a design paradigm that
specifies the creation of
automation logic in the form
of services
 Service refers to a discretely
defined set of contiguous
and autonomous business or
technical functionality
 SO is applied as a strategic
goal in developing a Service-
Oriented Architecture (SOA).
Services are trees
SO is the Forest

14. The Solution is…ServiceOrientation
 Access software via Services that are easy to
find and connect to
 Provide a standard way of building and
accessing Services
 Build applications out of Services

15. Wasn’t there SOA before?
 SOA have been around a while
 CORBA (Common Object Request Broker
Architecture)
 DCOM (Microsoft Distributed Component
Object Model)

16. Why is it different?
 SOA reflects the reality of ownership
boundaries
 CORBA, RMI, COM, DCOM, etc. all try to
implement transparent distributed systems
 Ownership is of the essence in SOA
 SOA is task oriented
 Components are organized by s/w function
 Services are organized by business function
 SOA is inspired by human organizations
 Component concepts are technology-oriented
 Services worked for us, it should work for
machines

17. So… What is SOA ?
SOA is a conceptual business architecture
where business functionality or application logic
is made available to SOA users, or consumers
as shared reusable services on an IT network
[Source: SOA: A planning and implementation guide for business and
technology by Eric A. Marks, Michael Bell]

18. So… What is SOA ?
[Source: IBM ]
An SOA is an orchestrated sequence of
messaging, transformation, routing and
processing events in which XML
technologies expose the message
content and the components that
operate on the messages

19. SOA- Roles & Functions
 Service Consumer :
Discover services and
metadata from Service
Registry
 Service Producer :
Publish newly developed
services and artifacts
 Service Registry : Notify
clients of changes
Organize service metadata
with classification and
lifecycle support (Broker)

20. Application Centric
Application
Application
Finance
Distribution
Manufacturing
Supply
Narrow Consumers
Limited Business Processes
Overlapped resources
Overlapped providers
Business scope
Application
Integration
Architecture
Business functionality is
duplicated in each
application that requires it.
EAI ‘leverage’ application silos with
the drawback of data and function
redundancy.
bound to
EAI vendor
Redundancy

21. Service Architecture
Service
Service
Service
Service
Finance
Distribution
Manufacturing
Supply
Service virtualizes how that capability is
performed, and where and by whom the
resources are provided, enabling multiple
providers and consumers to participate
together in shared business activities.
Multiple Service Consumers
Multiple Business Processes
Multiple Discrete Resources
Multiple Service Providers
source:TietoEnator AB,
Kurts Bilder
Business scope
SOA structures the business and its systems
as a set of capabilities that are offered
as Services, organized into a Service
Architecture
Shared
Services
Service Centric

22. Before SOA – After SOA
source:IBM

23. Why SOA?
To enable Flexible, Federated Business Processes
Enabling a virtual federation of
participants to collaborate in an
end-to-end business process
Enabling alternative
implementations
Enabling reuse of
Services
Enabling virtualization of business resources Enabling aggregation from multiple
providers
Identification
Ticket Sales
Ticket Collection
Inventory
Logistics
Manufacturing
Availability
Service
Service
Service
Service Service
Service
Service
Service
Service
Service
Ordering
source:TietoEnator AB,
Kurts Bilder

24. Why SOA? To enable Business Process Optimization
and the Real Time Enterprise (RTE)
Seamless End to End Process
Internal Systems
SOA Pattern: Standardized Service
provided by multiple suppliers
Service from Multiple Suppliers
SOA Patterns: Single, Multi-Channel
Service for consistency
BPM Expressed in
terms of Services
Provided/Consumed
Enterprise
source:TietoEnator AB,
Kurts Bilder
Smart Clients
Stores POS
Mobile
3rd Party Agents
Portal
Service to Customers

25. Why SOA?
Enable Structural Improvement
ERP X Process Z Partner A Process Y
Service
Standardizing capabilities Information Consistency
Policy Consistency
e.g. Single Customer
Details Service
Consolidation/
Selection
process
Reducing impact
of change
Encapsulating
implementation
complexity
ERP Z
CRM
System 2
CRM
System 1
Product
System
Policy Rationalization and Evolution
Resource Virtualization
e.g. Multiple Sources
of Customer Details

26. SOA Defined
 SOA is a software architecture model
 in which business functionality are logically grouped and encapsulated
into
 self contained,
 distinct and reusable units
called services that
 represent a high level business concept
 can be distributed over a network
 can be reused to create new business applications
 contain contract with specification of the purpose, functionality,
interfaces (coarse grained), constraints, usage
... of the business functionality
Services are autonomous, discrete and reusable units of business functionality exposing its
capabilities in a form of contracts.
Services can be independently evolved, moved, scaled even in runtime.

27. What is Service Architecture?
• A collection of services
• classified into types
• arranged into layers
• Governed by architectural
patterns and policies
services
type type
type
source:TietoEnator AB,
Kurts Bilder

28. Big (outer) vs. Little (inner) SOA

29. SOA is an evolutionary step
 for architecture

30. SOA is an evolutionary step
 in reusability and communication

31. SOA is an evolutionary step
Project-ware SOA
EAI
 in distributed communications
source:Sam Gentile

32. Service Architecture Organized by Layers
Reasons for Layering
1. Flexible composition.
2. Reuse.
3. Functional standardization in lower
levels
4. Customization in higher layers
5. Separation of Concerns.
6. Policies may vary by Layer
Example Layers
Presentation
& workflow
Composed Services
Basic Services
Underlying
API
according to:TietoEnator
AB, Kurts Bilder

33. Major service types
 Basic Services:
 Data-centric and logic-centric services
 Encapsulate data behavior and data model and ensures
data consistency (only on one backend).
 Basic services are stateless services with high degree of
reusability.
 Represent fundamental SOA maturity level and usually are
build on top existing legacy API (underlying services)
 Composed Services :
 expose harmonized access to inconsistent basic services
technology (gateways, adapters, façades, and functionality-
adding services).
 Encapsulate business specific workflows or orchestrated
services.

34. Service Types
Foundation
Service Blocks
Core APIs
G
eo
M
edia
Terra
Share
G
/
T
e
c
h
I/C
A
DI
/
.
.
In
Service Other
S
e
r
v
i
c
e
I
n
f
r
a
s
t
r
u
c
t
u
r
e
B
a
s
i
c
S
e
r
v
i
c
e
s
C
o
m
p
o
s
i
t
e
S
e
r
v
i
c
e
s
Smart Client
P
o
r
t
a
l SOA Management & Security
service mediation, routing, trust
enablement. ESB, Service Registry
Multi channel applications: Mobile,
Smart, Thin, Thick clients, Portals.
Business centric services,
orchestrated workflows.
Intermediate services (gateways,
facades )
Data centric and logic
centric consistent services.
Highly reusable, stateless
servers
Business
Capabilities

35. SOA Principles
 Standardized Service Contracts
 Loose Coupling
 Abstraction
 Reusability
 Autonomy
 Statelessness
 Discoverability
 Composability

36. Standardized Service Contracts
 “Services within the same service inventory
are in compliance with the same contract
design standards."
 Services use service contract to
 Express their purpose
 Express their capabilities
 Use formal, standardized service contracts
 Focus on the areas of
 Functional expression
 Data representation
 Policy
Source: Thomas Erl

37. Loose Coupling
 “Service contracts impose low
consumer coupling requirements
and are themselves decoupled
from their surrounding
environment."
 Create specific types of
relationships within and outside of
service boundaries with a
constant emphasis on reducing
(“loosening”) dependencies
between
 Service contract
 Service implementation
 Service consumers Source: Thomas Erl

38. Abstraction
 “Service contracts only contain essential information and information
about services is limited to what is published in service contracts”
 Avoid the proliferation of unnecessary service information, meta-
data.
 Hide as much of the underlying details of a service as possible.
 Enables and preserves the loosely coupled relationships
 Plays a significant role in the positioning and design of service
compositions
Source: Thomas Erl

39. Reusability
 “Services contain and express agnostic logic and can be
positioned as reusable enterprise resources."
 Reusable services have the following characteristics:
 Defined by an agnostic functional context
 Logic is highly generic
 Has a generic and extensible contract
 Can be accessed concurrently
Source: Thomas Erl

40. Autonomy
 "Services exercise a high level of control over their
underlying runtime execution environment."
 Represents the ability of a service to carry out its
logic independently of outside influences
 To achieve this, services must be more isolated
 Primary benefits
 Increased reliability
 Behavioral predictability
Source: Thomas Erl

41. Statelessness
 "Services minimize resource consumption by deferring the
management of state information when necessary."
 Incorporate state management deferral extensions within a service
design
 Goals
 Increase service scalability
 Support design of agnostic logic and improve service reuse
Source: Thomas Erl

42. Discoverability
 "Services are supplemented
with communicative meta data
by which they can be effectively
discovered and interpreted."
 Service contracts contain
appropriate meta data for
discovery which also
communicates purpose and
capabilities to humans
 Store meta data in a service
registry or profile documents
Source: Thomas Erl

43. Composability
 "Services are effective
composition participants,
regardless of the size and
complexity of the composition."
 Ensures services are able to
participate in multiple
compositions to solve multiple
larger problems
 Related to Reusability principle
 Service execution should efficient
in that individual processing
should be highly tuned
 Flexible service contracts to allow
different types of data exchange
requirements for similar functions Source: Thomas Erl

44. The Promise of SOA
 The Discoverable feature enables
 Faster decision cycles
 Increase cross-organizational information visibility
 Precision information retrieval
 Location Transparency
 Standards Based and Highly Interoperable
capability achieves
 Platform and language independent
 Leverage existing IT investments: Lower Cost
 Heterogeneity

45. The Promise of SOA
 Loosely Coupled and Decentralized nature
provides
 Plug and play components independent of
platform
 Enable redundancy for survivability
 Emphasis on business logic and less on
plumbing
 Reduced overall system complexity
 System Composability

46. SOA Security
“The computing field is always in need of new
clichés.”

47. Security in SOA
 Security is a pressing issue in SOAs
 SOA stresses machine-to-machine
interaction
 IT security is based on human-to-machine
interaction.
 Authentication and authorization become
more challenging in this environment.

48.  Unsecured SOA
 architecture's open nature
 hackers with the ability to eavesdrop and
reroute it or transform its content for
purposes of mischief or fraud
 Cannot secure unknown third parties
 Vulnerable to overload.
Security in SOA (Contd)

49.  No transaction logging
 Cannot keep track of its users or its
messages.
 No auditable record of usage that can be
used to investigate security problems or
diagnose security weaknesses.
Security in SOA (Contd)

50. SOA Security Solution
SOA security solution that enables
 Message monitoring
 Federated authentication
 Application proxy
 Contract management
 Certificates, keys, and encryption and
 Audit logging
Even though it looks like a long list, but the truth
is without any one of these in place, all the
benefits from SOA will evaporate.

51. SOA & Organization
“Computing is not about computers any more.
It is about living. ”

52. How might SOA transform an
organization?
 Building New Solutions With Services
 Independent Pieces Within Applications
 Independent Development and Maintenance
 Scale-Out
 Slicing Apart Existing Apps
 separate the “Big Ball of Mud”
 Joining Together Existing Apps
 Connectivity
 B2B: Business-to-Business
 EAI: Enterprise Application Integration
 Business Process

53. SOA Players

54. SOA – Non applicable scenarios
 Stable or homogeneous enterprise IT
environment
 Organization that does not offer or use software
functionality as services to and from external
parties
 Real time requirements that need synchronous
communications

55. Case Study – E-Banking
“Change is such hard work.”

56. Case study – E-banking
 Bank offers various financial services such as
 Online banking
 Bill payments
 Brokerage, etc.,
 Financial services are accessible through variety of
channels like
 Branch offices
 ATMs
 Call centers
 E-mails
 Internet
 A Service Oriented Computing Model for E-Banking
handles the agile scenarios of e-banking system

57. Achieving Service Abstraction in an
e-banking Scenario
Bank
server
Local
Data
server
Data
Mart
Host
Consumer
Broker

58. Case study – E-banking
Customer Regulatory
bodies
Branch Other banks
Core
financial
services
Payments
services
Mutual
fund
services
Bill payment,
presentment
services
Alerts and
messaging
services
Security
Services
Service
Broker
Service
Manager
SA
Agent
Service Registry Bank Server Knowledge
repositories
E-Banking Service Layer
Business
Layer
App.
Layer
Data
Layer
Service Management Layer

59. Application layer
 Illustrates client applications specific to
 Individual customers
 Corporate customers
 Self-supportive services for branch offices,
different section offices, etc.,
 Regulatory bodies and
 Other banks
 Takes advantage of services provided by
e-banking system

60. Business layer
 Set of components that constitute the actual
e-banking system
 E-banking service layer acts as the mediator
between client applications and the rest of the
system
 Service management layer is responsible for
generating and coordinating all the messages
within the system

61. E-banking Service Layer
 Core financial services
 Payments services
 Mutual fund services
 Bill payment & presentment services
 Alerts and messaging services
 Security Services

62. Service Management layer
 Service Broker receives service requests and
discover the services
 Service Manager is responsible for service life cycle
management
 Service Advisory Agent generate suggestions of
composition alternatives

63. Data layer
 Sources of information that support the e-
banking system
 Service Registry
 Data server
 Knowledge Repository

64. Future State of SOA
“Deserve your dream.”

65. Future State of SOA
 Combining mature technology with a proven
methodology will allow organizations to
transit from traditional enterprise automation
logic to SOA-based which achieve long-term
SOA benefits.
 The future state of SOA has the potential of
creating a new breed of “agile organization”.

66. References
 www.soasystems.com
 www.serviceorientation.org
 www.ibm.com/soa
 Eric A. Marks, Michael Bell, “SOA: A planning and
implementation guide for business and technology”, John Wiley
& Sons -2006
 Tony Chao Shan, “Building a service oriented eBanking
platform”, Proceedings of the 2004 IEEE International
Conference on Services Computing (SCC’04)