The document discusses the integration of mobile applications with event-driven architectures using IBM MessageSight to improve customer interactions and reduce backend costs. It highlights the challenges of existing mobile interaction technologies and introduces IBM's messaging solutions that optimize notification delivery while ensuring security and reliability. These solutions enable near real-time communication, supporting a high volume of connected devices and enhancing the overall user experience.

1. Enrich Mobile Applications
using Event Driven
Architectures and IBM
MessageSight : 3495
Phil Coxhead
Certified Consulting IT Specialist
European Technical Sales
IBM Hursley

2. Agenda for the Session
• What do we want to achieve in the mobile channel?
• How are we inhibited in achieving those aims?
• Why can event driven architectures help?
• What patterns for integration exist?
• How can I leverage events in my Systems of Record?

3. New Customer Interaction Points
Devices & Mobiles will be the touch points driving new revenue streams

4. 50Bn Connected Devices by 2020
4Q 2013, Dept store
drives 32% of sales online1.8Bn New Smartphones in 2013
Tablets outnumbered PC
sales in 4Q 2013
The World is Changing…

5. Branded Mobile Channel Opportunities
• Branded Mobile platforms lead the way in engaging customers
with a branded mobile user experience
• Single point of self-service enveloped in the brand
• Provide a “better than in the branch” customer experience while reducing
backend support costs
• Great for ‘pull’ (customer initiated) interactions
• “Transfer funds”, “Deposit this check”, “Show my account balances”, etc.
• Not so great (and potentially costly) for B-to-C interactions where
the organization needs to reach out to the customer
• Real time debit/credit card transaction notification
• Fraud/abnormal account activity alerts
• Account balance notifications (based on triggers)

6. Branded Mobile Channel Challenges
• Interactions that take place outside of the Branded app user experience
diminish the experience’s value and increase costs
• Existing mobile interaction (B2C) technologies are costly, insecure, and
have no integration into the “branded” app experience
• Native Mobile Platform Notification Services (APNS, C2DM, etc.): Lack
confidentiality protection for PII and other confidential info (account numbers,
account balances, transaction IDs, etc.) and have no QoS/reliability
– “Native notification services are great for announcing news levels for ‘Angry Birds’ but you
can’t run your business on them…”
• E-Mail: Lacks confidentiality protection, QoS/reliability, and integration into UX
• SMS: Costly, insecure, and doesn’t integrate into the user experience
• Call Center outcall: Extremely costly
• SMS is most commonly chosen mechanism of customer interaction
based on ‘best mix’ of Cost, QoS, and platform coverage, but
• VERY COSTLY – organizations can spend millions yearly in SMS charges
• SMS doesn’t integrate into the branded app experience on nearly all
smartphone platforms

7. “How do I save on the costs I spend for
SMS notifications for my Branded Retail
Mobile Banking application while ensuring
my customers never have to leave my
Branded Retail Mobile Banking user
experience when I interact with them?”

8. • Simple request/response model
• Data from known source
• Available on any tablet, laptop, phone, PC
• Slow and unreliable on mobile networks
• Requires a real-time, event-driven model
• Publishing information one-to-many
• Listening for events as they happen
• Sending small packets of data in huge volumes
• Reliably pushing data over unreliable networks
Mobile and IoT applications have
additional challenges
HTTP revolutionized how we
consume data
Why Messaging for Mobile Communication

9. HTTP has limitations
• Designed for document retrieval
• Follows the human task-driven model: Ask for (or give)
something and get a response
• No bi-directional interactivity: Client always has to ‘act first’. Back
end applications can’t initiate interactions with clients.
• No reliability: You get what you ask for or you get an “Error”. Error
handling is ad-hoc, problematic, and increases support costs.
• No transactional capability: What do you your connection stalls?
Try again? Cancel? “Don’t hit that Submit button twice!”
• Not optimized for fast user experience
• No mobile optimization
• Far too much data overhead, especially for small interactions
• No real time interaction capability; everything request/response

