This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I am looking at Java/JSP to replace a very old DOS/Novell production system. The system is internal only. The database and the web server will be on a local LAN. The system is tracking jobs moving around on a manufacturing floor. Screens that need to check user access before giving information currently have the user scan their badge for authorization. This system doesn't have keyboards only touch screens for the menus and scanners to read badges and travelers. All information is bar-coded. In the old system we know the id is captured by scanning a badge because the software captures the input rate of the scanned characters. If the rate is fast enough to indicate a scanner the user's ID# is checked to see if they are authorized for the screen. Is there a way to do the same thing on a JSP?
The new system won't be on Windows it's on Linux so no active X. The old system is like a web app. It runs on diskless workstations and the screens are stateless unless the task requires authorization. Every job on the floor is displayed as a button that users can touch to view information about where the job is and who is working it. We have seen demos of production tracking systems that are web based and they work well but they are expensive (1-2 million) and require Oracle. We need to update the system because we have to move to an OS that will support access to a database server (DOS does not) and that we can lock down the clients with.
Yes, our scanners Y into the keyboard cable or go directly into the keyboard plug in the back of the machine and the barcode converts to ascii characters. Currently what is barcoded on the badge is the employee's ID number. This is a low tech system but because we can test the scan speed it works. We are considering magnetic scanners instead, but again we need to have newer clients to use them.
There is no financial data in this system, or personal data on employees, its purpose is to collect hours worked on the parts that are moving and to automate WIP and inventory information. The data is uploaded to an accounting system which generates labor information and runs the payroll.
A typical operation would be employee walks to a terminal, touches the button for the job they are working (or scans the job# from the paperwork), scans their badge, picks the next operation the job is going to. The time is stopped for that employee on that job and then the lot is moved to the work center where the next operation will be done.
There will be forms for editing employee information, authorization levels, and task operations but they will require a normal userid - password login using a keyboard.
Originally posted by margaret gillon: Yes, our scanners Y into the keyboard cable or go directly into the keyboard plug in the back of the machine and the barcode converts to ascii characters.
Originally posted by Murthy Tanniru: Look into java card technology
That might be appropriate if Margaret were asking how to implement a new id card infrastructure. As it is, she's asking how to use a scanner to enter a barcode on a web page, and I don't think java card gets her any closer.
Originally posted by margaret gillon: In the old system we know the id is captured by scanning a badge because the software captures the input rate of the scanned characters. If the rate is fast enough to indicate a scanner the user's ID# is checked to see if they are authorized for the screen. Is there a way to do the same thing on a JSP?
While I haven't done exactly this, I have glued bar code scanners to Java, its not a big deal because the ones I used would either pump characters into the serial port, or act as a keyboard. You just read the data as any other data entry.
Most of them (all?) could also enter a "return" at the end.
As others have noted, you want to keep the focus in the field of your screen. And perhaps map the submit form's button to the "return" at the end
I don't understand this requirement. If someone types their id in on a keyboard it is not checked?
Correct. The scanner reads characters very fast and by knowing the speed of the input we can confirm that a scanner read a bar code instead of the password being typed. People who have this software on their desktops still need a scanner to get into the restricted screens. It is an old technology but it works because it makes it very simple for floor workers to register their work without having to type. If a scanner is used the id number is entered in < .1 of a second. So on a GUI interface the id text object measures the time it was filled in and if it is too long the user is sent back to the screen they came from and record is logged with their badge # and what they tried to access.
What's to prevent someone from copying and pasting their ID to pass the speed check.
Nothing. They copy their badge bar codes so they can leave early and their buddies can log them out later. We have reports that check for this. We tried using bar code labels that were 'copy proof' but they were still copied.
A new technology is a possibility but it has to be easy with no typing because we don't want keyboards on the floor and we want the employees to log their work which they won't do if the process is complicated.
I don't understand this requirement. If someone types their id in on a keyboard it is not checked?
I should have answered this better. The screens that expect a scanner check the speed and close if a scanner wasn't used. If you had a keyboard and typed in your id you would never pass the speed test. There are other screens that require a key board such as the screen that edits employee access to reports. These screens use a user id and a password and the user id is not the employee id# that the scanner accepts it is an alpha-numeric user name.
Originally posted by margaret gillon: The screens that expect a scanner check the speed and close if a scanner wasn't used. If you had a keyboard and typed in your id you would never pass the speed test.
The system is tracking employee time. The first time they punch into the system for the day it starts their hours. After that they punch to indicate all the jobs they are working on. During the day they constantly open and close work periods for jobs. We know what parts are being manufactured on each job so we analyze the labor time to value the parts. Since this is manufacturing the employee should always be working on jobs unless they are in training. Supervisors run reports to make sure the employees are punching jobs so that we can account for where all the labor is going. Employees can be written up if they do not punch the jobs they are working on. They can work on multiple jobs at the same time if they are at a work station that does batch operations like furnace runs. An employee might roll a cart up to a clock and move five different jobs to other parts of the plant. They scan their badge, scan the job numbers from the paperwork, tell the clock they are done with these jobs, and then choose the task the job is going to next.
When they leave at night they punch out and all the jobs they still have are closed. The punches are uploaded to the accounting system. The first and last punch go to payroll to show the hours they get paid for and all the other punches are fed into the labor module.
You have answered my question I think. We would need client side code to do what we are doing now and if I want to stay away from client side another technology is needed. We have looked at RFID badges in the past that use proximity scanners and that might be a good replacement for our home made bar code badges.
Originally posted by margaret gillon: We would need client side code to do what we are doing now and if I want to stay away from client side another technology is needed.
Thanks for explaining that. I still don't think you need the speed check. It seems unnecessary. As for "client side" code, remember, Java was built with network-centric programming in mind. Both applets and Java Web Start make it easy to deliver applications (both web and rich client) without a big client footprint. I think Richard has a good point that it would be wise to use real security (as opposed to a check for fast typing) to protect your application. I'd probably break the app in two, and limit the floor machines to only accessing the job portion.
It will be broken into several applications but some reporting that is sensitive does need to be done on the floor. For instance a supervisor can run a screen report that shows what the employees are doing and if they are working the jobs they were assigned. If a part is removed from a job only supervisors are allowed to change the quantities (employees use to be able to do this until it was found they would change quantities if they lost parts instead of tracking the part down).
I thought that there is a way to write web apps so that there is page level security? That is what this needs. The main app is stateless. Any person can walk up to a screen and choose to view any work center and see the jobs in the work center and if they are actively being worked. Anyone can run an inventory report or call a find screen to see where a job is sitting and when it was last worked. All buttons on the screens showing the jobs are rows in a database. Specific reports or editing functions that have their own pages are controlled by checking the access table. There are access groups as well and the groups are used more often than individual access checks except in the payroll editing module.
As for "client side" code, remember, Java was built with network-centric programming in mind. Both applets and Java Web Start make it easy to deliver applications (both web and rich client) without a big client footprint.
I am not worried about the client footprint I am worried about the support for installing clients. Although this is a big company the IT staff is minimal. My division has several hundred people and 3 IT. My boss is retiring next year and I will take his position so then it is 2 IT people. The other IT is a hardware tech with only Windows OS experience. Some hardware support is already outsourced like printer maintenance. Right now the old DOS app is served from Novell so I can update the software quickly and I have stubb programs to kick people out when I need to upgrade.
Novell is big in this schema, we use boot scripts that assign printer queues and the DOS workstations are easy to install. But Novell is getting old and even our backup software vendor won't guarantee the backups now.
Oh, we also get power outages that pop some of the clients. The dust from the floor is also hard on them so they fail quite a bit from heat.
One of our other divisions tried client based replacements with data on an SQLserver and it has been a nightmare. I manage their programmers and we never know where the software is installed. Since the individual clients access the database server directly we have a hard time making upgrades and changes. The client can be started without logging into the Novell software but they're on the LAN so they can still get to the SQLserver. The programmer who wrote the system is gone and no controls were written into the system to do clean shut downs for maintenance. The current staff is too thin and very under trained. The system is OOP (bad OOP) and they don't understand it so I maintain it. The staffing and training are not going to change.
Many days I really envy the AS400 programmer who maintains the accounting system on his mainframe. LOL.
For me web app seems like a viable way to manage the system and support the production floor with the minimal staff resources available (me). The floor machines could run Linux browsers on terminals that we could lock down. Anyone in the offices could run the app from their Windows machines.
Yes: Declarative Web Security. Basically you set up a database with users, groups and roles, then declare in your web.xml who has access to what.
The database is already set up and the roles and users established. It is postgresql and the routines to move data from the DOS app to the postgresql server run daily so I have a starting set of data to roll to.
Not declarative security -- programmatic security with the badges replacing the user name password login. (Defined by Marty Hall: With programmatic security, the topic of the next chapter, protected servlets and JSP pages at least partially manage their own security Marty Hall Core Servlets 2).
That is why how the badges work and how secure they are is important.