Leonardo Hartleben Reinehr and Maria Beatriz Felgar de Toledo

1
Leonardo Hartleben Reinehr and Maria Beatriz
Felgar de Toledo
A CORBA-Based Workflow ManagementSystem for
Wireless CommunicationEnvironments
Presented by Tapan Shatapathy
2
OUTLINE

• Introduction
• Process Model
• Architecture
• System Operation
• Prototype
• Related Work
• Conclusion

3
INTRODUCTION

• What is WFMS ??
• Workflow Management Systems (WFMS) increase the
  efficiency of an 0rganization by automating
  organizational processes. Many WFMS have been
  developed and successfully used. However,these
  systems still have some limitations,such as low
  interoperability among different WFMS,
  insufficient support for failure recovery and low
  flexibility.
• Challenge
• WMFSs usually require that the users are
  connected to wired networks, restricting users
  mobility.With the appearance of wireless networks
  and portable devices, it has become important to
  allow flexible use of WFMS s. Thus a user, from
  his laptop or other portable device,will be able
  to execute tasks independent from location and
  connection type.

4
PROCESS MODEL
WorkToDo Process Model
5
PROCESS MODEL

• Tasks
• Tasks are those activities that cannot be
  decomposed They are defined by Task Models,
  which are used to create tasks during a process
  execution.
• Automatic. Tasks which are executed by a software
  invoked automatically by the WFMS.
• Semi-automatic. Tasks which are executed by a
  human assisted by a software
• Manual. Tasks which are executed exclusively by a
  human.

6
PROCESS MODEL

• Processing Entities
• Every task has a processing entity responsible
  for its execution. Processing entities model the
  organizational aspect of a process and are
  specified in the task models.
• Applications. These are the processing entities
  of automatic tasks. When the task is initiated,
  the correspondent application must be invoked
• Users. Users are the processing entities of
  semi-automatic and manual tasks. Tasks are
  assigned to users through a role mechanism. A
  Role is a group of users with some set of
  characteristics. The task definition specifies a
  role R, allowing any user belonging to R to
  execute the task.

7
PROCESS MODEL

• Data
• Tasks can use input data and generate output
  data data specification corresponds to the
  informational aspect of a process.
• Definition Language
• WorkToDo provides a Workflow Definition Language
  (WDL)
• A process type definition contains a list of
  activities and, for each activity, its input and
  output data, its dependencies and its processing
  entity.
• A task model specifies the task characteristics,
  such as type and priority.
• An application definition contains the
  application characteristics, such as size and
  operating system on which it can be executed.

8
PROCESS MODEL
State Transition Diagram
9
ARCHITECTURE
10
ARCHITECTURE

• User and Role Manager
• The User and Role Manager (URM) is responsible
  for managing users and roles. It provides the
  following operations insertion/removal of users
  to/from roles, retrieval of a users roles,
  retrieval of users in a role, among others.
• Users. This repository contains information about
  system users, such as name, password, status
  (connected or not to the WFMS), and time of the
  last connection.
• Roles. This repository stores existing roles,
  together with a list of users belonging to each
  role. A user may assume zero or more roles.

11
ARCHITECTURE

• Definition Manager
• The Definition Manager (DM) manages process
  types, task models and applications definitions.
  The DM provides operations for retrieval of
  existing definitions and insertion/removal of
  definitions. The DM manages three repositories
  which stores process types, task models and
  applications definitions.

12
ARCHITECTURE

• Instance Manager
• The Instance Manager (IM) maintains information
  about the process instances in execution, as well
  as those already executed. The IM is also
  responsible for creating a Process Manager for
  each new instance at creation time, the IM
  transfers a copy of the process type definition
  to the Process Manager.
• Processes. This repository stores information
  about executing instances, such as name, type and
  host from where it is being managed.
• Completed Processes. This repository stores
  information about terminated instances, such as
  instance name, final state, start and end time,
  and the final state of each one of its tasks.