10. Optimized Mobile Messaging
• Disruptive technology for dramatically reducing or eliminating reliance
on SMS for organization initiated interactions to smartphone platforms
• Deliver near real time notifications from organization Systems of Record
directly to customers in your branded Mobile app user experience
• Secure notification, direct to the device; no confidential data over 3rd-party networks
• Optimized for mobile to use less network bandwidth and increase battery life
• Built-in QoS, including Once and Only Once assured delivery
• Supports large numbers of concurrently connected devices, including presence
detection, with no ‘per-connection’ charges
• Based on Open Standards; integrates directly into your branded Mobile
app experience (Native, HTML5 or Hybrid)
• Works with Android, iOS, Windows Phone, BlackBerry, etc.
• Target notifications to individual handsets, groups, or many with a single
message from backend systems

11. • Extends IBM’s Messaging leadership to the Internet
for mobile applications and the Internet of Things
• Optimized to reduce data costs, power requirements
and operational costs while bring a better/faster user
experience to the mobile application and device
worlds
• IBM’s proven OpEx-saving appliance form factor
• Based on open standards
• Optimized connectivity for
Mobile Applications and
devices
• Efficient open protocol
• Event-driven responsiveness
• Open and industry agnostic
• Fine-grained security policies
• Active dev community
• Free dev virtual appliance
• Simple yet powerful APIs
• Quick ramp messaging
paradigm
• 40+ MQTT clients for all
platforms
• Up and running < 30 minutes
• Task oriented web-based UI
• Designed to be operated in
the data center with the skills
of personnel who operate
routers and other network
gear
• Hardened Appliance Form
Factor driven by secure
firmware that can’t be
tampered
• No user-visible OS
• Can’t be compromised by 3rd-
party code
• Much more inexpensive to
maintain than servers
• JMS
• WebSockets
• MQ
• Integration Bus
• Worklight
• InfoSphere Streams
• Workload balancing across
Application Servers
• 13M non-persistent msg/sec
• 400K persistent msg/sec
• 1M concurrent connections
• Predictable microsecond
latency under load
• Highly available
Designed
for Mobile
Apps and
Devices
Developer
Friendly
Internet
Scale
Integrates
Reduce
OpEx
Costs
Proven IBM
Appliance
Platform
IBM MessageSight
Introducing IBM Message Sight

12. MessageSight [Primary]
MessageSight [Standby]
Mobile
Android
Mobile
iOS
Mobile
Tablet
MQTT
MQTT
MQTT over
websockets
MQTT over
websockets
MQTT
MQTT
MQTT
DMZ
Sensor
(Embedded C)
Sensor
Sensor
JEE Server
(WAS)
JEE Server
(WAS)
Resource
Adapter
JMS IBM
Worklight
MQTT
MQ
C
Application
IBM MQ
System Admin
Browser
Internet Intranet
IBM Message Sight - Connectivity

13. Action HTTP MQTT
Get single piece of data 302 bytes 69 bytes (<4 times)
Send single piece of data 320 bytes 47 bytes (<6 times)
Get 100 pieces of data 12600 bytes 2445 bytes (<5 times)
Send 100 pieces of data 14100 bytes 2126 bytes (<6 times)
Characteristics HTTP MQTT
Style Document-centric, request/response Data-centric, publish/subscribe
Verbs GET/POST/POST/DELETE, complex spec Pub/Sub/Unsub, simple protocol, easy to learn
Message size Large message, lots of data in headers 2 bytes in minimum header
Quality of Service None, requires custom coding in application 3 levels – best-effort, at-least-once, exactly once
Data distribution No distribution mechanism (1-to-1 only) Fully supported. 1-to-none, 1-to-1, 1-to-n.
MQTT is optimized for wireless
Optimizing network with event-driven communication

14. Device Application Considerations
• Is this a consumer application for “on-demand” or “ad-hoc” usage?
• use-cases for interactions through the application when running
• alternative channel for notification or wakeup generally needed
• Capabilities in native devices differ and assumed to continue to do so
• notifications and features
• programming models
• Is HTML5 and browser based the chosen interface?
• Applications for controlled and specific environments (eg: B2E)
• always active by implication or design
• interaction portal of choice

