Need to Convince My Boss


EJB design: Need to Convince My Boss

  1. Need to Convince My Boss (11 messages)

    Dear brothers i need a great favour from you guys actually the requirement is like that our company got a one client who have his serveral outlets of Pharmacy, in the city and out some outside the city now he want solution that he can be able to monitor inventory levels and accounts of different outlets from one place, my boss is not very much technical he always consult with me or one other guy who is working in Visual Basic, as soon as i come to know about this requirement i am sure that this is 100% J2EE and EJB's solution and i need to convince my Boss, but the problem is that i don't no that how this system will work by using EJB's cause i have never gothrough requirement such like that.

    I need to know that how EJB solution is implemented in this situation and also about DB is DB need to centerlized or distributed and if distributed then there is lot of other issues like not every time data available from the central location untill replicate.

    this is my request to all of you guy's that please give me some information regarding this specially DB issue and about its network infrastructure and how EJB's will work.

    I have command over Java and related tech i-e Servlets,Jsp and Struts Frame work but EJB is a new for me.

    Thank for your time and suggestion in advance.

    Threaded Messages (11)

  2. Need to Convince My Boss[ Go to top ]

    You need mitigate design risks.

    Design 2 or 3 solutions in a paper to your problem using Java technology, for each solution choose a different technology (EJB, Web Services, RMI, Corba), also, design 1 Visual Basic solution to your problem and get the pros and cons for each solution. Talk to your friend and your boss.

    If you have all this in paper and arguments, I'm sure Java will be choice, maybe not EJB, but java for sure.
  3. Need to Convince My Boss[ Go to top ]

    Don't use EJB. We use a EJB framework to build a ERP system and it is full of problems. Strange bugs happen all the time and the development process is very slow. EJB seems to be a dinosaur with a little brain. Dozen of classes and files are needed for small tasks. The performance is bad too.
  4. Need to Convince My Boss[ Go to top ]


      It seems you are stuckup with a technology migration mindset :) sorry about that but thatz whay I figured out with your desperation to kick VB and adapt java.

    The simple requirement is, you need distributed gui. The solution for this problem is HTTP. Now once you know you need to use http. you have two technologies.

    1. microsoft
    2. sun - java

    As per the informations supplied by you, you already have a resource in VB. and i guess you too are verygood in VB.

    1. Learning curve for VB to ASP (15 dayz) VB to .Net (3 months)
    2. learning curve for VB to EJB (ohhhhhhhhhhhhhhhhhh .... 9 months, almost a new baby comming to life :))

    Platform availability

    1. Microsoft OS comes with IIS server which has full asp support.
    2. for EJB you need to buy some really costly app server, or user JBoss but then you cant sell the product.

    Database availability

    1. MS Access comes with office and might help you store the data. or if you are planning to use oracle then ODBC support is greaaaaaaaaat.
    2. JDBC is also great and has not glitches, but again u gotta spend on that appserver.

    hope this solves ur problem
  5. Thanks But i am not a VB Guy :o)[ Go to top ]

    Hello Chetan thanks for your help i really appriciate but wana tell you that i am not a VB guy i am a Java guy and have great experiance in Servlets, Jsps and Struts and i love to work in Java and Struts from last 7 months i am using Struts and i feel great and full control on my application when i work in the greatest technologys, but the problem is with me that i have't go through any EJB project and did't work in that, i have read lot of articles on serverside but they only confuse me because there are thousends of design pattrens and i am stuck it with that, that from where to start.

    i am sure that you have go through the requirement i got for that project and i am doing R&D so i can come to some decesion, i have some questions in my mind if you please clear these things to me it will be the great help from you.

    i have come to know that distributing the application and database on each outlet location is a great overhead in the sence lot of extrawork i-e data replication. i feel that centerlized apporach is the best for that type of solutions.

    now i know that the same thing is possible in Simple Java by using Servlets,Struts or Jsp but then where lies EJB's.

    i want to develop this solution using EJB's and for that i need some help regarding from where to start learning and offcourse with a great vision of requirement where it fits.
    i have download a ejbdesignpattrens from theserverside and study few chapters and i have see that all the database logic is written into session beans then where entity bean stand.

    i am not sure that how and from where to start it, i will be very thank full to you if you come with some helping hand.

    with best regards...
  6. Thanks But i am not a VB Guy :o)[ Go to top ]


       Ok first the concept is you need to put db and application server centralized. My general assumption is at a given time you will have at the most 25 to 50 clients doing some operations on your application.

       Ok now letz talk about EJB, I am happy to know that you are into jsp / servlet part, the thing is that will help you a lot in doing view part of your appliction.

       for understanding ejb I will sugget you to download a copy of Mastering EJB II available on same site. It is good that you are going through design patterns, make sure you read about session facade (thats kind of de-facto standard for ejb development).

       Secondly you can go to java site and download J2EE tutorial, this one is really good with some nice examples.

        My suggestion to you will be to write a simple login screen and later write one entitybean which will be attached to your usertable and write a simple sessionbean which will hold your busness methods. try verifying users and see what kind of coding you will have to do.

       For starter you can start with JBoss as a server and you can download JDeveloper IDE from oracle site. (this is freeeeeeeeeeeeee). JDeveloper will help you generating basis ejb templates and hence you will spend more time undersstanding the framework rather than typingin the mandetory code.

    all the best
  7. Thanks Chetan[ Go to top ]

    Thanks Chetan for your kind suggestion i really appreciate it. tell me one thing which will clear my concept about Entity and session bean, let suppose their is table named (users with fields userid and password and some other fields now i need to validate a user, my question is from which bean i need to authenticate the user from session bean or from entity bean and please explain the role of session and entity bean in 2 lines

    with best regards...
  8. Thanks Chetan[ Go to top ]

    Hi Raheel,

    Basically, a session bean handles business logic on data. An entity bean *represents* data (usually an entity bean instance represents a row in a database). So, your session bean would have a method like this which accepts two parameters:

    public boolean authenticate(String username, String password) { //logic }

    Let's say as the username and password parameters, you received "John" and "mypasskey123" respectively. This method should then try to load the entity bean instance whose username field corresponds to "mypasskey123". Then, compare the password paramter you received, with the password field for the entity bean you loaded. If they match, return true, if not, return false.

    *Note: EJBs contain much more sophisticated authentication mechanisms which handle all the authentication and authorisation for you, so typically there is no need to authenticate yourself. Please read "Mastering EJB 2" as reccommended by others - it's essential reading.

  9. Thanks Mal and One More Question[ Go to top ]

    Hi Mal, our company is planning to design a solution for one of our client who have 30 outlets (sell points) in the field of pharmasutical accross the country.

    i am planning to this job in J2EE and by using EJB's but the main problem i am facing is the best network approach, T1 lines are not here, we have other standard that is ISDN with 64K and 128K channels, now i need some suggestion and feedbacks from you guys who have implementaion and practical experiane in that type of solutions where different branches need to connect with one centerlized place, and transaction ratio of some key points are normally 30 transaction / minutes, i-e customers rush on the shops normally the shops in the Hospitals.

    now i am a bit confused because i have never any practical experiance in this sort of solution, the point in my mind is that for example if the centerlized server location is in different city then what about the transaction speed,normally the shops where inventory/accounts software were running is done simple transaction very fast because of no remote call and no network isssue, then where is that solution stand which is in my mind, i am not clear in that and one thing more is that solutions capable of running on simple dialup lines?

    with best regards..
  10. Thanks Mal and One More Question[ Go to top ]

    Hi Raheel,

    For 30 transactions a minute, a 64k or 128k is more than enough. However, you need to consider some implications, most importantly, what happens if the link is down? You can't just stop selling items because there is network failure... that would be catastrophic. Also there are a few other issues, such as peak load... if you handle on average 30 transactions a minute, what is the maximum? 90? 150? Also, the pipe into the centralized application server will need to be of enough size to handle 30 clients (point of sales) connecting to it at once.

    I would reccommend designing your application so that transactions (or sales as you may put it) are as isolated as possible, i.e. each transaction is completely independant of each other. This way, even if the network fails, you can batch up the transactions at the point of sale and then when the network comes back up, you send the transactions along (JMS Messages being sent to Message-Driven Beans are ideal for this scenario as the model is asynchronous and can be batched up together - mind you, your requirements may not be suitable for that model, but most sales type of applications I've worked with use JMS Messages for their guaranteed delivery benefits).

    Do you want the client at a point of sale to have thick functionality or thin functionality? By thick, I mean that a client would contain it's own local records to do with inventory etc and would synchronize with the central server regularly (say at 6pm for reporting purposes). Or would you prefer a thin client, where data was not replicated at the client end but instead all information kept real-time at the central server? If the latter, how do the point of sale stores know how much inventory they have at their particular store? Do they connect to the central server to query this information?

    Also, how about processing payments? With the JMS asynchronous model, the problem that occurs is if you include credit card details etc with a message to be processed at the central server... how do you receive confirmation (and on time) if a credit card payment was processed succesfully? After all, a customer could walk out of the store with the goods giving invalid credit card details, and you wouldn't know until the central server had processed it. Perhaps there will be separate EFTPOS machines at each point of sale to handle all credit card processing though, which makes things a lot easier because then you only send a message to the central server when a payment was succesful. If you do need server-side credit card validation, then it would be more appropriate to use a session bean - but again, if the connection was down, does that mean you stop selling?

    Talk to your client about these issues (and much more) and how to structure the system so that sales keep coming in - the number one rule of enterprise programming is to prevent the situation where a business grinds to a halt because of system issues - design the application with as many fail-safes as possible.

  11. Hello Mall But what about this??[ Go to top ]

    Yes you are right Mall, the network fail possiblity is the very big and major issue in this application although they have POS (point of sale) machines already installed on their locations so validating a credit card is not a issue, any way i will be very great full to you if you give me some suggestion which is in my mind and i am very confuse on that and you have alreay mention in you reply,

    1. What will be the stratergy if Link go down we can't stop sale at store.
    so in this regard if we maintain the date or client side (@ store) and the replicat the data on specific time (6 PM) for reporting purpose then what is the benefit of using EJB's and J2EE plateform it can be done in visual basic & Sqlserver or Oracle / Developer apps.

    2. What will be the stratergy if we are using EJB's and link goes down and we are doing real time transaction on the centeral server what will be the best stratergy for doing that and is the message beans will be the best to do in this case rather then session beans.

    3. In inventory controll applications where you are selling items, you need some of the information of the item for example (item level in inventory and price) from the database so with each transaction i need to call the entity bean from the centerlized server to get the detail of that item or caching trick on client side but with every transaction of perticuler item inventory will be change)

    4. What do you mean by Isolate the transaction i-e you said that every transaction will be seperate from other.

    i will be very greatfull to you for your help.

    with best regards...
  12. Hello Mall But what about this??[ Go to top ]


    To anwer your questions:

    1) Yup, you can also do it in Lotus Domino (which is renowned for it's replication technology). Basically, the implementation of this system using J2EE is both a technical decision and a strategic decision... technically speaking, the flexibility, performance and transactionality of J2EE may be over-kill for this client based on the current requirements of just 30 transactions a minute. As you said, Visual Basic wouldn't break a sweat handling that. However! Strategically, if your client wishes to expand his services, to provide a web site for customers to order products, or supply products to other businesses etc, by using J2EE, the EJBs and core functionality you've written for this simple day trading tool, can be *reused* in the new system, without much difficulty, and the wonder of EJB is its ability to scale, whether it's 30 transactions a minute or 3 million.

    2) Yes, message-driven beans would be more appropriate than session beans for this particular requirement, due to the former's ability to remain in a persistent queue until such time as the link is up. If you are doing real-time transactions on the server and the link goes down (which should be avoided as much as possible by selecting an ISP with multiple backup pipes), well, you can always cache the requests (persist them in a database) and run through them once the link is backup.

    3) Yup, can use chacing with a smart-enumeration type. So the data you require from the central server will be loaded into the client as you use them, i.e. a list of all the items for sale will be retrieved and loaded into the client system when first started up. The details of that item (description etc), can remain on the central server until such time as you access it when processing a payment. Or, you can keep the entire inventory at the client (downloaded and synchronized with the central server at system start-up), and report back to the server the stock levels at the end of the day.

    4) What I mean is, no dependancies between models, i.e. when you purchase Paracetemol, that transaction affects only Paracetemol, you shouldn't have to fiddle with a table representing "off-the-shelf medicine", that information should be implicit in the record that represents the Paracetemol.