The document discusses enterprise application integration and related technologies. It begins with an introduction to enterprise applications and the benefits of integration. Common integration approaches are then described, including middleware, message-oriented middleware, enterprise integration patterns, and service-oriented architecture. The document also covers topics like SOA security, resource-oriented architecture, and API management.

1. ICTA Technology Meetup 01
Enterprise Application
Integration
By Crishantha Nanayakkara

2. Agenda
●
●
Enterprise Application Integraion – An Introduction
Enterprise Application Integraion Patterns and the
usage
●
Service Oriented Architecture (SOA)
●
SOA Security
●
Resource Oriented Architecture (ROA)
●
API Management
2

3. Enterprise
Applications?
3

4. Enterprise Applications
●
Enterprise Applications usually,
–
Involve “persistent data”
–
Have a lot of data
–
Accessed by many people “concurrently”
–
Can be integrated
–
Can interoperate
4

5. Enterprise
Application
Integration
An Introduction
5

6. The Information Silos
Systems that are not connected
Drawbacks:
Isolated without insufficient
communication to the rest of the
world
●
6

7. The Enterprise Integration
Benefits:
Provides a way to connect each
other
●
Drawbacks:
Extremely “Spaghetti” like
architecture, create headaches
●
7

8. The Enterprise Integration

9. Point-to-Point Integration
9

10. Point-to-Point Integration
Specifically, linking every component to every other
component will require N(N-1)/2 physical connections
N = Total Number of Components in the Network
e.g: If there are 10 components in the network,
Total number of physical connections = 10 (10-1)/2
= 45
10

11. Point-to-Point Integration
●
The value of the network increases linearly over time
while its costs increase exponentially
11

12. Point-to-Point Integration
●
Maintaining trust between clients and services can be
difficult with the number of keys to be maintained
12

13. Point-to-Point Integration
13

14. So how we do we resolve this?
14

15. Middleware
15

16. What is “Middleware”?
Types of middleware
–
Object Oriented Middleware (OOM)
–
Message Oriented Middleware (MOM)
16

17. Message Oriented Middleware
(MOM)
17

18. Message Oriented Middleware
(MOM)
●
●
●
This creates a loosely-coupled distributed system
Such a system can continue to function reliably,
without downtime, even when individual
components or connections fail
Examples:
●
IBM MQSeries, Sun JMS, Microsoft MSMQ
18

19. Messaging Systems - Benefits
●
Supports Remote Communications
●
Ability work as a message bus
●
Supports Asynchronous Communication
●
Supports Throttling (Controlling the rate at
which the receiver consumes the requests)
●
More reliable
●
Can be used for disconnected operations
●
Supports mediation
19

20. Messaging Systems - Issues
●
●
●
●
Complex Programming Model
Sequence Issues – There is no guarantee of
the message delivery sequence
All the transactions cannot be asynchronous.
(Airline booking system should be more
synchronous than asynchronous)
Not suited for syncing systems with big
chunks of data.
20

21. Most of the enterprise integrations are based on
message oriented design patterns
which are known as
Enterprise Integration Pattens
21

22. Enterprise
Integration
Patterns
(http://www.eaipatterns.com)
http://www.eaipatterns.com)
65 Patterns
22

23. 23

24. Enterprise Integration Patterns
Message Router
Pipes and Filters
24

25. Enterprise Integration Patterns
Content Based Router
Message Translator
25

26. Enterprise Integration Patterns
Message Filter
Message Splitter
26

27. Enterprise Integration Patterns
Message Aggregator
Message Resequencer
27

28. Enterprise Integration Patterns
28
Source: http://www.idevnews.com/views/images/uploads/general/talend_intfactory.jpg

29. The integrated SOLUTION
29

30. Service Orientated
Architecture
(SOA)
30

31. A Typical SOA Environment
Service Description
Service
Registry
Fi
nd
h
is
bl
Pu
Service
Consumer
Bind
Service
Provider
Web Service
31

32. The SOA Environment
Source: Open Source SOA
32

33. Lanka Gate: A Typical SOA
Environment
Portlet Applications
Application
Services
Citizens
Private Sector Companies
Credit Card
Payment Service
Mobile Portal
Country Portal
Private Sector
VPN
Lanka Gate
Lanka Gate
Mobile Service
Providers
Lanka Government
Network
Certificate
Authority
Services
Services
Services
Services
Application
Application
Application
Application
33

34. A typical SOA environment
●
Service Interfaces/ Contracts
●
Service Transparency
●
Service Composition
●
Service Registry or Publication
●
Service Governance
34

35. The Core Characteristics of SOA
1) The Service Interface / Contract
35