15. Patterns

16. Pattern – Fan Out Broadcast
• Single MQTT publisher application or component writes (publishes) a
message to a specific topic
• Multiple (zero or more) subscriber applications or components have
subscribed to that topic (or a topic which matches it)
• The publication is “broadcast” to all the subscribers
• Examples:
• Sports scores published by an event management system for consumption by web
portal and mobile applications
• Law enforcement officer uses mobile application to warn of situation to command
centre and other officers in division or locality

17. Pattern – Fan In per Device Notification
• Multiple MQTT publisher applications or components write (publish) a
message to a specific topic
• Single MQTT subscriber application or component has subscribed to that
topic (or a topic which matches it)
• The publications are “broadcast” to the subscriber
• Examples:
• Customer uses mobile app to rate satisfaction with service dynamically
• Smart trashcan publishes whether it is becoming full to the owning waste
management company who can alter the collection schedule for a efficient service

18. Pattern – Fan Out per Device Notification
• Single MQTT publisher application or component writes (publishes)
messages to defined set of topics, generally unique by subscriber entity
• Multiple subscriber application or components are each subscribing to
one of those known unique topics
• Examples:
• Passenger receives information on mobile application about aircraft boarding status
• Warehouse manager uses mobile application to communicate with staff in building

19. Example – Fan Out per Device Notification

20. Native Notifications – a real example

21. Native Notifications – a real example
• This feature is aimed at improving customer
experience, which is a good thing. However,
let’s consider what this notification tells us…
• Why is the time it was sent important?
• Well, we can determine it took around 3
minutes to receive it…
• …and including the sent time confirms the
mobile developer knows they have no
control over how long it will take to be
delivered
• What will a delayed or lost notification do to
the customer experience for something
important like making a flight?...

22. Pattern – Fan In per Device Request Reply
• Multiple MQTT publisher applications or components write (publish)
“request” messages to different topics, unique by publisher entity
• Single MQTT subscriber application processes messages and publishes a
“reply” message to a topic logically associated with the original
• Example:
• mobile app makes request requiring data or acknowledgement where there is some
latency and/or the delivery should be asynchronous

23. Example – Fan In per Device Request Reply

24. Pattern – Fan Out per Device Request Reply
• Single MQTT publisher application or component writes (publishes)
“request” messages to different topics
• Multiple subscriber application or components each subscribe to a request
topic for domain of interest, process a message and publishes a “reply”
• Example:
• mobile app requests to multiple subscribers and requires data or acknowledgement
where there is some latency and/or the delivery should be asynchronous

25. IBM MessageSight
Internet Scale
device
connectivity
Traditional back-
end systems
Support for JMS
shared subscriptions
allows distribution of
workload amongst
Application Servers
Shared Subscriptions and Workload Balancing

26. • Provides a way to notify disconnected clients that messages have arrived
• Often, mobile apps running in the background may not be able to maintain a
persistent TCP connection
• With durable subscriptions, when the app reconnects messages will be
delivered
• this requires the user to bring the app back into the foreground
• When a message arrives for a disconnected client, MessageSight can publish
an event on a special topic
• These events can be consumed and use a side notification scheme to notify
the mobile app
• common mechanisms include SMS, Apple APNS, Google GCM
Disconnected Client Notifications

27. Event Identification and Generation
• Where is the “correct” source of the event information for the mobile channel?
• what uniquely represents the business event or “transaction”
• should (must?) the event be part of a real transaction?
• do I have components in my architecture that can facilitate event production
• Such events may originate from:
• business processes (eg: BPEL)
• application integration (eg: A2A) solutions
• existing applications running in a range of environments
• How can I most easily leverage the information?
• what solution enables me to generate events with minimal change?
• existing data (messages) are likely to be in different formats
• and those formats are probably not suitable for a mobile channel
• how, and where, do I transform into a common event format?

