Proposed Solution – Web-based Command Line Application

Phases

The currently proposed solution contains two Phases-Phase 1 and Phase 2.  Estimation of effort is only provided for Phase 1 in this proposal.

Phase 1

Phase one has got two steps:

Step 1: This step includes the development of the Web-based User Interface, Task Manager, Database and the Maya Adapter.

Step2: This step includes the creation of the Resource Management Solution that includes the Resource Manager and the Job Queue.

Details of each component within Phase 1 are provided in this section.  The estimation of effort and the pricing information is also provided for Phase 1. 

Phase 2

Broad outline of enhancements to the solution is outlined as Phase 2.  Specific tasks or estimation of efforts are provided.  ACME may choose to engage OSS (Open Source Software) for the implementation of Phase 2.  Based on ACME enhancement requirements and timeline requirements another Statement of Work will be generated for Phase 2 at that time.

 

 

The key components of the application are:

 

1.     Web Based User Interface:

 

a.      Authentication

Phase 1: Step 1

There will be two access levels of Administrator and User.  The web pages will have a login screen that requires a username and password for authentication.  The User authentication objectives are limited to understanding the user’s name to identify the associated tasks for that user. 

Phase 1: Step 1

Phase 2 may have security features based on ACME requirements.  Role based security may be considered for this phase. 

 

b.      Task Scheduler

Phase 1: Step 1

A queue-based system that allows a user to submit tasks will be part of this phase.  The user will be able to view submitted and completed tasks.  Priority of tasks may be set based on simple business rules.

Phase 2

The Task Scheduler developed during phase 1 implementation will be upgraded to a sophisticated scheduling and monitoring solution that allows users to filter and view tasks.  Tasks may be scheduled to run at specific time or day with priority settings based on advanced business rules.

 

c.      CL Script Composer

Phase 1: Step 1

The script composer will have two parts

Administrator Config

The administrator config is an xml configuration file that allows an administrator to add new commands.  These commands will be dynamically available to the client through the CL script composer engine.

 

CL script composer engine

This component allows a user to schedule tasks using a web-based interface.  The engine is responsible for dynamically providing the required parameters and validations to abstract away the complexity of the Command Line interface.  An XML configuration file will be maintained by an administrator that will provide the required input for the engine.  This approach means adding and modifying commands become relatively straight forward.  Novice users don’t have to have to gain knowledge in using the Command Line.

 

Phase 2

Phase 2 of the solution will be for advanced features that abstracts away most of the complexity of submission of tasks.  Replicating and repeating tasks and intuitive pre-population of tasks will be part of this phase.

 

d.      Administrator

Phase 1: Step 1

Administrator module will not be part of Phase 1.  The administrator will interact with the configuration files directly without any user interface. 

Phase 2

The administrator module allows the administrator to configure the user profile, password, and any other configuration files.

 

e.      Task Lists

Phase 1: Step 1

A user can get a list of tasks or a list of all tasks running on the system.  The standard output from the command line will be made available to the user as a web link.  The standard output will not be saved in a database but will be provided on a file server.

Phase 2

Administrators will be able to view and reprioritize task lists that include all the available tasks with its status.  Pre-defined business rules will allow automated prioritization of tasks.

 

f.       Reports

Phase 1: Step 1

The administrator will have to run ad hoc queries to run reports. 

Phase 2

The Reports engine will provide standard reports that provide summary information to help management and user make informed decisions. 

2.     Task Manager

a.      Messaging

Phase 1: Step 1

The messaging component provides the ability to send and receive messages to the Command Line adapters, the web user interface and the database.

Phase 2

The messaging component will be enhanced to handle asynchronous communication.  Messages can be prioritized and queued so that guarantee of message delivery can be assured.  The solution may move to a Java Messaging Service (JMS) environment based on ACME’s requirements.

b.      Monitoring

Phase 1: Step 1

The monitoring interface interacts with the CL interface and/or the messaging interface and keeps track of the interaction between CL interface and the rest of the system.

Phase 2

The monitoring interface will be enhanced to handle asynchronous communication.  The solution may move to a Java Messaging Service (JMS) environment based on ACME’s requirements.

 

c.      Logging

Phase 1: Step 1

Logging of data will be at a node level for Phase 1.

Phase 2

The Logging interface will be responsible for logging all relevant information into a database or an ASCII file.    

 

d.      Validating

Phase 1: Step 1

Front-end validation

The front-end validation will allow basic validation before a job submission to avoid common syntax errors.

Back-end validation

A nice to have feature for Phase 1 is the ability to identify if the number of output file matches in input frames and the size of the files are over a predefined value, say 1 MB.

Phase 2

The validation module will be responsible for validating the input parameters and the output values.  Examples are checksums for validation of a successful process or output file counts to ensure successful completion. 

e.      Reporting

Phase 2

The reporting module will be responsible for interaction with the messaging interface/monitoring interface/database to provide the necessary business logic for rendering standard reports.  The UI component will leverage the reporting module to visually represent the reports.

 

3.     Adapter

Phase 1: Step 1

a.      The adapter is responsible for all interactions between the Task Manager and Maya or any other rendering tool.  There will be one adapter for each rendering tool. 

b.      The adapter will take requests in a chosen scripting language for interaction with the CL.  The output from CL will be translated into HTML requests or messages as required.

Phase 2

The adapter will be enhanced and modularized and developed as a component ready to be reused for other tools.  Other rendering tool adapters may be developed in this phase.

 

4.     Resource Manager

Phase 1: Step 2

a.      Groups

The Resource Manager is responsible for creating groups and user association.

b.      Roles

Each user within a group could in turn have specific roles such that there is granularity in defining specific tasks to users within a group.

c.      Pools

The Resource Manager is responsible for identifying nodes/network elements and bundling them to pools. The defined pools would then be related to groups defined within the Resource Manger by the administrator.

 

 

DOWNLOAD FILES: