Communication Paradigms for Mobile Computing

1
Communication Paradigms for Mobile Computing

• René Meier

2
Introduction

• Widespread deployment and use of wireless data
  communications causes the need for
• middleware to interconnect the components that
  comprise a mobile application.
• Middleware for mobile computing must deal with
  the increased complexity that comes
• with a dynamically changing population of
  application components, and the resulting
• dynamic reconfiguration of the connections
  between these components.
• There are two communication paradigms that are
  well suited as the basis for middleware
• for mobile computing event-based communication
  model and proximity-based group
• communication.

3
Event-Based Communication

• middleware that asynchronously interconnects the
  components that comprise an application in a
  potentially distributed and heterogeneous
  environment.
• supports a one-to-many or many-to-many
  communication pattern
• event notifications, or simply events, are the
  messages that contain the data representing the
  change to the state of the sending component.
  They are propagated from the sending components,
  called the producers, to the receiving
  components, called the consumers.
• event filters provide a means for a consumer to
  subscribe to the (ideally) exact set of events
  that it is interested in receiving.
• avoids centralized control as well as
  long-lasting and hence potentially expensive
  connections and requires a less tightly coupled
  communication relationship between application
  components compared to the traditional
  client/server model.
• Scalable Timed Events And Mobility (STEAM)
  designed for mobile applications such as traffic
  management.

4
Proximity-Based Group Communication

• classical group communication provides a one-to
  many or many-to-many communication pattern based
  on a reliable multicast protocol that allows a
  member of a group to send messages to all members
  of that group.
• an extension to classical process groups called
  proximity groups allows potentially mobile
  application components to join a proximity group
  and subsequently interact with its members once
  they are within the same geographical area.
• proximity groups defines membership by functional
  (i.e., the name of the group) and geographical
  (i.e. the geographical area) aspects
• proximity group can be distinguished as either
  absolute or relative
• Absolute proximity group is geographically
  fixed. Relative proximity group is relative to a
  moving point in space, most likely one of the
  proximity groups mobile members.
• STEAM utilizes the functional aspect of
  proximity groups to define the common interest of
  producers and consumers based on the type of
  information that is propagated among them and the
  geographical aspect
• to outline the scope within which the
  information is valid, i.e., the area within which
  the corresponding events are propagated.
• STEAM exploits the message delivery semantics
  associated with proximity groups to provide
  end-to-end guarantees when delivering events.

5
Software Engineering and the Internet a roadmap

• Paolo Ciancarini
• (with L.Bompani and F.Vitali)

6

• Introduction
• The computer is the network the convergence
  of computer, telecom and multimedia technologies
  produces new opportunities for industry, research
  and teaching.
• World Wide Web
• Software engineering a distributed environment
• Makes collaboration of remote shops possible
• Allows sharing and collaborative drafting of
  documents, code and all the objects of the
  workflow that are part of daily life of the
  software engineering.
• Provided advancement in the field of markup
  language.

7
Representing documents

• We use the term document with a wide scope,
  meaning any kind of data structure which network
• aware applications can exhange.
• (passive) document content (structured)
  representation
• A document that carries some information has some
  structure a book, a report, a letter, a program
  are
• examples of documents of different forms.
• HTML has been invented to write passive documents
  to be displayed inside WWW browsers.
• (HTML) documents contents procedural markup
• Since HTML is procedural it is therefore bad for
  two reasons
• The logical structure of document is not
  expressed in the markup, thus searching document
  (e.g. all titles, represented by intended bold
  lines) is difficult
• The concept of style is non existent, thus
  changes in style require revising all markup
  commands
• A solution was the introduction of declarative
  markup language (e.g. XML), useful to declare
  both the
• logical structure of a document and the styles to
  be used.

8
Towards active documents

• Active documents documents become active when
  they can react to external inputs, can produce
  computation, include animations, can dynamically
  modify themselves. An active document provides
  support for actions on the document.
• The idea of active document consists of putting
  the behavior together with the contents using
  generic markup behaviors and actions are applied
  just like formatting
• Many architectures have been defined to support
  active documents OpenDoc (Apple, IBM, etc.),
  ActiveX (Microsoft), and JavaBeans (Sun)
• All these architectures allow documents to become
  more complex and sophisticated and to include
  text, structured data, images, multimedia etc.
