C4: Common Applications of Sonic

1
C4 Common Applications of Sonic ESB
Mike Ormerod
Applied Architect
2
Goal

• Understand the various use-cases
• Common Development Patterns
• Development Best Practices to allow all to be
  developed at will.
• All the scenarios can be solved using a common
  approach that promotes reuse
• Demonstrate solution without custom code

3
Agenda

• Batch to Real-time
• Remote Information Access/Distribution
• Respond to Real-time events
• Conclusion

4
Batch to Real-time
Challenges

• Interaction mismatch
• Existing channels using Batch, backend real-time
• 24 hour batch cycles causing competitive issues
• Caused by businesses becoming 247
• Single error causes whole batch to be rejected,
  no time for reprocessing
• Same data sent multiple times to different
  backend systems
• Maybe over distributed environment

5
Scenario Daily Batch of Account Information

• 24 hour cycle
• Same data fed to all databases
• Tight coupling of database schema to transport

Phone
New Account Application
Internet
Location-1
Location-2
6
Batch to Real-time Logical Deployment
Location 1
Location 2
7
Breaking Down the Problem for Developers

• Breakdown solution into separate
  problems/projects
• Projects scoped to tasks and visibility
• Two types of project
• Connection hides connectivity implementation to
  Back end
• Mediation provides logical entity on the ESB

8
Operation Add Account
9
Routing to the Appropriate Connection
10
Routing to the Appropriate Connection
11
Sample Connect Project
12
Sample Connect Project
13
Sample Connect Project
14
Sample Connect Project
15
Sample Connect Project
16
Sample Connect Project
17
Sample Connect Project
18
Returning from the update
19
Connections and Connection Project

• Implement each individual method as an ESB
  process e.g.
• AddAccount
• DeleteAccount
• Hides Underlying Platform from other ESB Services
• Therefore can change platform implementation but
  ESB remains the same

20
Deployment

• Connection services located near connected system
• Entity services located in 1.. number of
  locations based on access.

21
Conclusion Batch to Real-time

• Targeted projects based on developers skills and
  knowledge
• Artifacts are specific to context of usage not
  the overall problem
• This will allow reuse

22
Agenda

• Batch to Real-time
• Remote Information Access/Distribution
• Respond to Real-time events
• Conclusion

23
Remote Information Access/Distribution

• Leveraging artifacts from Batch to Realtime
• Routing patterns used
• Content Based Router
• Recipient List
• Aggregation techniques
• Data Validation and Enrichment

24
Remote Information Access/Distribution

• Challenges
• Provide external systems and users with
• Single access to read/write across multiple
  back-ends
• Back-ends may change during project and over
  time.
• Providing support to multiple teams
• Portal/UI development team need interfaces today
  to generate Look and Feel
• Back-end team maybe changing applications at the
  same time

25
Scenario Portal to End User

• Providing single view of all data (Read)
• Real-time update of backend (Write)

ESB
Internet
Phone
26
RIA/RDD Solution
27
Portal Project and High Level Flow
28
Portal Project and High Level Flow
29
Individual Request
30
Individual Request
31
Individual Request
32
Individual Request
33
Portal Project and High Level Flow
34
Agenda

• Batch to Real-time
• Remote Information Access/Distribution
• Respond to Real-time events
• Conclusion

35
Respond to Real-time events

• Event based integration
• Process is implicit rather than explicit
• Federated Deployments
• Lower cost of integration
• Dynamic Deployments
• Applications/Services plugging in/out ESB

36
Solution Consists of 3 items

• Event Backbone
• The ability to move events to various
  applications
• Event Consumer
• Proxy to the actual application's that are
  consuming the events
• Note this would be in front of Apama/BPEL etc
• Event Producer
• How events are sent to the Event Backbone

37
Event Backbone

• Simple ESB process allows simple VET in channel
• Decouples topic of publisher and consumer
• Channel unaware of consumers
• Consumers can be changed with no affect on the
  channel

38
Event Consumer

• Proxy to consuming application
• Consumes and directs events as required
• May add transformation to move from canonical
  format to target
• Entry point into ESB process is a MultiTopic
• Allows multiple event types to be consumed with
  NO application logic change
• Proxy maybe reloaded on behalf of the consuming
  application.
• Therefore application does not need to be changed

39
Event Consumer
40
Event Router

• Router of On-Ramp to Event Backbone

41
Agenda

• Batch to Real-time
• Remote Information Access/Distribution
• Respond to Real-time events
• Conclusion

42
Summary

• One set of deployments for multiple project types
• Reuse of artifacts to reduce implementation time

43
Conclusion

• Artifacts built for one solution can be reused
  across solution types
• Little to no code is required
• ESB supports both SOA and EDA paradigms

44
?
Questions
45
Thank You
46
(No Transcript)