3 Specific Requirements

$Revision: 1.4 $

$Date: 2002/06/17 11:55:17 $

	"Would you please remove any metallic items you're carrying, keys, loose change.... Holy shit!" "Backup. Send backup!"
--"The Matrix"

Abstract

This chapter describes specific system requirements according to the iChilli™ system componets described in section The iChilli Vision.

	Note
	Requirements of must-have nature are marked with the letter 'M' on the right side, optional ones are marked with an 'O'. Requirements which were met^[6] are marked with the symbol while others are marked with the symbol .

Examples:	The mobile EJB container should run on mobile devices that are supporting the PersonalJava spec.	M
	The mobile EJB container should turn the mobile device into a goos that lays golden egs.	O

Functional Requirements

Inputs

Input facility for dtF/AF
Description:	The dtF/AF system considers an application server as a black box with a SPOA^[a]. Basicly dtF/AF will use that communication interface to pass and recieve so called data models, which are the underlying data structures for GUI view elements. So for example dtF/AF might pass a model of a text field containing a user name to the comunication interface. Because of the specific type of the model the application logic behind the communication interface knows how to process that model. After processing, the communication interface might return another model as a corresponding return type, which will be considered to be an output.
Requirements:	The previously described communication interface (SPOA) should be implemented using a Web Service endpoint that is able to handle XML-RPC messages. The Web Service interface was choosen because it is a general purpose interface and could be accessed by almost any programming language.	M
	The Web Service communication interface (e.g. a Web Service endpoint) must be able to process dtF/AF models which are considered to be input.	M
General Purpose Input Facilities
Description:	In general, every bussiness logic should be accessable through the following generic interface type.
Requirements:	JMS Messages	O
	HTTP Requests	O
	SOAP Messages	M
	XML-RPC Messages	M
^[a] Single Point of Access

Operations

Processing of dtF/AF input models
Description:	The dtF/AF system passes so-called models to the previously described input interface of the iChilli™ system. Those models have to be processed and if there are corresponding return types they have to be returned as a dtF/AF model by the communication interface.
Requirements:	The dtF/AF models should be processed by a stateless Session Bean.	M
Flow of Data
Description:	The iChilli™ server system and the PersonalChilli mobile client are loosly coupled systems which are sharing data while beeing wired together. Usually this happens if the mobile client is connected to some kind of a TCP/IP network. There are two distinct ways of how the client and the server system are exchanging data. The server replicates data to the mobile client The client synchronized changes resulting from off-line operations.
Requirements:	Containers are no longer systems that are living in their own self-contained world - They rather are coupled systems exchanging data. This requires a server EJB system to be able to migrate data from the server onto the mobile client system. This process is considered to be implemented using some kind of a replication scheme.	M
	As the server system requires to replicate data to the client, the client in turn requires to synchronize data that changed during an off-line operation with the server.	M
Application Management
Description:	As described in section The iChilli Vision mobile applications need to be registered and versioned during a deployment process, which in turn ensures to be able to manage and administer mobile applications accordingly. This requires the support of two different processes: Available mobile application must be queryable and must be transfered to the client using OTA^[a]. Already installed applications must be queryable by providing some specific type of filters. A filter for example could be 'list all applications of user john doe'. The result would be a list of the applications that are currently installed by John Doe.
Requirements:	Mobile applications must be stored in a repository that could be accessed by mobile clients. The repository should provide a facility that enables mobile users to query mobile applications that are currently available. Additionally to just query the mobile application repository, a user should be able to subscribe to a specific application, which will be then transfered onto his device.	O
	Administrators need a management interface that will provide informations which application is installed on whoms device and what specific version is currently installed on that device. Thus a query engine is required.	O
^[a] Over the Air Provisioning.

Outputs

Returning dtF/AF models
Description:	The dtF/AF system is only capable to handle data models. As previously described, this specific behaviour requires the iChilli™ system to output dtF/AF models.
Requirements:	The Web Service endpoint which serves as a communication interface for dtF/AF should allways return dtF/AF models.	M
Additional data processing
Description:	Non- dtF/AF data processing should output every data type currently specified by the J2EE spec.
Requirements:	The following output should be possible: JMS Messages SOAP/XML-RPC Messages HTTP Messages RMI/RMI-IIOP Messages CORBA Messages Other RPC Based Messages	O

Error Handling

Returning dtF/AF models

Description:

The iChilli™ system must be able to deal with some kind of exeptional situtations. This includes broken network links, failed replication or synchronization attempts at the client site and logging of exeptional situations at the server site.