13
ARCHITECTURE

• Process Manager
• The Process Manager (PM) is responsible for
  coordinating a process execution. The PM verifies
  which tasks are ready to execute, initiates their
  execution and collects their results, verifying
  if these results allow the execution of other
  tasks.
• Scheduler. This component evaluates the
  conditions for the execution of the tasks.
• Dispatcher. This component prepares the tasks for
  execution. The Dispatcher periodically checks the
  tasklist for ready tasks. When a ready task is
  found, the Dispatcher executes one of the
  following actions if the task is automatic,it
  creates a Task Manager to manage the task
  execution if the task is semiautomatic or
  manual, it notifies the users belonging to the
  task role about its availability.

14
ARCHITECTURE

• Task Manager
• The function of the Task Manager (TM) is to
  control the execution of an automatic task. The
  TM is created by a PM and initialized according
  to the respective task definition. The TM then
  invokes the application responsible for the
  execution of the task (with the necessary data)
  and monitors its execution. When it is finished,
  the TM notifies the correspondent PM, returning
  the task termination type (with success or with
  failure). If a task execution fails, the TM can
  execute the task again until it succeeds or it
  reaches a maximum number of retries (specified in
  the task model).

15
ARCHITECTURE

• Worklist Manager
• The Worklist Manager (WM) controls and maintains
  a list with all the tasks that can be executed by
  a given user. This list is called worklist and
  the tasks are called workitems.
• Each workitem corresponds to some process task.
  Thus, every time a workitem state changes, the
  state of the corresponding task is also changed.
  This guarantees that the changes made by users on
  the workitems are reflected on tasks. The
  workitems always correspond to semiautomatic or
  manual tasks, since automatic tasks are managed
  in a different way (through TMs) and are not
  added to worklists.

16
SYSTEM OPERATION

• User System Interaction
• Visualize workitems. The worklist shows the
  users workitems, listed according to one of four
  ordering types by arrival time, by priority, by
  deadline and by size of related data.
• Select workitems. When the user wants to execute
  a workitem, he must select it. The correspondent
  PM receives a notification, passing it to the
  other WMs that also received this workitem the
  WMs remove the workitem from their users
  worklists. The user who selected the workitem is
  then authorized to execute the workitem.
• Lock workitems. When the user wants to execute a
  workitem in disconnected mode, he must lock it.
  Thus, the workitem is removed from the worklists
  of the other users of that role, in a similar way
  as if the workitem had been selected. A workitem
  can only be locked if its correspondent task was
  defined as allowed to be executed disconnected.

17
SYSTEM OPERATION

• Task Deadlines
• Tasks have deadlines, which represent the time
  limit to their execution. The deadline of a task
  is specified in the task model definition. If a
  task deadline is reached, the user-in-charge of
  the process instance decides if the instance
  execution should be interrupted or not.
• Prefetching
• While the user is connected to the WFMS, the WM
  periodically checks if the worklist contains some
  workitem which can be executed in disconnected
  mode. If it does, the WM copies the workitem to
  the users machine. By copying a workitem we mean
  copying both data and application related to the
  workitem (if they exist).

18
SYSTEM OPERATION

• Disconnected Operation
• The WorkToDo supports planned disconnected
  operations, requiring the user to notify the
  system prior to disconnection. Users reserve
  workitems to execute in disconnected mode through
  a locking mechanism.
• In order to execute a workitem in disconnected
  mode all data related to the workitem must be
  available locally. Therefore, these data are
  copied to the users machine at disconnection
  time. Moreover, when the user reconnects, the
  WFMS must be notified about the results of
  workitem executions.

19
SYSTEM OPERATION

• Semi-Connected Operation
• During semi-connected operation there may exist
  periods when there is little or even no
  communication between the users machine and the
  WFMS. These periods are used for Prefetching.
  Thus, when the user selects a workitem, its data
  may be already available locally. In this case,
  it may be less expensive to execute the workitem
  locally instead of remotely, avoiding
  communication with another machine and thus
  masking possible failures.

20
PROTOTYPE

• Why CORBA???
• CORBA was chosen because it provides transparent
  remote object access, making the development of
  distributed applications easier. Furthermore, it
  is a relatively stable technology and has been
  used successfully in many contexts.
• The components of the architecture were all
  implemented as CORBA servers,communicating
  through a Local Area Network (LAN).

21
PROTOTYPE

• Additional Services
• Persistent objects. This service allows the state
  of an object to be recovered and saved
  automatically when the object is activated and
  deactivated, respectively.
• Multithreaded servers. This service allows a
  server to process many requests simultaneously.
  Each time the server receives a request, a
  separate thread is created to process the
  request, freeing the server to receive other
  requests.
• Timeout for servers. Through this service, it is
  possible to establish for how long a server will
  stay active after processing a request. After a
  certain amount of time without receiving any
  requests, the server is automatically
  deactivated. This amount of time may be specified
  when the server is created.

22
PROTOTYPE
23
PROTOTYPE

• Results
• Disconnected and semi-connected operation have
  proved to be feasible and the system to be stable
  in the face of communication failures, without
  generating inconsistencies.
• There is a problem with respect to the CORBA IORs
  of some objects. When a mobile host moves to
  another cell, it receives a new IP address,
  invalidating all IORs. One way to solve this
  problem is to store the WM state into the URM
  before moving, to instantiate a new WM recovering
  this state and to inform the new address to the
  URM. In order to achieve this, the WM must know
  when the mobile host moves to a new cell.
• CORBA has fit well into the workflow system. The
  provided transparency is clearly a great benefit,
  separating the application functional aspects
  from the distribution aspect.

24
RELATED WORK

• The Exotica Project allows planned disconnection.
• In the INCAS model, the entities that execute
  tasks can communicate through wireless links.
  However, there are some implementation issues
  related to the last requirement for which no
  solutions have been proposed yet.
• Bussler presents a list of requirements to
  incorporate disconnected operation into
  conventional WFMS and proposes the mobile
  worklists concept to meet these requirements.
• Jing et al. discuss the Prefetching technique for
  mobile environments.
• METEOR model using CORBA, called ORBWork, in
  which each component of the model is mapped to a
  CORBA server. However, METEOR does not explore
  the system usage in wireless environments.

25
CONCLUSION

• The users can execute tasks from their laptop or
  other portable device without any mobility
  restriction.
• The users can execute tasks even disconnected
  from the system, using a locking mechanism to
  reserve the tasks to be executed in disconnected
  mode.
• Aspects such as local task deadline management
  (controlled by the WM) and the copy of data and
  results (made by the WM in the disconnection and
  reconnection protocols) are covered.
• Asynchronous techniques such as Prefetching and
  postponed propagation of results can also
  optimize the use of available bandwidth and mask
  eventual communication failures.

26
QUESTIONS

• ???

27
Andry Rakotonirainy and Greg Groves
Resource Discovery for Pervasive Environments
Presented by Tapan Shatapathy
28
OUTLINE

• Introduction
• Survey of Discovery Protocols
• Evaluation
• Architecture
• Performance Testing
• Conclusion

29
INTRODUCTION

• What is Pervasive Computing?
• Pervasive computing is the trend towards
  increasingly ubiquitous, connected computing
  devices in the environment, a trend being brought
  about by a convergence of advanced electronic -
  and particularly, wireless - technologies and the
  Internet.
• Pervasive computing devices are not personal
  computers as we tend to think of them, but very
  tiny - even invisible - devices, either mobile or
  embedded in almost any type of object imaginable,
  including cars, tools, appliances, clothing and
  various consumer goods - all communicating
  through increasingly interconnected networks.

30
INTRODUCTION

• What is the paper going to provide?
• This paper investigates and analyses the
  deficiencies of the current resource discovery
  protocols identifies the key problems and
  presents a solution. It provides a distributed
  and adaptable architecture that addresses the
  identified deficiencies.