28. Architectures

29. Example Architecture
• Existing events are to be
derived from business
logic in back-office
applications or systems
• Leverage an existing
component which
already integrates event
messages if possible
• Component to integrate
with MessageSight may
need to be introduced
• Assumes that no other
notification mechanism is
required

30. Optimized Mobile Messaging
IBM MessageSight
Mobile Optimized
Messaging
1) Existing Account Management
infrastructure identifies event
necessitating handset alert
Integration
Platform
2) Integration
Platform receives
notification
requests, matches
destination to
relevant customer
handset topic(s)
3) SMS delivery to non-smartphone
handsets or handsets without
Branded Mobile app installed
4) Delivery to relevant Mobile Optimized
Messaging topic(s) for reliable delivery
to Branded App on handset(s)
5) Notification(s) delivered securely/reliably via IBM Optimized
Mobile Messaging to Branded App on each online handset –
Branded Mobile App controls notification UX in the Branded
Mobile App
6) PRESENCE DETECTION: Offline handset
Branded App alerts Integration Platform to
natively launch/wakeup Branded App(s) on
the handset (iOS7)
7) Integration Platform natively wakes up offline Branded Apps on the
handset (if required) using native facilities
External Native 3rd-
Party Notification
Service
(APNS, C2DM, etc.)
8) Native Notification (containing no confidential information) delivered to
silently launch/wakeup app on the handset. Branded App wakes up,
connects to IBM Optimized Mobile Messaging, and immediately receives
all notifications for display in Branded Mobile App user experience
SubscriberHandset
* Remote Notification capability varies by handset platform and OS version
CoreBankingSystem
Use case example for Branded Retail Banking

31. APIs and Events Combine in Scenarios
Service
Provider
Integration
Server
DMZ ApplicationIntegration Layer
Security Layer
Secure
Gateway
Mobile
Device
API
Manager
• APIM securely expose existing services to external
• Can expose existing SOAP / REST services
• Easily transform to JSON and reformat response
• APIM supports self-service, policies and analytics
REST/HTTP
MessageSight
JSON/HTTP
Event
ProducerMQTT/TCP
JSON/HTTP
REST/HTTP
SOAP/HTTP
???
???MQ/MQTT/JMS

32. Application Tier Middleware Tier
App 1
App 2
MQ
Queue Manager
MessageSight
Application environments may be well suited
to a integration through MQ (platform, API)
MQ application skills available
MQ infrastructure may exist which can be
used or extended
Applications take responsibility for creating
messages in the correct format and client
identification
Styles of messaging (queue, pubsub) is an
important design choice
Branded
App
Environment B
Environment A
Mobile Device
DMZ
Leverage Messaging Infrastructure
Use MQ network to facilitate integration of events from Systems of Record

33. Optional extension to handle disconnected clients
Application Tier Middleware Tier
App 1
App 2
MQ
Queue Manager
MessageSight
Although an optional extension, may be
essential for certain use cases
Custom service for handling knowledge of
disconnected clients and integrating direct
to native or other notification services
(APNS, GCM, SMS…) or to other solutions
Service may integrate through IBM
Worklight to handle such notifications
Service needs to have knowledge about the
device identity and device platform
How does the custom service get
managed?
Branded
App
Environment B
Environment A
Mobile Device
DMZ
Service
X
SMS
GCM,
APNS,
SMS
Worklight
Leverage Messaging Infrastructure

34. Use Integration Bus to receive new events or intercept existing ones
Application Tier Middleware Tier
App 1
App 2
Integration Bus MessageSight
Applications may already exchange events
of interest using A2A patterns
Those implementations can be enhanced to
generate events to the mobile channel
(framework, modification, event
configuration)
Applications can integrate events more
easily through “traditional” ESB usecase
Branded
App
Environment B
Environment A
Mobile Device
DMZ
App 3
Environment C
Message Flow
FTP, File, HTTP …
MQ, HTTP, SAP …
Format=X
Format=Y
Message FlowFTP, File, HTTP …
Format=Z
JMS,
MQ,
MQTT
JSON?
JSON?
Leverage Integration Infrastructure

