ICTA Technology Meetup 01 - Enterprise Application Integration

1,038 views

Published on

Enterprise Application Integration

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,038
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
35
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

ICTA Technology Meetup 01 - Enterprise Application Integration

  1. 1. ICTA Technology Meetup 01 Enterprise Application Integration By Crishantha Nanayakkara
  2. 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. 3. Enterprise Applications? 3
  4. 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. 5. Enterprise Application Integration An Introduction 5
  6. 6. The Information Silos Systems that are not connected Drawbacks: Isolated without insufficient communication to the rest of the world ● 6
  7. 7. The Enterprise Integration Benefits: Provides a way to connect each other ● Drawbacks: Extremely “Spaghetti” like architecture, create headaches ● 7
  8. 8. The Enterprise Integration
  9. 9. Point-to-Point Integration 9
  10. 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. 11. Point-to-Point Integration ● The value of the network increases linearly over time while its costs increase exponentially 11
  12. 12. Point-to-Point Integration ● Maintaining trust between clients and services can be difficult with the number of keys to be maintained 12
  13. 13. Point-to-Point Integration 13
  14. 14. So how we do we resolve this? 14
  15. 15. Middleware 15
  16. 16. What is “Middleware”? Types of middleware – Object Oriented Middleware (OOM) – Message Oriented Middleware (MOM) 16
  17. 17. Message Oriented Middleware (MOM) 17
  18. 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. 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. 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. 21. Most of the enterprise integrations are based on message oriented design patterns which are known as Enterprise Integration Pattens 21
  22. 22. Enterprise Integration Patterns (http://www.eaipatterns.com) http://www.eaipatterns.com) 65 Patterns 22
  23. 23. 23
  24. 24. Enterprise Integration Patterns Message Router Pipes and Filters 24
  25. 25. Enterprise Integration Patterns Content Based Router Message Translator 25
  26. 26. Enterprise Integration Patterns Message Filter Message Splitter 26
  27. 27. Enterprise Integration Patterns Message Aggregator Message Resequencer 27
  28. 28. Enterprise Integration Patterns 28 Source: http://www.idevnews.com/views/images/uploads/general/talend_intfactory.jpg
  29. 29. The integrated SOLUTION 29
  30. 30. Service Orientated Architecture (SOA) 30
  31. 31. A Typical SOA Environment Service Description Service Registry Fi nd h is bl Pu Service Consumer Bind Service Provider Web Service 31
  32. 32. The SOA Environment Source: Open Source SOA 32
  33. 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. 34. A typical SOA environment ● Service Interfaces/ Contracts ● Service Transparency ● Service Composition ● Service Registry or Publication ● Service Governance 34
  35. 35. The Core Characteristics of SOA 1) The Service Interface / Contract 35
  36. 36. The Core Characteristics of SOA 2) The Service Transparency What if you change the IP of this address??? 36
  37. 37. The Core Characteristics of SOA 2) The Service Transparency 37
  38. 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. 39. The Core Characteristics of SOA 3) Service Composition 39
  40. 40. The Technologies of SOA 40
  41. 41. SOA Security 41
  42. 42. Transport vs Message Level Security 42
  43. 43. Transport Vs Message Level Security 43
  44. 44. WS-Security The standard framework for including XMLformatted security data into SOAP messages is called WS-Security 44
  45. 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. 46. WS-Security 46
  47. 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. 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. 49. WS-Security Stack 49
  50. 50. WS-Security Stack 50
  51. 51. Point-Point vs End-End Security 51
  52. 52. Point to Point Security ESB as a Security Gateway 52
  53. 53. End to End Security with Pass Through 53
  54. 54. End to End Security with Security Translantion at ESB Level 54
  55. 55. End to End Security with Security Translantion at ESB Level 55
  56. 56. Federated Identity Management with SAML 56
  57. 57. The Federated Identity ● SAML provides a loosely coupled identity management with the help of WS-Trust and WS-Fedeartion specifications. 57
  58. 58. Resource Oriented Architecture (ROA) 58
  59. 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. 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. 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. 62. API Management 62
  63. 63. Source: WSO2 API Management Quick Start Guide 63
  64. 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. 65

×