need immediate help

[kavins]

you are to design and deploy an e-system that would allow a non-profit organization to track and send the requested information to various parties. More specifically, the organization's responsibility is to send literature regarding its business to people who request it. However, the organization believes that it is handling the situation inefficiently as the same people keep on requesting the information but there is no way to track the duplication. The system will be compromised of seven subsystems namely
1.The Profile subsystem
2.The Security subsystem
3.The Inventory subsystem
4.The Transaction subsystem

1 the transaction bean will be very basic.
- The functions that are required in the Remote interface are
public boolean addRequest (String requestinfo) throws
RemoteException;
public String getTitle (int position) throws
RemoteException;
public int getQuantity (int position) throws
RemoteException;
public String getName (int position) throws
RemoteException;
public String getAddress (int position) throws
RemoteException;
public String getOrganization (int position) throws
RemoteException;
Note: position starts with 1 here not 0.
- the String requestinfo consists of one long String of all the request information
with the * serving as the parser in order to make it easier for everyone.
You can assume the * will never appear as a value in the input only as a parser.
- the add function should return true if the operation was successful and also
assign a unique id for each request. Since Transaction is a stateless session
bean assigning a unique id is a little tricky. The add function will process one
request at a time and give each request a unique number starting from 1 and
then incrementing upward for the next request. Therefore, every time a request
is submitted to the bean the bean should first read in the contents of the
request.txt file and place everything into a hashtable. The keys will serve as the
request id. Then the new request will be assigned the next corresponding
number and then added back into the hashtable and then the whole hashtable
could be either printed to the request.txt file or the corresponding new entry
can be appended to the request.txt file.
- Example of request.txt file
1*Mastering EJB*2*John Smith*123 Main St. Reston VA 20133*GW*
2*Computer Networks*1*Rob Tim*2121 I St. Washington DC*IBM*
. (and the next entry would be assigned the request id 3)
.
.
.
- You can create as many internal helper functions as you like and it is
recommended to create a read and write function that would read and write
data from the request.txt file.
- create a test client that reads in requests from a text file already containing the
*'s as the parser called transaction_input.txt.

- Example of input.txt file
*Mastering EJB*2*John Smith*123 Main St. Reston VA 20133*GW*
*Computer Networks*1*Rob Tim*2121 I St. Washington DC*IBM*
.
.
.
Treat each request as a single transaction and do not worry about any forms of
duplication.
The client calls the add function from the Transaction Bean
and processes each request one at a time and returns true if it has successfully
created a unique id and added the id and all of the request information into the
request.txt file. Also test the getter functions such as getName for position 1 should
return John Smith.



- Think about implementing an approve and reject function in the future so that
an internal user will have the ability to go through each request and manually
approve or reject it. (not needed for now)

-Remember the file names are all case sensitive. Therefore, you will have exactly Transaction.java, TransactionEJB.java, TransactionHome.java, and request.txt files for the Transaction sub-system. Also there will be a Client,java with its transaction_input.txt file.

2. Security Bean
- The Security sub-system will be quite primitive for now. It will consist of two features including uid and password creation and authentication.
- The creation will just be a normal create function that inserts a uid and a password into a text file called password.txt. The uid and password can only be alphanumeric, between 6 to 15 characters, and is seperated by a * in front of the password and after the password in the request.txt file. Insert an end of line after every uid-
password pair.
ex:
John*1ert4t5o*
Tim*er5t*
Steve*yuT6%rt*

[Chris Mathews]

Maybe you should think of a specific question, I am not sure about anyone else, but I am certainly not going to do your homework for you.

[Simon Brown]

I totally agree and also, could you just take a quick look at the naming policy and edit your profile accordingly.
Thanks
Simon
Bartender (moderator) of "J2EE and EJB" forum

[Avi Abrami]

Hi Kavs,
Wow, J2EE is being studied at university, now. I am impressed. Do you know about this web site:
http://www.hotdispatch.com
Ask your question there (and offer a few dollars to the solution provider) and you will get what you seek. (They have no problem with doing people's homework for them -- in exchange for money, of-course!)
By the way, if you do decide to use HotDispatch, I would appreciate it if you said that I referred you. My ID is 455442101
Good Luck,
Avi.