Requirements:

The client needs to switch to offline mode upon network errors.

Mobile clients based on CDC are supposed to log other exeptions to some log files.

Logging on CLDC based devices is supposed to be discarded because of resource constraints. Allthough on devices such as the Palm Pilot logging to a Record Store might be taken into considerations^[a].

Server are supposed to log exceptional situations to a log file, a socket, an email account ore some other facility currently covered by appropriate logging frameworks^[b].

^[a]

	Note
	The Palm Pilot does not provide a file system, hence it is required to store logs into some kind of a database.

^[b] For example, Log4J or Avalon LogKit.

External Interfaces Requirements

User Interfaces

GUI (Graphical User Interface)
Description:	Generally, at the time there is no user interface required on the server site, at the client site a user interface may be required to start and stop the PersonalChilli mobile EJB server.
Requirements:	Possibility to start/stop/restart the PersonalChilli server.	M
	The GUI follows the Java™ Look & Feel guidelines.	M

Hardware Interfaces

No hardware interfaces must be taken into account.

Software Interfaces

The mobile client has to be compliant to the EJB spec. The server has to be compliant to the J2EE spec. Additionally no specific API^[7] must be developed, since as long as the iChilli™ system is implemented according to the J2EE spec, every other software interface requirement will be met.

Communication Interfaces

Apart from the distributed object layer needed to replicate and synchronize data and the remote web service endpoint that accepts dtF/AF models, no additional communication interface must be considered.

Performance Requirements

System Load Factors

Mobile Client Load Factors
Requirements:	The PersonalChilli server that runs on the mobile device is considered to be a single user system. Thus the system doesn't need to handle concurrency.	M
	Memory consumption shouldn't exceed the 10 MByte limit, as acquired by section Mobile Operating Systems.	M
Mobile Client Load Factors
	The iChilli™ server has to opperate according to system load factors of current J2EE system. Future load factors might be considered to be determined by ECperf™. Allthough during the time writing this diploma thesis, load factors of the iChilli™ server were completly discarded.	M

Database Factors

Database load factors are not taken into account at the time.

Response Factors

Because mobile devices are operating most time on a low transfere rate (see section Wireless Communication Protocols), no specific response factors are taken into consideration.

Resource Utilization

Mobile Resource Utilization
Requirements:	The PersonalChilli server should consume less than 5MByte storage space, because most mobile devices don't support huge storage media types.	M
	While doing computation resulting from some PersonalChilli operations, the remaining operating system should remain stable. That means that the PersonalChilli server shouldn't cause the user interface to not respond to user gestures.	M

Design Constraints

Hardware Environmental Requirements

Description:

The whole iChilli™ system is supposed to run on TCP/IP based network infrastructures. Because the iChilli™ system is devided into client and server peers which will be considerd to run in different subnets, the prefered communication protocol is HTTP. This requirement results from the fact that network providers are securing access to different subnets with firewalls, which might cause some TCP/IP based communication protocols (especially non HTTP protocols) to be blocked.

Because the network interfaces and network communication protocols are operating on a low bandwidth level, bandwidth consumption should remain at a minimum level.

Requirements:

Run on TCP/IP based networks.

The application has to be considered to be able to operate at a low bandwidth.

Software Environmental Requirements

Description:	Since the iChilli™ system is thought as an extension or addition to the dtF/AF system, it has to support specific requirements of the dtF/AF system.
Requirements:	Run on the same J2ME profiles as dtF/AF does.	M
Requirements:	The dtF/AF system has to be considerd a black box, thus it could be only access through specific interfaces.	M

Quality Constraints

Reliability

Requirements:	Incomming dtf/AF models must be processed accordingly.	M
Requirements:	Processing results must be returned to the dtf/AF system accordingly. Return values have to be returned as dtF/AF models.	M

Availability

See section Operations.

Security

Requirements:

dtF/AF models and replication/synchronization data has to be considered to be transefered encrypetd over the radio link.

Maintainability

See section Software Environmental Requirements.

Portability

No additional precautions will be considered, since Java applications are generally platform independent. Allthough it has to be taken into considerations that some J2ME profiles are having API contsraints and thus wouldn't run every Java™ application.

Standards

Requirements:	Java™ source code has to be documented using JavaDoc and has to be formated according to the Sun coding conventions.	M
Requirements:	Unit test have to be implemented using JUnit, J2MEUnit and Jakarta Cactus.	O

^[6] Met in the sense that the architectural design supports that requirement.

^[7] Application Programming Interface