• What are the challenges in the current resource
  discovery techniques?
• Most current RD systems have been designed with
  desktop and server systems in mind. These often
  require complex protocols that are not supported
  by mobile devices. Consequently they are not
  suitable for use by mobile devices in realistic
  scenarios and do not support ad hoc or peer to
  peer networking, which is prevalent in pervasive
  environments.

31
INTRODUCTION

• Mobile devices should be able to take advantage
  of RD systems available on desktop and server
  systems as well as among other mobile devices.
• This paper investigates and determines the key
  issues that need to be resolved in order to have
  an adaptable and flexible RD protocol suitable
  for use in a pervasive computing environment.

32
SURVEY OF DISCOVERY PROTOCOLS

• Service Location Protocol (SLP) from Sun
  Microsystems is an IETF standard for the
  spontaneous discovery of services. The SLP
  architecture utilizes three types of agents. It
  consists of User Agents, Service Agents and
  Directory Agents.
• Jini, from Sun Microsystems, is designed to
  federate groups of devices and software
  components into a single dynamic distributed
  system. The Jini protocol is based on leases with
  expiry.
• More recently, Sun Microsystems released JXTA
  technology. It is a set of open protocols that
  allow any connected device on the network ranging
  from cell phones and wireless PDAs to PCs and
  servers to communicate and collaborate in a P2P
  manner. It enables discovery of peers and
  resources on the network even across firewalls.

33
SURVEY OF DISCOVERY PROTOCOLS

• The Jini Mobile Edition (JiniME) research
  proposal aims to develop a version of Jini
  designed to run on wireless mobile computing
  devices, specifically those using the Java 2
  Micro Edition (J2ME) Connected, Limited Device
  Configuration (CLDC) and PDA profile.
• Universal Plug and Play (UPnP) is a standard for
  spontaneous discovery from Microsoft Corporation.
• Simple Service Discovery Protocol (SSDP) enables
  devices and services to announce their presence
  to the network as well as discover available
  devices and services.

34
SURVEY OF DISCOVERY PROTOCOLS

• Universal Description, Discovery and Integration
  (UDDI) is a specification for distributed
  web-based services from IBM and Microsoft
  Corporation.
• The Salutation protocol is an open specification
  for the spontaneous configuration of network
  devices and services. The architecture uses an
  abstract model with three components client,
  server and Salutation Manager (SLM).
• The Secure Service Discovery Service (SSDS) is
  part of the University of California, Berkeley
  Ninja research project. SSDS is implemented in
  Java and uses XML for service description and
  location, rather than Java objects.

35
SURVEY OF DISCOVERY PROTOCOLS

• Bluetooth is short range wireless transmission
  technology. The Bluetooth protocol stack contains
  a Service Discovery Protocol (SDP) which is used
  to locate services provided by or available to a
  Bluetooth device.
• The Home Audio/Video Inter-operability (HAVi)
  Device Discovery uses the Self Describing Device
  (SDD) data to discover a device in the network.
• MOCA is an adaptable service framework targeting
  mobile computing devices from IBM. MOCA is based
  on the notion of services and the assumption that
  applications are composed of sets of co-operating
  services.

36
EVALUATION
37
ARCHITECTURE

• The problem with all the protocols discussed
  above are
• First, the device must be able to use a discovery
  server when available and return to its own RD
  and management when it is no longer available.
• A device must also be able to find out the
  capabilities of other devices. This stops a
  device from offloading RD and management to
  another device that is less able to do the job
  than it is.

38
ARCHITECTURE

• Requirements
• The ability of a device to announce its presence
  to the network.
• Spontaneous discovery of devices and services
  available
• The ability of discovery protocols to enable
  self-configuration.
• The ability of a device to describe its
  capabilities and query and understand the
  capabilities of other devices.
• Self-configuration without human administrative
  intervention
• Inter-operability across manufacturers and
  platforms
