EN QUÉ ORDEN UBICAMOS A LOS INVITADOS EN EL PLANNING DEL SALÓN QUE TENEMOS EN LA INTRANET?

Wong Kok Seng

Multimedia University, Malaysia Sellappan Palaniappan

Malaysia University of Science and Technology, Malaysia Nor Adnan Yahaya

Malaysia University of Science and Technology, Malaysia

IntroductIon

In today’s information and communication technology (ICT) era, the need for real-time collaboration over the Internet is increasing. Due to ongoing corporate globalization and geographic dispersion of project operations, collaborative becomes a key for supporting these distributed corporate operations. Current elec-tronic design automation (EDA) and computer-aided software engineering (CASE) tools typically do not sup-port collaborative work. In a geographically dispersed environment, designers from different companies or locations are finding it difficult to communicate with each other. Several studies have been done on collab-orative environment; however, all studies are still in the research level and not yet commercialized. In order to support collaborative work, few concerns must be taken into consideration. Network architecture is the main concern when designing a network-based col-laborative environment. Client-server architecture and peer-to-peer architecture are two possible architecture designs that can be used for a collaborative graphical-based design environment.

Architects, practitioners, designers, and researchers alike are all interested in how computer technology may help them to improve effectiveness in the collaborative works. The technological advances in computing and networking in recent years have enabled collaborative work among members of a project team. Collaborative technology is used to improve the speed and efficiency of project implementation as well as its operations.

Creating, maintaining, and evolving social interaction in communities are concerned for collaboration. As described by McCullough (2004), interaction design

needs to be concerned with how people interact with each other in situations where technology should be part of the environment.

Collaborative work is also aimed at supporting groups of people engaged in a common task and pursuing a common goal. There were several types of solutions that enable users to work in a collaborative environment. Two competing solutions are peer-to-peer (P2P) and client-server architecture. Both architectures allowed data sharing among collaborators within a single environment—collaborative environment.

According to Xu (2000), “Collaboration is primar-ily concerned with creating, maintaining, and evolving social interaction in communities, and it is aimed at supporting groups of people engaged in a common task and pursuing a common goal.” Projects that involved a team of people often supported by basic needs of enabling communication tools such as e-mail, Web-based file sharing, and chat programs. There is a need for these components to support collaborative environment so that collaborators will feel that they are working together on a daily, hourly, or even continu-ous basis (Agarwal, Sachs, & Johnston, 1998). Both client-server and peer-to-peer architecture can be used to support graphical-based design tools such as EDA and CASE. However, the usage of these architecture designs is based on the functionality and requirement from the collaborative team. The framework with either architecture design is comprehensive enough to support the development of a collaborative design environment, particularly one that uses graphical-based design tools. In this article, we will examine the usage of the previously mentioned architecture to support graphical-based tools (e.g., EDA). A design overview



Collaborative Support for Graphical-Based Design Tools

and the salient features of such a collaborative environ-ment or system will be presented.

BAcKGround

Collaborative support for graphical-based designed tools is relatively new. There are only few projects that are carried out at research level. The first identi-fied project is Web-based electronic design (WELD, 1999), which is currently running at the Department of Electrical Engineering and Computer Sciences University of California at Berkeley. This project is the first operational prototype in IC design for the U.S.

electronic industry. It aims to provide a reliable, scal-able connection and communication mechanisms for a distributed environment that consist of users, EDA tools, and services. The Internet-based distributed VHDL design (IVE) project is another similar project that focuses on VHDL design tool. IVE as described in Yang, Windisch, Schneider, Mades, and Ecker (1999), helps developers to distribute VHDL related design data, software components, and services over the networks. It is applicable in distributed, concurrent design, teamwork develop, and provisions of IPs. The main advantage of the proposed system in this project is platform independence. The system is implemented in JAVA and supports multi platforms.

ProBLEM StAtEMEnt

According to Jeffrey and Tony (2001), collabora-tive interactions can be divided into four categories, which include face-to-face, asynchronous, distributed asynchronous, and distributed synchronous. There are many collaborative tools that are now available in the market to support these collaborative interactions. There are also many studies conducted in universities and organizations that focus on collaborative design. The success of collaborative computing depends on many factors including protocols used, the architecture style used, the level of need, and performance of network system. Currently, graphical-based design tools were used in most of the industries. Industries from different domains apply such tools into their business operations.

Collaborative works become a trend for most of the companies especially projects that involve multi-parties.

The study on existing graphical-based tools and

tech-niques are not efficient enough to support the growing technology nowadays. Graphical-based design tools are of significant importance to system architecture design, electronic circuit design, and other forms of design. The usage of these tools is becoming increas-ingly important to help designers in monitoring their work. Unfortunately, there is no standard framework that enables such tools to be used in a collaborative environment.

