We regularly receive, from mobile phone companies, variously-formatted lists of phone numbers that have been disconnected. We need to update our records in response. To automate handling of these, we'd like to purchase the software necessary to create a new service with a web interface that accepts as input, via file-upload, files containing those phone number lists. The new service should produce as output a series of EJB calls to *our* pre-existing service. Each call will simply ask our service to disconnect the number in question, if it belongs to one of our users.
Our Company (OC) provides its users with a realtime information service. One of the primary interfaces between users and the service is mobile phone text-messaging via the SMS protocol. About 8 U.S. mobile phone service providers (MPSPs) have granted OC permission to send computer-generated text messages to OC's users. As part of the terms of this agreement, MPSPs regularly email to OC files that list phone customers who have either discontinued using their mobile phones or changed their phone numbers (we'll call these files "discontinue lists"), and OC has agreed to remove these people from its list of active customers. The MPSP-provided lists vary in their formatting, but at their core they each contain a list of U.S. phone numbers.
We need someone to build a system (the "project system") that accepts as input, via a file-uploading web-interface, a set of variously-formatted discontinue lists. The project system produces as output a series of EJB calls to our pre-existing service, the net effect of which is to suspend OC users' accounts as requested by the MPSPs. The project system should make the calls in sequence, waiting for a response before issuing another call. The project system should be designed so that only one executable can be making calls at a time, ie, several duplicates cannot flood our service in parallel.
In order to interface seamlessly with our existing systems, we'd like the service to be implemented as a Java EE Web Application (either as a Servlet or as a combination of JSPs and Servlets). The front-end of the interface would provide a mechanism for an administrator to upload disconnect lists. Upon successful upload of the lists, the system would generate the appropriate EJB calls, and report to the administrator which numbers belonging to our users were disconnected from the service.
The project system should make it easy to increase the number of MPSPs to 100, with minor variations in input file-format consistent with the types of variations seen in the sample files. A single discontinue list may be from 0 to 1,000,000 lines long.
The current input formats we receive can be described as follows. There will be zero to two phone numbers on each line of each input file. Lines with zero phone numbers may be ignored, and lines with three or more phone numbers should generate an error. Phone numbers are defined as either 11 digits in sequence with the first digit being "1", or 10 digits with the first digit being 2-9. If the digit sequences are broken up by non digits, e.g. 123-456-7890, they are not considered phone numbers. When two or three phone numbers are on a line, they are separated by a whitespace character and/or a comma and/or a "|" character. Lines may include text strings before and/or after the phone number(s), containing for example the name of the MPSP or a date; these text strings should be ignored if they are present. Strings of digits that are less than 10 or more than 11 digits long may be ignored.
Supported input file formats should include .xls, .rtf, .csv, .htm, and .txt. **Samples are attached.**
With the possible exception of a configuration file, the project system is basically "stateless" so it doesn't require a database underneath it, and it doesn't remember whether it's seen a particular phone number or input file before.
We'll expose something like this to you, to a) let the new system determine whether we care about a particular phone number, and b) let the new system inform the old system to disconnect or change a number:
public interface UserManagerRemote
* Called upon notification by a mobile operator that the given number
* has been disconnected. If the number belongs to one of our users,
* we'll de-activate his/her account and send him/her an email notification.
* returns true if the number belonged to one of our users, false otherwise.
public Boolean disconnectMobilePhone(String mobilePhone)
For the sake of debugging and implementing this feature, developer should feel free to simply call a stubbed-out implementation of disconnectMobilePhone(). UnexpectedErrorException is a generic wrapper around the Throwable class.
Deliverables: All software necessary to build, compile, and run the Java EE Web Application. We will add the necessary resource injection (to call our EJBs) upon receipt of the deliverables.
How many users does the business expect for the proposed system? 1-3 users within OC manipulating the project system, all from our Seattle headquarters via a web browser running on a PC or Mac.
How many do you expect to be on the system concurrently? 1
Do OC Partners need to access the system? no
Do you need a new server for development, testing, or staging? Contractor should provide his/her own server for these purposes, but once testing is complete and software is accepted, we'll host all of it on our machine and have no further need of contractor's server(s).
The system is to be deployed in production on an existing server shared with other systems
Backup and Recovery Needs: none. Once the project system is delivered to OC, the backup and recovery of the project system, including its source code, executable code, configuration files, input files and output files are all the responsibility of OC, not the contractor.
Test plan: JUnit tests documented by a thorough test plan. The test plan should show what part of testing is our responsibility and what part is yours.
Deliverables should also include 1) Complete and fully-functional working program(s) in executable form as well as complete source code of all work done.
2) Deliverables must be in ready-to-run condition, as follows (depending on the nature of the deliverables):
a) For web sites or other server-side deliverables intended to only ever exist in one place in the Buyer's environment--Deliverables must be installed by the Seller in ready-to-run condition in the Buyer's environment.
b) For all others including desktop software or software the buyer intends to distribute: A software installation package that will install the software in ready-to-run condition on the platform(s) specified in this bid request.
3) All deliverables will be considered "work made for hire" under U.S. Copyright law. Buyer will receive exclusive and complete copyrights to all work purchased. (No GPL, GNU, 3rd party components, etc. unless all copyright ramifications are explained AND AGREED TO by the buyer on the site per the coder's Seller Legal Agreement).
Java EE Web Application -- see See "deliverables" section.