35. Optional extension to handle disconnected clients
Application Tier Middleware Tier
App 1
App 2
Integration Bus MessageSight
Again, although an optional extension, may
be essential for certain use cases
Service implemented as an IIB message
flow and managed in the same way as other
integrations
Branded
App
Environment B
Environment A
Mobile Device
DMZ
App 3
Environment C
Message Flow
FTP, File, HTTP …
MQ, HTTP, SAP …
Format=X
Format=Y
Message FlowFTP, File, HTTP …
Format=Z
JMS,
MQ,
MQTT
JSON?
JSON?
X
Service
SMS
GCM,
APNS,
SMS
Worklight
Leverage Integration Infrastructure

36. Example approach when deploying IBM Worklight
Use of JMS enables one to leverage the
integration through MQ, IIB or WAS
Other options likely to have similar approach
This is the standard asynchronous approach
for delivery of notification data
JMS appropriate an event driven paradigm
Worklight Integration with Native Push

37. Services exposed on the ESB may be an appropriate event source
Application Tier Middleware Tier
Consumer
Integration Bus MessageSight
In a SOA solution, the exposed business
services may represent the best
encapsulation of an event of interest to a
mobile channel (eg loanApproved())
Those implementations can be enhanced to
generate events to the mobile channel
(framework, modification, event
configuration)
Branded
App
Environment A
Mobile Device
DMZ
Provider
Environment C
Message Flow
MQ, HTTP …
SOAP, XML, REST
JMS,
MQ,
MQTT
JSON?
MQ, HTTP …
SOAP, XML, REST
Leverage SOA Infrastructure

38. Handle events from other vendor platforms
Application Tier Middleware Tier
App 1
Integration Bus MessageSight
Existing application environments may be
suited to Java integration, possibly using a
J(2)EE environment from another vendor
Those environments may not have any (or
rich) transformation features and therefore
ESB features are needed
IIB acts as a bridge between the two JMS
providers, either for queue or topic based
pubsub interactions.
Either pattern can map directly with the
necessary transformation in a bi-directional
manner.
Branded
App
Provider A
Mobile Device
DMZ
App 2
Provider B
Message FlowJMS …
Format=X
Message FlowJMS
JMS,
MQ,
MQTT
JSON?
JSON?Format=Y
Integrate Events from other JMS Providers

39. What approaches are needed for concurrency and integrity
Application Tier Middleware Tier
App 1 MessageSight
For HA and scalability reasons it is typical to
deploy flows to a “cluster” of integration
servers (either same or different node)
This pattern is not appropriate for subscriber
flows since this will result in duplicate /
multiple publications being processed
Consider active / passive or use the global
shared subscriptions in 1.2
Deploy multiple subscriber flows to exploit
the topic design and ability to execute more
workload in parallel
Multi-threaded message flows?
Branded
App
Provider A Mobile Device
DMZ
Message FlowJMS Q,??? …
Message Flow
JMS,
MQTT
Integration Server
Integration Server
JMS Q,??? …
Subscriber Considerations in Integration Bus

40. Application Server
Direct inbound and outbound communication
Data Tier Middleware Tier
EJB
MessageSight
Application business logic exists within the
IBM JEE environment and hence the
integration of mobile event interactions
might be closely coupled to this.
Inbound integration using an MDB which is
configured using supplied Resource Adapter
Other JEE components can send or receive
synchronously from MessageSight.
Both Queue and PubSub are appropriate
Ability to transform into desired mobile
message format must be considered.
Branded
App
Mobile Device
DMZ
JEE App
Component
MDB
JMS
???
???
JMS
Integration with WebSphere Application Server

