Enrich Mobile Applications using Event Driven Architectures and IBM MessageSight : 3495Phil CoxheadCertified Consulting IT SpecialistEuropean Technical SalesIBM Hursley

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?

New Customer Interaction Points

Devices & Mobiles will be the touch points driving new revenue streams

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…

Branded Mobile Channel Opportunities

• Branded Mobile platforms lead the way in engaging c ustomers 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)

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 i nteraction based on ‘best mix’ of Cost, QoS, and platform cove rage, but

• VERY COSTLY – organizations can spend millions yearl y in SMS charges• SMS doesn’t integrate into the branded app experien ce on nearly all

smartphone platforms

“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 myBranded Retail Mobile Banking user

experience when I interact with them?”

• 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

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

Optimized Mobile Messaging

• Disruptive technology for dramatically reducing or eliminating reliance on SMS for organization initiated interactions to sm artphone platforms

• Deliver near real time notifications from organizati on Systems of Record directly to customers in your branded Mobile app us er 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 y our 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

• 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

DeveloperFriendly

InternetScale

Integrates

Reduce OpEx Costs

Proven IBM Appliance Platform

IBM MessageSight

Introducing IBM Message Sight

MessageSight [Primary]

MessageSight [Standby]

MobileAndroid

MobileiOS

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 IBMWorklight

MQTT

MQC

Application

IBM MQ

System Admin

Browser

Internet Intranet

IBM Message Sight - Connectivity

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 wirelessOptimizing network with event-driven communication

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

Patterns

Pattern – Fan Out Broadcast

• Single MQTT publisher application or component writ es (publishes) a message to a specific topic

• Multiple (zero or more) subscriber applications or c omponents 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

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

Pattern – Fan Out per Device Notification

• Single MQTT publisher application or component writ es (publishes) messages to defined set of topics, generally unique by subscriber entity

• Multiple subscriber application or components are e ach 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

Example – Fan Out per Device Notification

Native Notifications – a real example

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?...

Pattern – Fan In per Device Request Reply

• Multiple MQTT publisher applications or components write (publish) “request” messages to different topics, unique by pub lisher entity

• Single MQTT subscriber application processes messag es 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

Example – Fan In per Device Request Reply

Pattern – Fan Out per Device Request Reply

• Single MQTT publisher application or component writ es (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

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

• 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

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?

Architectures

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

Optimized Mobile Messaging

IBM MessageSightMobile 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 hand set –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 Bran ded Apps on the handset (if required) using native facilities

External Native 3 rd-Party Notification Service(APNS, C2DM, etc.)

8) Native Notification (containing no confidential inf ormation) delivered to silently launch/wakeup app on the handset. Branded App wakes up, connects to IBM Optimized Mobile Messaging, and imm ediately receives all notifications for display in Branded Mobile App user experience

Sub

scrib

er H

ands

et

* Remote Notification capability varies by handset platform and OS version

Cor

e B

anki

ng S

yste

mUse case example for Branded Retail Banking

APIs and Events Combine in Scenarios

ServiceProvider

IntegrationServer

DMZ ApplicationIntegration Layer

Security Layer

SecureGateway

MobileDevice

APIManager

• 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

EventProducerMQTT/TCP

JSON/HTTPREST/HTTP

SOAP/HTTP

???

???MQ/MQTT/JMS

Application Tier Middleware Tier

App 1

App 2

MQQueue 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

BrandedApp

Environment B

Environment A

Mobile Device

DMZ

Leverage Messaging InfrastructureUse MQ network to facilitate integration of events from Systems of Record

Optional extension to handle disconnected clientsApplication Tier Middleware Tier

App 1

App 2

MQQueue 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?

BrandedApp

Environment B

Environment A

Mobile Device

DMZ

Service

X

SMS

GCM, APNS, SMS

Worklight

Leverage Messaging Infrastructure

Use Integration Bus to receive new events or intercept existing onesApplication Tier Middleware Tier

App 1

App 2Integration 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

BrandedApp

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

Optional extension to handle disconnected clientsApplication Tier Middleware Tier

App 1

App 2Integration 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

BrandedApp

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

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

Services exposed on the ESB may be an appropriate event sourceApplication 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)

BrandedApp

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

Handle events from other vendor platformsApplication 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.

BrandedApp

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

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?

BrandedApp

Provider A Mobile Device

DMZ

Message FlowJMS Q,??? …

Message Flow

JMS,

MQTT

Integration Server

Integration Server

JMS Q,??? …

Subscriber Considerations in Integration Bus

Application Server

Direct inbound and outbound communicationData 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.

BrandedApp

Mobile Device

DMZ

JEE AppComponent

MDB JMS ???

???

JMS

Integration with WebSphere Application Server

What approaches are needed for concurrency and integrityData 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

BrandedApp

Mobile Device

DMZ

MDB JMS

Application Server

EJB MDB

Application Server

Cluster

JMS

Subscriber Consideration with WAS

References

• Building Real-time Mobile Solutions with MQTT and IBM MessageSight, SG24-8228http://www.redbooks.ibm.com/abstracts/sg248228.html

• Building Smarter Planet Solutions with MQTT and IBM WebSphere MQ Telemetry, SG24-8054http://www.redbooks.ibm.com/abstracts/sg248054.html

• Responsive Mobile User Experience Using MQTT and IBM MessageSight, SG24-8183http://www.redbooks.ibm.com/abstracts/sg248183.html

• IBM MessageSight product web page http://www-03.ibm.com/software/products/en/messagesight

• IBM MessageSight announcement letterhttp://ibm.co/1xo29rP

• IBM MessageSight Knowledge Center http://ibm.co/1oVGLaz

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?

Notices and DisclaimersCopyright © 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, dupli cation 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 beenreviewed 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, in tent or product plans are subject to change or with drawal 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.

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.

Thank YouYour Feedback is

Important!

Access the InterConnect 2015 Conference CONNECT Attendee Portal to complete your session surveys from your smartphone,

laptop or conference kiosk.