A Component
Based Approach to Creating a
Collaborative
Janth English*,
Roy George*, Mike Evans+
*Department of Computer Science
+Army Research Laboratory
Abstract
Creating new applications can be a complex, time-consuming process that oftentimes results in a product that doesn't behave appropriately. Object oriented software engineering techniques have yielded components, software objects, which can be reused to develop new applications. This paper presents the necessary elements to create a collaboration aware server that integrates components, including legacy systems, into a collaborative environment. It also describes the Distributed Collaborative Battlefield Visualization System (DCBVS)[1]. DCBVS is a software system that currently supports collaboration between a legacy Geographical Information System (GIS) used to visualize the battlefield environment; BV Map -- a GIS based on Open Map, a free Java component; and the Data Server -- an application that manages persistent collaboration objects. Future system developments and proposed components are also discussed.
Keywords: Collaboration Software, Distributed Collaboration, Software Components, Component Development, Software Reuse.
1. Introduction
Certainly, development of cheaper faster memory has led to nothing short of an information revolution. Millions of families have personal computers in their homes capable of performing tasks that mainframe computers could not attempt 30 years ago. This new found access to computers coupled with the advent of the Internet and the World Wide Web has led to the proliferation and sharing of information. Arguably, this era in human history can be called the Information Age. This insatiable desire for information has created a demand for more software products to produce, transform, capture, and display the information.
At the same time, software producers have had a crisis situation with not being able to keep up with the demand for new products. Products that were delivered were in general late and over budget, often lacking the desired functionality and of questionable quality. Object Oriented Software Engineering (OOSE) methodologies applied discipline and engineering principles to the art of producing software. OOSE promised quality software that could deliver the functionality the new market place desired. Their matured products such as Rational Rose automated the design, documentation, and to some degree the software for new applications. OOSE coupled with domain modeling of business enterprises held out the hope that business objects would be created and software companies would mass-produce components that would be reusable by many businesses.
But more than an engineering methodology was required to achieve this software nirvana. The new distributed cross-platform computing environment required standards for interoperability. Standards such as Common Object Request Broker Architecture (CORBA), Java 2 Enterprise Environment (J2EE), Distributed Component Object Model (DCOM), the Extended Markup Language (XML), and even the Java language itself were developed to fulfill specific needs in this area.
Yet, with the interoperability standards, OOSE products, and Object Oriented (OO) languages in place, a proliferation of software components has not materialized. The vision of creating applications by purchasing components and interconnecting them in a "plug-n-play" fashion has not been realized[5]. This cycle of more computers generating a demand for more software has permeated every industry including defense. Demand for applications exceed the ability to produce those applications using the predominate paradigm of little or no reuse of existing software. It is generally agreed that reuse of existing components can produce applications that are (1) more reliable -- the logic has already been tested; (2) scalable -- additional components may be added when necessary; and (3) cheaper -- development time and maintenance is greatly reduced. Since this is the case, why aren't software components being widely created as the next logical step in increasing software production might indicate?
2. Component Development
If existing, reused components were examined, common characteristics would be found among them [1]. First of all, these components address a specific need. Secondly, the components behave well and their functionality is well understood. Lastly, software developers know about the components so that they are able to reuse them in new applications. Good examples of software components that generate significant reuse are Math and Input-Output Libraries. Most programmers would not consider writing their own I/O procedures because they know these procedures exist and that they work. In the same way, software development shops must build and test reliable components and make them available for reuse.
One key to a good component is that it addresses a specific need. The need may be across domains such as a report writer, or, if productivity is to be gained, it may address a domain specific need such as battle planning. To determine the need, the question should be answered affirmatively that this process is one that will be required by other applications and that it can be generalized so as to be useful to those applications.
Once a need for a component is established, engineering efforts must determine the component's scope. Components must be more than just a function; it must provide some functionality. Care must be taken that it does not exceed its responsibility by intruding into other functionality. Components that are domain specific most often supply an internal business need. Even so, engineers should not make the component so specific that it is not easily reused by other applications. One view to keep in mind is that the component may have potential value to like businesses, so that it should be designed and implemented for resale.
A component will live or die by its quality. No matter how much work has gone into it, a component will not be reused if it does not perform the functionality it was designed to perform. The issue of quality cannot be overstated. Components should undergo very strenuous tests, perhaps more than other software because errors will be introduced into every application that utilizes the component.
A component will not be reused if it is not easy to do so. This statement addresses both quality and publicizing issues. From the quality perspective, a component must easily fit into the application. This is most often done through the use of generalized or parameterized code and good documentation on how to use the component. Software developers often feel it is easier to write their own code than to modify someone else's code. When it is determined that a component is safe for reuse, it should be made known to others who could benefit. There is no standard way as yet to determine all the available components. This is something that should be addressed especially as freeware begins to transform the market place. Businesses may want to develop or acquire a software reuse library that would include available components.
Creating software components is an expensive non-trivial task. Distributed applications, including collaboration software, add additional complexity to this process. Engineering a component that is general enough to be widely used and specific enough to be useful requires a rare expertise that some feel borders on the metaphysical. In fact, the authors feel in order to achieve the level of reuse necessary to affect the supply side of the software problem, software components that are domain specific must be developed.
3. The DCBVS Application
Due to advancement in hardware, information, and communication technologies, Battle Planning is an application whose time has come. Battle Planning is a collaborative effort with decision making and wargaming among groups of geographically dispersed personnel in different environments using heterogeneous computer systems and manual operations. The current model is centrally controlled, weakly collaborative, and does not adequately support electronic dissemination or integration of mission critical information. Conversely, the modern battle-planning environment demands pertinent information is disseminated expeditiously. This environment should permit field units to make localized decisions that can be incorporated into the overall plan. The problem, simply stated, is to create a new collaborative environment, which initially would encompass the functionality of an existing legacy system.
It was decided to approach the project from a component perspective taking a long-term view of the software development environment. This means that existing components would be sought for reuse, and that when applicable, components will be created for reuse. An analysis suggested the need for several components to create a solution for the problem. These would include a component that provides the functionality of the legacy system, a component that adds persistence to the battle planning effort, a component that provides a user interface for collaboration, and a server component that enables collaboration among participants. This methodology creates a framework from which other applications may be developed. The project was appropriately named Distributed Collaborative Battle Planning System, DCBVS. Figure 1 depicts the DCBVS Architecture.
The Legacy System Component
The legacy component is a battlefield planning tool developed by the Army research Laboratory (ARL). It is a proprietary Geographical Information System (GIS) that allows the commander to visualize the battle plan. This system aids the commander in fusing disparate information and assists him in understanding the current battlefield state and projecting future states.
Since the functionality of this system is a required feature of the new project, one option to meet this requirement would be to start over -- reengineer and rewrite the component. The rewrite option would make a better more cohesive application, but it would be time consuming and expensive, possibly introducing new errors. Another alternative would be use existing technology to reuse the existing legacy system[3]. This alternative would keep the existing functionality of the current system in tact without introducing defects. It would take less time than a rewrite. This would be the desired solution.
Like many legacy systems, the existing system does not support access to data nor does it share data with other systems. Using Common Object Request Broker Architecture (CORBA) technology, the system was wrapped with an object wrapper to expose its basic access functions [4]. This process made the legacy system a distributed component, allowing it to participate in the new collaborative environment. And, as a component, it can be used by any other application that may require its functionality.
The Database Component
The existing battle planning environment did not include persistent objects in the sense of a traditional database application. Current database technology supply database management systems that provide features such as concurrency control, data integrity, etc. The DBMS is itself a component that supplies this functionality. In addition, a database server component that provides access to the data through an API would also be required.
Before the Plan DB API's could be created, an analysis of the data was completed and a data model created. An analysis of the application domain revealed that the primary objects of interest are Battlefield Entities and Control Measures. A Battlefield Entity is anything in the battle theatre including military objects such as troops and weapons, or civilian objects such as schools and factories. A Control Measure is any instruction given to military personnel. All battlefield entities and control measures have graphical representations. In addition, the Commander is permitted to make notations on the battle plan (Ink objects). The Battlefield Entity, Control Measure, and Ink objects are the artifacts of collaboration, and must be persisted. The conversation surrounding the collaboration and, if available, the video data of the planning session should also be part of the database.
A major step in supporting
collaboration with persistence is to describe a model for the interchange of
data [2]. Artifacts may be described
differently from one department to another or from one application to another. In order to collaborate successfully, there
must be a common understanding of what an artifact means. In the computing environment, this involves
describing a common object for each artifact.
The data structure of the common objects can be minimally represented by
the shared attributes of all. This data
structure becomes the object attributes.
The data model that was implemented is closely mapped to the common data
structure of each artifact (object). The
Plan DB API's were bundled as a component -- a Data Server, which provides
access to the plan data. This new
component is essential to the existing application and provides the framework
for exciting new applications involving knowledge discovery, knowledge
management, and training to name a few.
Figure 2 is a partial listing of the Data Server API's.
The BV Map Component
The proposed system needed an interface that would collaborate with the legacy system and other clients. It was decided to develop a GIS-based tool where users could manipulate artifacts in their own workspace. A virtual, shared workspace is created as each participant views the plan in their own workspace using their own symbols producing a "What You See Is What I See", WYSIWIS, effect with the provision that each sees the plan in their own way.
The BV Map application is mentioned here not merely because of its value as a component, but because it was developed using Open Map, a Java Bean component that is freeware. Open Map has proven to be a quality component, and its' use saved considerable time in the development of the BV Map application. While it is anticipated that other client applications, e.g. http and XML based clients, will be developed as collaborators, BV Map is certainly available for reuse. Because it is written in Java and uses RMI to communicate with the server, it can run on any platform.
The Session Server Component
A collaboration server has many responsibilities associated with providing teledata and a sense of presence. A common virtual environment in which collaborators can interact must be created and maintained. This common virtual environment or session could be described as a set of real-time events that can be shared by multiple users. The session must permit each user to communicate their intent with every other user in the session. There are access and security issues to consider with only valid clients allowed to participate in a session. The server must know at all times who is participating in what sessions and must communicate this information to all as clients are permitted to join and leave sessions at will.
The Session Server must handle concurrency issues as many clients may be acting asynchronously with common objects. This involves receiving all messages from all clients and synchronizing access to shared data. The server must ensure data integrity; in this role, it must be the final arbitrator for the correct state of the shared workspace. The Session Server must incorporate and support fault tolerance. This can be implemented on several levels. If clients leave a session by losing a connection, when they rejoin the session, their workspace should be updated with the current state. Servers should also protect themselves from network failures and other anomalies by periodically saving the current state. Many of these requirements are the same as for any distributed system, and distributed technologies have done much in this area especially on the subject of concurrency control.
The Session Server uses the publish-subscribe model using Java/RMI protocol for communications. It contains two major modules the Session Manager and the Callback Manager. All clients must contact the server to join or create a session, and they are authenticated through the Data Server. When a session client joins or creates a session, it is added to the client list. The client notifies the Server of specific events, which includes changes to system artifacts such as users, map layers, wargaming entities, control measures, and ink drawings. The Server captures all events that occur during the session. When an event notice is received, it is passed to the Callback Server, which notifies all clients on the subscriber list of the event.
Figure 1. DCBVS Architecture
public interface DBServerI extends Remote
{
public static
final String REGISTRY_NAME = "DB Session Server";
long
DBCreatePlan(long pid, String pname, long cdate, long user, String comment)
throws RemoteException;
long
DBCreatePlanUpdate(long pid, long unum, long cdate, long user, String audio,
String video) throws RemoteException;
long
DBGetNextPlanNumber() throws RemoteException;
String
DBGetPlanName(long planID) throws RemoteException;
Vector
DBGetPlanActions(long planUpdateID) throws RemoteException;
Vector DBGetUserPlans(long userNumber) throws
RemoteException;
Vector
DBGetPlans()
throws RemoteException;
Vector
DBGetPlanData(long planUpdateID) throws RemoteException;
long
DBSavePlanActions(Vector actions, long planUpdateID) throws RemoteException;
long DBSave(Vector
objects, long planUpdateID) throws RemoteException;
boolean
DBVerifyUser(String userid, String password) throws RemoteException;
boolean
DBVerifyPlanID(long pid)
throws RemoteException;
boolean DBVerifyPlanName(String name) throws
RemoteException;
}
Figure 2.
The Data Server API
4. Conclusion and Future Work
This paper discussed the advantage of creating applications through the use of components. It also described the characteristics of a viable component. The DCBVS application, which was created with reuse of components in mind, was also presented. DCBVS is a prototype for a battle planning collaboration application; it contains several components including a Legacy Component, a Session Server component and a Data Server component. This framework will allow other clients to participate in the collaborative effort by utilizing the Server API's. In addition, these components may be reused in other applications.
The Session Server and Data Server are currently being tested by another ARL research project. The reuse of these components will save that project considerable time and other resources. This research effort plans to develop knowledge management and knowledge discovery applications by reusing the Data Server component. Future plans include utilizing the knowledge represented in the Plan DB to create training applications.
The component based development approach takes a long term view of the software development productivity problem. Because this type of development looks beyond the immediate problem, it can be more costly. The payoff comes as these components are reused to create new applications.
References
1.
Barnett,
2. English, J., George, R. "Collaborative Planning in a Distributed Environment." Submitted to the ACM SouthEast Conference, 2001.
3.
George, R., English, J., Borhauer, R., Higley, H.,
McCoyd, G. "Developing a
Distributed Collaborative
4.
Higley, H., English, J., McCoyd, G., George, R. "Integrating a Distributed
5. Pye, Ray. "Business Software Components Save Time, Money, and Effort." www.eiffel.com/doc/eiffelworld/5.2/component.html, Interactive Software Engineering, Inc., 2000.
[1] This research is funded in part by the U. S. Army research Laboratory under Cooperative Agreement No. DAAL01-98-2-0065.