Status Report to 01/11/2007

Plans for demonstration

1. Universal collaboration framework (UCF) on cell phone
2. Authentication service (Narada team implemented) integrated into UCF on desktop
3. Controls (XGSP, XRBAC, XFloor) mechanisms with applications
4. Simulations of the control mechanisms modeled by coloured petri net
5. Collaborative applications (IM, WB, Textchat)
   

Status Report to 12/27/2006

I am in the process of measuring performances and writing my thesis.

Status Report to 12/13/2006

This picture shows a simulation of the modeling.

Done

1. A handler and a protocol were newly added to the framework. The handler and protocol are about XFloor.
2. Also, the simulation of control mechanism modeling was updated.

Doing

1. In the process of measuring some experimental.
2. In the process of writing my thesis.

Status Report to 11/29/2006

Status of XGSP

Collaboration can be defined as interaction for cooperation between people working at remote locations. The interaction in collaborative computing requires a simple and universal access means and mechanism for people to access information or to communicate with other people. Interactions and cooperation in collaboration are generally provided through the unit of conference and sessions. A conference is composed of a set of sessions. A session means online workgroup of collaborating users working with sharing various collaborative resources. A conference needs control logic to maintain state information among sessions in a conference. The control logic is used to manage presences of and connectivity among collaborating users in the online workgroup (session), and organize the online workgroups (sessions). The control logic needs a protocol for streaming control messages to exchange presence information of collaborating users and states of various collaborative sessions. To describe presences, connectivity, and states of sessions,we use XML as a protocol definition language of session control. The XML based General Session Protocol (XGSP) is a protocol for streaming control messages written in XML to provide various collaboration sessions in a conference for users according to the presences and connectivity. The session control protocol account for policy, presence, and session creation, initiation, teardown, and so on.

During the integration of XRBAC and XFloor into the framework, a policy(session and access policy) handler and a protocol for the policy into the framework were added. A user need to send a join-conference message to conference manager before the user can establish a session on the conference manager in order to receive policies for setting session policies and accessing to resources. Also, a user need to send the join-conference message to chair node before the user establish a session on the chair node in order to engage in presence information of other collaborating users and existing various collaborative applications in the session. The initial presence message, join-conference XML stream, is to signal his availability for communications to nodes and conference manager. The initial presence XML stream was updated by adding new element "Role Name". We have now three role names (chair, nonmobile user (desktop user), and mobile user). I plan to divide the mobile user into two other role (Treo cell user and Nokia cell user). I found some missing capability in XFloor mechanism during simulation of the model. To do it, a handler and a protocol are going to add to the framework. Also, the protocol affects the simulation of control mechanism. Thus the simulation will be updated.

Summary

1. A handler and a protocol were newly added to the framework.
2. An initial presence XML stream join-conference was updated.
3. A new handler and a new protocol will be put into the framework.
4. New role name (Nokia cell) will be created later if necessary. (Perhaps later this will be tested for comparison of overheads)
5. After the new handler and protocol are created, the simulation will be updated.

Status Report for 11/01/2006 to 11/15/2006

Done

The control mechanisms (XRBAC and XFloor) were modeled by using Colored Petri Nets with time. Formal verification and analysis to prove the correctness of the mechanisms were done using state space functions provided by the CP-nets. But the analysis is not completed yet. The current results show the mechanism model is working as expected. Also the modeled mechanism used communication service provided by the CP-nets to connect the model to external process. Without the communication service, we can simulate our XML access type decision service by randomly generating the classified access types (invalid, implicit, exclusive, shared, and released) in the mechanism model. But I thought it will be more nice if we can test the correctness of the classification decisions service codes used in practical programming of universal collaboration framework. The simulation result also shows the classification decision service is working as expected.

Summary
1. The control mechanisms (XRBAC and XFloor) were modeled by using Colored Petri Nets with time.

2. The classification decision service was verified by the CP-nets simulation methods. This service means XML requests are parsed and one of the classified access types from parsed request are returned for use of control decision in the mechanism model.
3. Informal introduction of the control mechanism model was done.
4. Formal definition of the control mechanism model was done.

5. Using state spaces (also called occurrence graphs) analysis functions provided by the CP-nets, simulation results of the mechanism model are being analyzed.

- some results : analysis results generated from state space analysis functions show the modeling of our control mechanisms is working as expected.

6. The draft report will be finished within roughly next 2 weeks.

Next Research

- Experiment issues - coming soon

• case study
• performance analysis - overheads incurred (due to use of XML (XRBAC and XFloor)) on

mobile vs. non-mobile device,

coarse-grained vs. fine-grained access control,

fine-grained (level (depth) 1) vs. fine-grained access control (level (depth)2))

Status Report for 09/01/2006 to 10/31/2006

Formal Verification
This shows modeling of the control mechanism, in this report referred to as XRBAC and XFloor, and formal verification to prove the correctness of the mechanism. For the modeling representation of the control mechanism, we used Colored Petri Nets (CP-nets or CPNs) with time. One of the main reasons for using the CP-nets is the fact that it allows each transition to have a number of different types of occurrences by using different types of token colors, and thus reduces a large number of places, transitions, and arcs and makes modeling and verification of a system much easier than classical Petri net (place/transition net). The CP-nets provides a formal simulation tool to model a system and analysis functions using state spaces (also called occurrence graphs) to prove the correctness of a system based on mathematical methods.

1. Modeling of Control Mechanisms (XRBAC and XFloor)
   The modeling by CP-nets to verify the correctness of our mechanisms is composed of five parts. First, the model has a single queue for storing requests from collaborating users in sessions. The queue is implemented in FIFO (First-in, First-out) fashion. The first XML request in the queue is moved to classified access type decision service located in external process for parsing the XML request and returning a type value into the model. And the first request is removed from the queue. Second part is, mentioned above, classified access type decision service located in external process outside the modeling tool. The classified access type decision service is connected to the modeling tool by communication service provided by the CP-nets. Also the classified access type decision service is a practical code programmed in Java language which is practically used in our control mechanisms (XRBAC and XFloor) integrated into the universal framework. The service parses XML requests sent from modeling (or simulation) tool and returns a type value (Invalid, Implicit, Exclusive, Shared, or Released) to the tool as practically does the service in universal framework. Third, decision activities in the model are processed with a type value returned from classified access type decision service working as external process outside the modeling tool. The decision activities are also classified into the same access types as mentioned in second part. Each decision activity simulates decision behaviors (grant, deny, released or queued) of conference chair in universal framework (chair node) by generating the decisions through random generation provided by the CP-nets. Fourth part is to update action states of users joining a session for accessing resources. Some requests are denied without need for updating current action state of users joining a session, some request are granted with need for updating the current action state, or others are stored in a queue different from one storing access requests to resources. Finally, all the requests for the use of resources have to be serviced in some amount of time to avoid starvation. The access requests to shared resources are stored in a single queue which is implemented in FIFO (First-in, First-out) fashion. The first request in the queue is serviced when a floor to the shared resources is released or after an appropriate amount of time. The request is removed from the queue and the current action state is updated with the removed request.
2. Informal Introduction of Control Mechanism Modeled by Colored Petri Nets - coming soon
3. Formal Definition of Control Mechanism Modeled by Colored Petri Nets - coming soon
4. Analysis based on State Spaces (Occurrance Graphs) - coming soon