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*
Joined: Jul 18, 2001
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.
sharp shooter, and author
Joined: May 10, 2000
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
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.