36. The Core Characteristics of SOA
2) The Service Transparency
What if you change
the IP of this
address???
36

37. The Core Characteristics of SOA
2) The Service Transparency
37

38. The Core Characteristics of SOA
3) Service Composition
–
There are two general types of composite services
●
Simple
●
Complex
–
Simple: Simply wraps one or more lower­level
services together into a more coarse­grained operation
–
Complex: (Work Flow Type BPM)
●
●
WS­BPEL
Entry Point of invoking WS­BPEL is usally a web
service
38

39. The Core Characteristics of SOA
3) Service Composition
39

40. The Technologies of SOA
40

41. SOA
Security
41

42. Transport vs Message
Level
Security
42

43. Transport Vs Message Level
Security
43

44. WS-Security
The standard framework for including XMLformatted security data into SOAP messages is
called WS-Security
44

45. WS-Security
●
●
The same cryptography techniques (Confidentiality,
Integrity, Non-repudiation and Authentication) are
applied in the web services security stack as well
It basically provides a XML based Abstraction Layer
for the above established cryptography techniques
45

46. WS-Security
46

47. WS-Security
●
●
●
Transport level security is completely independent
of message level security.
For example, in order to have the message level
security, it is not required to have a HTTPS secured
message channel.
But if all you need to do is keep messages
confidential between point A and point B, using SSL
is perfectly sufficient
47

48. WS-Security
●
How does WS-Security handles Authenticity,
Integrity, Non-Repudiation and Confidentiality?
–
Security Tokens are used for Authenticity
–
XML Signature is used for Integrity and NonRepudiation
–
XML Encryption is used for Confidentiality
48

49. WS-Security Stack
49

50. WS-Security Stack
50

51. Point-Point vs End-End
Security
51

52. Point to Point Security
ESB as a Security Gateway
52

53. End to End Security
with Pass Through
53

54. End to End Security
with Security Translantion at ESB Level
54

55. End to End Security
with Security Translantion at ESB Level
55

56. Federated Identity
Management with SAML
56

57. The Federated Identity
●
SAML provides a loosely coupled identity management with the
help of WS-Trust and WS-Fedeartion specifications.
57

58. Resource Oriented
Architecture (ROA)
58

59. An Introduction
●
●
ROA consists of REST based web services
Resource Oriented services focus on distinct
data objects upon which a handful of basic,
standard operations can be performed
–
Retrieving the resources (GET)
–
Modifying the resources (POST)
–
Creating new resources (PUT)
–
Deleting resources (DELETE)

60. SOAP Web Services
Cons
Pros
●
●
●
●
Language, Platform and
Transport agnostic
Designed to handle in
distributed environments
●
●
More difficult and more
“heavy-weight” than REST
Harder to develop. Require
tools or frameworks
Better usage of WS*
standards
Built in error handling
features
●
Highly Extensible
●
Suitable for end-end security
60

61. REST Web Services
Cons
Pros
●
●
●
●
Language and Platform
agnostic
Much simpler to develop
than SOAP
Small learning curve. Less
reliance to tools/ frameworks
Unlike SOAP, no need of
having an additional
messaging layer
●
●
●
Not transport agnostic.
Supports only HTTP
transports
Only good at point-point
communication model
Lack of standards support
for security, policy, reliable
messaging, etc
61

62. API Management
62

63. Source: WSO2 API Management Quick Start Guide
63

64. API Management
●
●
●
API Gateway - To secure, manage, protect
and scale API calls
API Publisher – Enabling platform for API
Providers / developers
API Store – Enable service consumers to selfregister and discover existing APIs
64

65. 65