41. What approaches are needed for concurrency and integrity
Data Tier Middleware Tier
EJB
MessageSight
Ordinarily, configuring for more than a single
MDB consumer will result in all receiving the
same copy of a publication
Using shared subscriptions will avoid this
since multiple consumers can be attached
to the same subscription
Within a cluster, concurrency can be
achieved by configuring the activation
specification at cluster scope
It is also possible to have multiple MDB per
server, so design accordingly to maximize
the concurrent workload
Branded
App
Mobile Device
DMZ
MDB
JMS
Application Server
EJB MDB
Application Server
Cluster
JMS
Subscriber Consideration with WAS

42. References
• Building Real-time Mobile Solutions with MQTT and IBM MessageSight, SG24-
8228
http://www.redbooks.ibm.com/abstracts/sg248228.html
• Building Smarter Planet Solutions with MQTT and IBM WebSphere MQ
Telemetry, SG24-8054
http://www.redbooks.ibm.com/abstracts/sg248054.html
• Responsive Mobile User Experience Using MQTT and IBM MessageSight,
SG24-8183
http://www.redbooks.ibm.com/abstracts/sg248183.html
• IBM MessageSight product web page
http://www-03.ibm.com/software/products/en/messagesight
• IBM MessageSight announcement letter
http://ibm.co/1xo29rP
• IBM MessageSight Knowledge Center
http://ibm.co/1oVGLaz

43. Summary
• What do we want to achieve in the mobile channel?
• How are we inhibited in achieving those aims?
• Why can event driven architectures help?
• What patterns for integration exist?
• How can I leverage events in my Systems of Record?

44. Notices and Disclaimers
Copyright © 2015 by International Business Machines Corporation (IBM). No part of this document may be reproduced or
transmitted in any form without written permission from IBM.
U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with
IBM.
Information in these presentations (including information relating to products that have not yet been announced by IBM) has been
reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM
shall have no responsibility to update this information. THIS DOCUMENT IS DISTRIBUTED "AS IS" WITHOUT ANY WARRANTY,
EITHER EXPRESS OR IMPLIED. IN NO EVENT SHALL IBM BE LIABLE FOR ANY DAMAGE ARISING FROM THE USE OF
THIS INFORMATION, INCLUDING BUT NOT LIMITED TO, LOSS OF DATA, BUSINESS INTERRUPTION, LOSS OF PROFIT
OR LOSS OF OPPORTUNITY. IBM products and services are warranted according to the terms and conditions of the
agreements under which they are provided.
Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without
notice.
Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are
presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual
performance, cost, savings or other results in other operating environments may vary.
References in this document to IBM products, programs, or services does not imply that IBM intends to make such products,
programs or services available in all countries in which IBM operates or does business.
Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not
necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither
intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation.
It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal
counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s
business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or
represent or warrant that its services or products will ensure that the customer is in compliance with any law.

45. Notices and Disclaimers (con’t)
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products in connection with this
publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM
products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.
IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to
interoperate with IBM’s products. IBM EXPRESSLY DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED,
INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE.
The provision of the information contained herein is not intended to, and does not, grant any right or license under any
IBM patents, copyrights, trademarks or other intellectual property right.
• IBM, the IBM logo, ibm.com, Bluemix, Blueworks Live, CICS, Clearcase, DOORS®, Enterprise Document
Management System™, Global Business Services ®, Global Technology Services ®, Information on Demand,
ILOG, Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™,
PureApplication®, pureCluster™, PureCoverage®, PureData®, PureExperience®, PureFlex®, pureQuery®,
pureScale®, PureSystems®, QRadar®, Rational®, Rhapsody®, SoDA, SPSS, StoredIQ, Tivoli®, Trusteer®,
urban{code}®, Watson, WebSphere®, Worklight®, X-Force® and System z® Z/OS, are trademarks of
International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and
service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on
the Web at "Copyright and trademark information" at: www.ibm.com/legal/copytrade.shtml.

46. Thank You
Your Feedback is
Important!
Access the InterConnect 2015
Conference CONNECT Attendee
Portal to complete your session
surveys from your smartphone,
laptop or conference kiosk.