Communication in an Appliance World

1
Communication in an Appliance World
Components and Messaging

• Perry Hoekstra
• Talent Software Services

2
Agenda

• ? Introduction
• A Case for Messaging
• Messaging Systems
• Wrapup

3
The More Things Change

• Business applications of the future will need to
  be spread across multiple, and sometimes
  specialized, hardware that will cooperate with
  other hardware, as well as the legacy computer
  systems we have today. To meet the demands of
  business, the information systems we build today
  and tomorrow must be based upon distributed
  object computing technologies and paradigms.
• - UnixInsider, 4/1996

4
More They Stay the Same

• Age of the computer appliance
• Computing appliances come in many different
  flavors, colors and form factors
• They are often called
• task specific computers
• personal digital assistants (PDAs)
• consumer devices
• network computers or portable devices

5
More They Stay the Same

• Age of the wireless computing
• All of these computing devices will need to be
  connected to a network through an appliance hub
• The medium for wireless computing will be
  Bluetooth or one of its chief
  competitors such as 802.11 wireless LAN standard

6
Software in an Appliance World

• The architecture of distributed applications that
  will support an appliance model is surprise a
  component-based one
• Components give us two key strengths in designing
  and deploying solutions

7
Software in an Appliance World

• First, components are designed to execute on the
  appropriate node
• server in the host-processing environment
• client device (in this case the appliance)
• Components allow us to deploy the application in
  the most logical and economical fashion

8
Software in an Appliance World

• Second, components, by nature of the design goal
  of resolving business goals through interfaces,
  are supportive of the disparate user interfaces
  found on these different appliance devices

9
Connectivity in an Appliance World

• Distributed computing as we know it is changing
• No longer is the defined environment x number of
  clients and servers with a constant connection
  through a local or wide area network
• All of a sudden we have computing devices on our
  wrists, in our pockets, and embedded in devices
  all over our homes and offices

10
Connectivity in an Appliance World

• These idea is that these computing appliances are
  constantly communicating with each other via
  wireless networks
• However, as these devices move from one location
  to another, these devices will disconnect and
  reconnect from the network

11
Wireless Computing

• The FCC report estimates that last year, U.S.
  mobile phone subscriptions grew by 24 percent (17
  million new users) while usage increased by 38
  percent
• Whether you believe that wireless-based computing
  is nothing more than the latest IT fad, the
  demand for this applications will grow as people
  believe they need them or that they are meeting a
  perceived demand

12
The Challenge

• Provide reliable, distributed wireless
  information systems to a multitude of devices
• These devices
• are not static in their location
• use a multitude of operating systems (PalmOS,
  WinCE, embedded Linux et. al)
• use different network protocols (TCP, UDP or WAP)
• have an unreliable network connection

13
The Challenge

• An wireless application must scale to thousands
  (or more) of users
• Support authentication of users and
  non-repudiation of transactions
• Robust, in that a transaction must be executed
  once, even in the face of weak network coverage
  or outage
• Accommodate different networks such as SMS, GSM,
  Bluetooth, IR, etc.

14
One Solution

• Message-oriented Middleware (MOM) allows for the
  loose coupling software components
• Applications communicate with other applications
  indirectly, through a third-party message service

15
Agenda

• Introduction
• ? A Case for Messaging
• Messaging Systems
• Wrapup

16
Scenario

• Consider the standard calendar/email application
• The well-equipped businessperson just asked for a
  list of their appointments from the corporate
  email system (on their PDA) as they head into
  work
• At just that moment, they entered a tunnel
• The connection is unavailable for x amount of
  seconds until they emerge from the tunnel
• Now imagine 5000 business people asking for their
  appointments as they go into work

17
Scenario

• For wireless-based applications, communication
  delays can vary widely
• The challenge is to design the system to cope
  with these delays
• In addition, the system must also cope with
  faults in the network such as undelivered replies
• The corporate email system is unable to deliver
  the list of appointments because there is no
  receiver

18
Why not RPC/RMI

• Think about the corporate email system in an
  Remote Procedure Call (RPC) scenario
• The client will time out waiting for a reply that
  will not be delivered while in the tunnel
• The server application will throw an
  error/discard the results because there is no
  client to receive the results

19
Why not RPC/RMI

• Even with a reliable wireless network (an
  oxymoron?), there are limitations to an RPC-based
  application
• Such an application has to deal with some
  performance overhead

20
Why not RPC/RMI

• When messages cross enterprise boundaries, rarely
  want to inherit security or transaction contexts
  (do not belong to same domain)
• Applications at enterprise boundaries examine
  messages that conform to security policies
• These enterprise boundaries exist even in major
  corporations as they wall off major sections of
  their network
• Because caller needs execution thread for each
  call (threads not cheap), RPC/RMI can hit a wall

21
Why MOM

• MOM or more commonly known as messaging supports
  disconnected operations
• One application can send a message to a second
  application even if the application is not
  available
• This second application (running on a PDA) may
  not be running or connected to the network at the
  time a reply is sent
• Coordination of the message flow is done through
  the message server