• Suffer from a fundamental weakness the
  persistent representation that is used to store
  data on disk or to exchange it among applications
  (i.e. the data format) is usually extremely
  complex, necessarily in a binary format, and
  often it explicitly includes the code necessary
  to create their active components.
• The approach here lies on providing generic
  active documents without including specific
  executable code in any form, XML.

9
XML

• XML is a standard markup language (defined by
  W3C, and derived from SGML) to describe the
  structure of documents instead, documents
  behaviours are specified using either stylesheet
  languages (e.g. XSL) or even programming
  languages (e.g. Java).
• XML and is cohort of related standards XSLT,
  XSL, XPointer, XPath, XLink, DOM, RDF and
  XML-Namespaces
• document contents structure behaviours
• Remark declarative markup is either structural
  or semantic
• Structure A book is composed of chapters,
  sections, titles, notes, etc. A letter is
  composed of sender, addressee, salutations, body,
  signature, attachments, etc.
• Semantics A news item about a criminal act may
  specify the source of the news item itself, the
  description of a sequence of acts, the name of
  the place where the acts took place, the name and
  rank of the involved police officers, the stolen
  amount, etc.
• With XML it is possible to define a syntax (i.e.,
  a Document Type Definition, or DTD). The purpose
  of a
• Document Type Definition is to define the legal
  building blocks of an XML document. It defines
  the
• document structure with a list of legal elements.
  
• 3 most important aspects of XML family
  Meaningful structure, namespaces and hypertext
  links

10
Related standards

• XSLT is a mapping language that can be used to
  transform an XML document into another one. Its
  most important use is to transform an XML
  document into a format that can be displayed by a
  browser.
• XML-Namespaces is a specification to allow the
  intermixing of tags defined for different
  document types. For instance a mathematician may
  write the text parts of a textbook using plain
  HTML and intersperse the HTML with MathML
  formulas without needing to create a new DTD
  including the two tag sets.
• XSL describes how the document should be
  displayed. XSL as a set of languages that can
  transform XML into XHTML, filter and sort XML
  data, define parts of an XML document, format XML
  data based on the data value, like displaying
  negative numbers in red, and output XML data to
  different media, like screens, paper, or voice.
• XLink defines a syntax for hypertextual links
  between XML documents.
• XLink allows to define simple links (a la
  HTML), Multi-directional links, External links,
  Automatic links, Document groups
• XPointer specify in a general way chunks of
  content inside an XML document. They allow to
  combine absolute references (eg. a named element,
  the root of the XML tree, etc.), relative
  references (eg. the second child), and text span
  (eg. third character).  

11
Displets

• XSL is not up to XML in terms of generality
  specialized notations are not supported
• Authors proposal is to create an open set of
  formatting objects that are loaded when needed,
  depending on the required behavior of a complex
  document.
• Each document has a stylesheet associated that
  maps its elements to the available formatting
  objects each formatting object is then
  associated to a sw module, a JavaBean, that they
  call displet, displaying the information (we
  exploit the dynamic linking capabilities of Java)
• XMLC (XML Compiler) is the authors architecture
  for rendering displets. The main purpose of XMLC
  is to read an XML document and to produce a
  displayable tree of Java objects.

12
Declaratively active documents

• The authors of this article have two reference
  architectures for displets, that they call
  server-side and client-side, respectively
• The server-side architecture is more efficient,
  but less flexible (a behaviour is pre-processed
  and wired-in a document, that then is sent to a
  browser and displayed)
• The client-side architecture can be used to have
  documents performing activities, rather than just
  be displayed
• Since displets which are Java Beans and are
  associated to each element in an XML document, we
  can ask a Bean to paint itself, or to perform any
  other method of its classes
• Depending on the stylesheet and the Java classes,
  then the same document can behave in any
  different ways
• The code performing the activities is not part of
  the document (as in Active X or similar systems)
  but declaratively associated to the document
• Example Petri Nets
• Authors have defined a DTD for Petri Nets, thus
  we can represent textually any Petri Net. Then
  they
• have defined stylesheets to display and animate a
  Petri Net. Then they have enriched the Petri
  Beans
• with editing capabilities, so that the original
  document can be modified (but not saved, if we
  use the full
• Java security model)