Graphical-based design tools such as EDA, CASE, and CAD are commonly used nowadays. These tools are important because they can accelerate the design cycle. Software industry needs CASE tool to help in their software design (e.g., use case modeling can help the designers or developers to produce quality design.

EDA tool is a new design tool for electronic industry.

This tool is developed and designed for electrical circuit design, schematic capture, simulation, prototyping, and production. There are many electronic companies look-ing for EDA tools because it can increase productivity and shorten the design circle time for electronic circuit design. EDA tool helps the electronic industry to speed up their complex circuit design. The electronic design automation industry supplies services, products, and tools used by electronic engineers. Engineers who de-velop today’s highly complex computer chips and the larger electronic systems in which they reside require EDA tools and services.

Many problems will occur if there is no collabora-tive support for designers. Significant research efforts have been devoted to the area of sharing information through computers and the Internet. However, limited attention has been devoted to the basic communication mechanisms and the encoding of these mechanisms as discussed in Pena-Mora and Hussein (1998). If only one designer controls the entire design, it is hard for another project member to understand the existing design. This problem becomes worse when the person who controls the design process leaves the company or quits the project. All these problems occur because there are no features from existing design tools that enable collaborative work among designers. Current design tools do not support information sharing among collaborators. All information is available locally to the team or organization. There is no central repository to store files and information. During the collaboration process of large-scale projects, the design is separated into sub modules and distributed to several project teams. Unfortunately, the current design environment

assumes that the design is a product that belongs to their

C

company and minimizes information and idea sharing.

The lack of collaboration between all project teams might cause the project to fail as all teams think only of their own benefits and decline to share information and resources.

MotIVAtIon For coLLABorAtIVE SuPPort

This section will discuss a sample scenario for motiva-tion toward collaborative support for graphical-based design tools. Company A is an international company.

They have a team of designers working on a project, but team members are from dispersed locations. The project is then divided into different modules and each designer is responsible for a particular module. The work of each designer might depend on work completion from other designers. Due to this, there must be some communications among the team members. The project manager is responsible for managing the project and he or she needs to track and review all the works.

Designers are able to access information or files at any location. He or she will expect modifications made to any of these files on one device to be automati-cally reflected on another, even when the devices are geographically far apart and connected to physically separate networks. He or she also wants all files to be accessible even when his or her system is in discon-nected mode. Designers will need to share their work with other team members. Each of the designers would like to read and view the group’s files, and also be able to modify the files, delete, and add a new file.

The collaboration system must be able to support different network environments such as machines connected via intranet and shielded by firewall, wire-less network such as 802.11 or 802.11b, or machines connected to an ISP via an ADSL or dialup and have dynamically assigned IP addresses. A designer may work in online or off-line mode. For example, during working hours, designer X’s laptop is connected to the corporate intranet. Modifications made to any of the files are replicated to other designers of the group. At the end of the working day, designer X may disconnect his or her laptop and continue to work on some of the shared files at home. Thus, he or she is working in off-line mode. Any modifications are stored in the local

drive of his or her laptop, and hence may be uploaded to the network when designer X reconnects to the net-work in the following morning. He or she boots up the notebook and reconnects to the P2P-C system. After he or she has logged in, the system will fetch the changes and update to other members automatically. From the discussed sample scenario, it brings up the motivation to setup an environment that allows collaborators to work under a same virtual environment.

dESIGn conSIdErAtIonS

In 1999, Fastie (1999) defined the concept of client-server architecture as one or more machines (client) accessing a powerful computer (server) to store and process data. In this case, a client is an individual user’s computer or a user application that does a cer-tain amount of processing on its own. The client can be any machine within the network that is connected to the server. However, peer-to-peer architecture has been introduced and used in many applications such as KaZaA, Gnutella, Mojo Nation, and Freenet. According to Mauthe and Hutchison (2003), “Napster was the first major system enabling the direct exchange and sharing of content. While the actual exchange of content in Napster is between peers, the discovery of the peers, however, is highly centralized.” According to Barkai (2001), “There are many types of applications that employ P2P technologies compared to client-server architecture.

A matter of great interest to architects, practitioners, and researchers alike is how computer technology might affect the way they think and work. The concern is not about the notion of “support” alone, but about ensur-ing that computers do not disrupt the design process and collaborative activity already going on (Finholt, Sproull, & Kiesler, 1990). Architecture style that can be used to support collaborative works for graphical-based design tools included client-server architecture, peer-to-peer architecture, as well as distributed object architecture.

There are some criterions to be considered in order to choose the best architecture style for the collaborative framework. Feasibility is one of the main concerns for the selected architecture. As the number of nodes on the collaborative network increase very fast, the architecture used must be able to support large number of users



Collaborative Support for Graphical-Based Design Tools

simultaneously. In the collaborative environment, there might be more than 10 or even 100 users collaborating together for a same project at the same time.

Data transfer rate is another important feature that must be provided by the network architecture. All data must be transferred securely between the nodes in the network. File sharing is essential because it is the pri-mary requirement for collaborative work (Agarwal &

Perry, n.d.). In terms of scalability, architecture used must allow the creation of additional nodes or services anytime, anywhere. It has to support simultaneous users and provide a reasonable performance.

Workspaces locking algorithms or locking mecha-nisms are concerned when concurrent operations occur.

It is used to prevent conflicts and inconsistencies of the collaborative design. The coordination of group members’ activities in the shared workspaces is crucial because any inconsistency will bring the big impact to the design. Problems might occur if there are two or more clients working at the same time within the same environment without having locking mechanisms. An example is shown in Figure 1.

In this example, peer-to-peer (P2P) architecture is selected. Client A draws a rectangle at (x0, y0), while client B on the other hand draws a triangle at (x0, y0).

Assuming that both clients drawing at the same time or within a small different of time. Thus, this may result in having two different drawings as shown in Figure 1.

P2P uses a locking mechanism for workspace to solve this problem. The locking mechanism is shown in Figure 2. When client A is drawing a rectangle, a message is sent to client B to lock the workspace. Client B can only view the workspace and no modification is allowed. The workspace is unlocked after client A has finished drawing and this action is translated to client B’s workspace.

The locking operation is done transparently from the user and it uses implicit floor control mechanisms.

When users draw an object on the screen, the workspace is temporarily locked until the operation is completed.

Other users are not able to draw on the workspace in the mean time.

Collaborative environments for graphical-based design tools use transmission control protocol (TCP) to transmit information across the Internet. TCP is the Internet standard transport protocol that provides the reliable, two-way connected service that allows an ap-plication to send a stream of data end-to-end between two computers across a network (definitions of transmis-sion control protocol). It uses the Internet protocol (IP) as the underlying protocol. In addition to TCP, there is another transport level protocol called user datagram protocol (UDP). The UDP provides a connectionless service for application level procedures. However, UDP does not guarantee delivery, preservation of sequence and protection against duplication.

Figure 1. Shared workspaces without lock mechanism

no Locking

Client A

Draw rectangle at

(x0,y0)

Shared Workspaces

(Client A)

Shared Workspaces

(Client b)

Draw triangle at

(x0,y0)

Client b

translate action translate action dt

C

TCP uses the concept of port numbers to identify sending and receiving applications. Each side of a TCP connection has an associated 16-bit unsigned port number assigned to the sending or receiving applica-tion. The port numbers are divided into three ranges:

well known (0 to 1023), registered (1024 to 49151) and private (49152 to 65535) ports. Well known are ports that are listening for connections, such as HTTP (80), FTP (21), and TELNET (23). Registered ports are named services that have been registered by a third party. Private ports are those used by end user applications. We can use 8888 as listening ports and use random port numbers to accept connection.

IMPLEMEntAtIon

The implementation of collaborative support into graphical-based designed tools is a daunting task.

The design can be different from one tool to another tool. However, collaborators in the workspace should be able to use and share the same components from the server.

According to Maziloglou, Scrivener, and Clark (1994), workspace can be defined as both interpersonal space and shared workspace. In this section, we will discuss the implementation by using peer-to-peer ap-proach as discussed by Minar and Hedlund (2001).

The client logs on to the centralized server and publishes local information. Published information includes the client’s IP address, listen port, and firewall status. The server verifies the client’s username and password. If it is a valid client, a log file is added into the database.

The server then sends a list of active peers who are in the same group as the client. The list includes nodes’

IP address, listen port, and firewall status. The client receives the list and proceeds to work through it, at-tempting to establish connection between the group members.

The client requests for a direct point-to-point con-nection by sending concon-nection request messages. The peer needs to accept the connection request to establish a direct point-to-point connection. In the initial state, the central server is needed to manage and integrate the connection because in the current design it is not possible to establish and maintain connectivity between clients without connecting to the central server. There-fore, central server is needed for peer discovery and peer joining. Clients that connect to the server need authentication from the server such as username and password checking. Clients register with the server to announce their availability in the network. The central server acts as a common user directory service to lo-cate group members at anytime, and also resolves the issue of node discovery for joining clients. A periodic update to this status is tracked so that the server knows Figure 2. Shared workspaces with locking mechanism

With Locking

Client A

Draw rectangle at

(x0,y0)

Shared Workspaces

(Client A)

Shared Workspaces

(Client b) Lock

Client b

translate action

Unlock view



Collaborative Support for Graphical-Based Design Tools

whether the node is still online or no longer available by using a connection checker.

FuturE trEndS

Future work includes research and implementation im-provements. In future, the data transfer over the network would use XML standard. XML is a common standard used to structure information and exchange data using markup tags. Users would need to exchange information in a collaborative environment, even though they are not online simultaneously. A relay server is required to solve the intermittent connectivity problem.

Authentication and authorization process applied in the prototype might not be perfectly secure for distrib-uted environment as discussed by Parashar, Agarwal, Arbeeny, Bhat, and Chowdhury (2001). The research on security itself can be complicated because there are many factors that have to be taken into consideration.

Public key infrastructure (PKI) is a method of allow-ing users of networks such as the Internet to securely and privately exchange messages using public key cryptography. Voice over Internet protocol is a way of IP telephony. It involves the transmission of telephone calls over a network or Internet. VoIP may be used

Public key infrastructure (PKI) is a method of allow-ing users of networks such as the Internet to securely and privately exchange messages using public key cryptography. Voice over Internet protocol is a way of IP telephony. It involves the transmission of telephone calls over a network or Internet. VoIP may be used