22
Messaging Architecture
23
Message Server

• The message server acts as the home base of the
  devices running the messaging client library
• The message server performs activities such as
• message queuing and forwarding
• access control to queues and topics
• message encryption
• transaction management
• protocol translation

24
Loose Coupling

• There is a high degree of anonymity between
  creator of a message (the producer) and the
  receiver of the message (the consumer)
• it doesn't matter who produced the message
• where the producer lives on the network
• when the message was produced
• Loose coupling permits dynamic, reliable, and
  flexible systems to be built

25
Guaranteed Delivery

• All messages can have guaranteed delivery
• Messages are held in queues and are delivered to
  their intended recipients as soon as the
  recipient comes online
• These messages also have guaranteed exactly
  once delivery

26
Lightweight Libraries

• Most messaging systems can run on resource
  limited systems
• For example the Softwired iBus//Mobile library
  can run in as little as 50kB of RAM and 70kB of
  ROM

27
Persistent

• Have the ability to designate that a message
  queue is persistent
• Ensures that a message can be recovered in the
  event of a failure by the message service
• Once up, the message service is responsible for
  retrieving the messages from persistent storage
  and delivering them

28
Messages

• The message itself is quite flexible
• Messages are like containers, freely expandable
  and capable of holding any kind of object such as
  an XML document or a serialized class
• Messages are either routed through the system
  (peer-to-peer) to distinct receivers or they are
  broadcasted (publish/subscribe)

29
Publish/Subscribe

• A publish/subscribe (pub/sub) is an event driven
  model
• Producers "publish" events
• Consumers "subscribe" to events of interest, and
  consume the events
• Producers associate messages with a specific
  topic, and the messaging system routes messages
  to consumers based on the topics the consumers
  register interest in

30
Peer-to-Peer

• In peer-to-peer (also known as point-to-point)
  messaging systems, messages are routed to an
  individual consumer which maintains a queue of
  "incoming messages
• Messaging applications send messages to a
  specified queue, and clients retrieve messages
  from a queue

31
Other features

• Message priorities
• Order delivery of messages to consumers
• Time-to-live, this limits the lifetime of a
  message
• Message maybe only relevant for a period of time
• An example is a stock quote
• Transactions
• Can have either send or receive as part of a
  transaction

32
Not for Everyone

• RPC/RMI superior for many types of scenarios
• More efficient than messaging in a
  well-connected, single-platform environment
  especially in terms of data marshalling
• Messaging can be quite verbose over the network
  due to its more text-based format
• While messaging may scale better in terms of
  number of clients supported, RPC execution is
  faster between client and server
• Need to know the outcome immediately

33
Agenda

• Introduction
• A Case for Messaging
• Messaging Systems
• Wrapup

34
Java Messaging Service

• Enterprise messaging systems are middleware for
  durable storage and forwarding of messages
• JMS provides standard APIs that Java developers
  can use to access the common features of
  enterprise message systems
• A JMS provider is an implementation of these
  interfaces
• Allow for a Java technology-based wrapper around
  an existing system

35
JMS Vendors

• A number of vendors offer products based on JMS
  including
• SoftWired - iBus
• Progress SonicMQ
• Fiorano FioranoMQ
• Numerous open source implementations including
  OpenJMS and Spyder

36
IBM MQSeries

• Leader in enterprise messaging market
• Supports all IBM platforms and most everything
  else
• Has numerous language APIs including C

37
Microsoft MSMQ

• Embedded in Microsoft Windows 2000 Server edition
• Supports the Microsoft COM object model
• Only supports Windows CE as an appliance
  operating system

38
Agenda

• Introduction
• A Case for Messaging
• Messaging Systems
• ? Wrapup

39
Review

• So what do we have?
• A flexible environment that can function in
  multiple scenarios
• device to device
• hub and spoke
• multiple hubs with spokes to support massive
  scalability

40
Review

• Support for multiple platforms, either natively
  or through the Java Virtual Machine
• Guaranteed delivery each message is delivered
  in spite of network outages and device failures
• Event notification ideal for pushing
  information such as stock quotes or alerts to
  wireless devices
• Persistence the message server tracks what
  topics/queues a devices is subscribed to. In the
  event of a crash, the information is restored
  from a database

41
Review

• Components loosely coupled through message
  sending/receiving, able to run on multiple
  platforms
• Essentially a platform for the integration of
  appliances as clients into enterprise
  applications

42
Reference Material

• Java Message Service
• OReilly Associates
• ISBN 0596000685

43
Reference Material

• Understanding Windows 2000 Distributed Services
• Microsoft Press
• ISBN 157231687X

44
Reference Material

• International Middleware Association (IMWA)
• http//www.imwa.org
• SoftWired (iBus//Mobile)
• http//www.softwired-inc.com/
• IBM (MQSeries EveryPlace)
• http//www.ibm.com/software/ts/mqseries/everyplace
  
• Microsoft (Microsoft Message Queue or MSMQ)
• http//www.microsoft.com/msmq/

45
Communication in an Appliance World

• Questions