• Provide inter-operability solutions that overcome
  challenges presented by the growing number of
  service discovery protocols.
• Automatic adaptation to mobility and sporadic
  availability.

39
ARCHITECTURE
40
ARCHITECTURE

• The basic architecture
• The Native Operating System provides the
  communication mechanisms.
• A Java virtual machine (KVM), CDLC API and
  Native API allow us to access the OS calls.
• The KVM provides remote invocation mechanisms.
• The RD protocol is the middle layer. It consists
  of a registration and lookup service.
• The Object Exchange protocol OBEX layer provides
  object exchange facilities for beaming data
  between devices.
• The Serial Infrared (SIR) layer and the Fast
  Infrared (FIR) layer are the hardware portions of
  the IrDA protocol stack.
• The Infrared Link Access Protocol (IrLAP) layer
  provides a data pipe between IrDA devices.
• The Infrared Link Management Protocol (IrLMP)
  layer manages multiple IrLAP sessions and the
  Tiny Transport Protocol (TinyTP) layer provides a
  lightweight transfer protocol for higher-level
  IrDA layers such as the OBEX layer.

41
ARCHITECTURE

• Resource Discovery Protocol
• Two distinct modes of operation centralized and
  distributed.

42
ARCHITECTURE

• Resource Discovery Protocol
• When in contact with a server, or a system that
  identifies itself as a server, the protocol will
  enter centralized mode. When a server entity is
  unavailable or is no longer reachable the
  protocol enters distributed mode.
• In distributed mode the protocol continues to
  actively and efficiently advertise, use, register
  and de-register services amongst peer devices.
• There is a device using an application that acts
  as a router, communicating with a discovery
  server while also exporting services. In this
  configuration all exported services are available
  by all the communicating devices.
• Each device is uniquely identified by an IP
  address.
• By using a device identification number (device
  ID) a device type can be referred to and
  identified without requiring a full description
  at each interaction.

43
ARCHITECTURE

• Service description and Message types
• Services are described by their signature. Our
  service signature is very similar CORBA IDL
  description.
• They use XML to have a more complete description.
  
• The description includes information such as type
  of the operation, textual description, timestamp
  and expiry date. They plan to use WSDL (Web
  Service Definition Language) in the future.

44
PERFORMANCE TESTING

• Application Responsiveness results

• Test A indicates a significant delay from when
  the application is selected and it is ready for
  use.
• Test C shows that this time increases when there
  are services stored in the Palm database that
  have to be retrieved and parsed.

45
PERFORMANCE TESTING

• Service Request Times

46
PERFORMANCE TESTING

• XML Parsing times in milliseconds

47
CONCLUSION

• Complexity and code size are very important when
  considering suitability of a protocol for use in
  mobile environments.
• Applications and a prototype written in Java
  using J2ME CLDC platform have been implemented
  and tested to validate the proposed solution.
• An XML based RD protocol can be implemented using
  mobile computing devices in ad hoc networks.
• The discovery protocol features
• centralized and distributed modes of operation
• integral device descriptions
• use of leases timestamping of services
• support for protocol inter-operability.

48
References

• Resource Discovery for Pervasive Environments
  Andry Rakotonirainy and Greg Groves
• http//searchnetworking.techtarget.com/sDefinition
  /0,,sid7_gci759337,00.html
• http//searchcio.techtarget.com/originalContent/0,
  289142,sid19_gci878639,00.html
• http//www.computer.org/pervasive/
• http//www.ibm.com/pvc/
• http//java.sun.com/products/jini/index.html
• http//wwws.sun.com/software/jxta/index.html
• http//www.cs.rit.edu/anhinga/whitepapers/JiniMEW
  hitePaper/abstract.html
• http//searchwin2000.techtarget.com/sDefinition/0,
  ,sid1_gci525224,00.html
• http//www.uddi.org/
• https//www.bluetooth.org/

49
QUESTIONS

• ???

50

• THANK
• YOU