Go Premium for a chance to win a PS4. Enter to Win

x
?
Solved

EJBs and MDBs in a Service Provider.I need some URGENT help plz

Posted on 2004-04-26
7
Medium Priority
?
230 Views
Last Modified: 2013-11-24
Hello all ..
im actually about to design a distributed service provider across a LAN..users register at a service provider server and then receive messages through their pc., namely an alert service and chat system. I would be using JMS with the publish subscribe model in the J2EE environment..i have downloaded the SunOne application server bundle which includes Sun Message Queue as JMS provider.


The basic technology decisions for the implementation of this application are as follows:
·      A Java-based client side application for users to interact with. The SWING (JFC) toolkit will be used.
·      A J2EE-compliant application server to handle the middleware chores. (SUN ONE Application Server)
·      A JMS-complaint messaging product to tie all the subsystems together. (SUN ONE Message Queue, which is bundled within SUN ONE application server.)
·      A database server

Ive read about EJBs(Session beans, entity beans) and the new Message Driven Bean. My design problem is that I don’t know how many beans are needed to implement the system. Users will have to login into the system, and their credentials shall be checked to those in the remote database located on the server. Upon successful login, if there are any messages pending for them, they could be sent to their pc (alert service).
Also, I’d like to know what is the functionality of each bean. Can you plz provide some light on this design issue?
Thanks a lot..
Hoping a reply from you soon,
Drftwy
0
Comment
Question by:Driftaway
  • 3
5 Comments
 
LVL 30

Expert Comment

by:Mayank S
ID: 10917965
>> I don’t know how many beans are needed to implement the system

You could tell us what are the various functions to be carried out by the application. That would help estimating the number of beans required. Do you want to use session beans or entity beans?

>> their credentials shall be checked to those in the remote database located on the server

That could be done in a UserService EJB which performs all user-related functions. That makes one EJB so far.
0
 

Author Comment

by:Driftaway
ID: 10918304
Well mayankeagle ..lets go deeper into the subject

1.there are two main services..the first one (Chat application) is rather straight forward to implement using the JMS pub sub messagin model.

2.the second one (an reminder service) enables users to post messages at specific times/date (e.g like send me a msg on my pc on 12/12/2004 telling me that i have to check my mail..).

3. the third service is a virtual finance account. it will monitor how many msgs are sent to a particular user and then calculate the cost sending messages to their pc (eg: 5p/message).at the end of each month, if the user hasnt paid in the amount he owes (Virtually), then the system cuts out his quota for messages. he will still be able to chat but not use the reminder service.

 4. forthly, an extension of the system would be be: instead of receiving messages through their computers, users will be able to receive the service via their mobile phones in the form of a Short Message Service (SMS)...  

ps: which one of these would be more useful for each functionality?session or entity beans?

thanks a lot.
Drftwy

0
 
LVL 4

Accepted Solution

by:
illusionz70 earned 1000 total points
ID: 10925308
maybe if all these questions were answered , the company wuldnt hire you , :)

As far as the number of ejbs go , u'll have to find out yourself.make sure you create diferent ejbs only when your business logic changes.for eg, Login logic is different from sending reminders.but sending reminders thru either sms or emails may not be altogehter different.i hope u are getting what i am saying.

session/entity beans --> ???? stateless beans would reuce the complexity i guess.dont see the need for entity in either case.but well thats my opinion
0
 
LVL 30

Assisted Solution

by:Mayank S
Mayank S earned 1000 total points
ID: 10925354
I would also agree that stateless session beans would greatly reduce the complexity, especially because of their simplicity. Simple database transactions can very well be carried out by them.

For the number of EJBs - you will have to figure out what common logic you can put in your EJBs. At first - assume that you need one EJB per specific service. Then, if its possible to put 2 services in 1 EJB - do that. Make sure the code in any of them doesn't go two long because of that otherwise it becomes difficult to maintain.
0
 
LVL 30

Expert Comment

by:Mayank S
ID: 11162325
Please proceed with that recommendation.
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Introduction This article is the last of three articles that explain why and how the Experts Exchange QA Team does test automation for our web site. This article covers our test design approach and then goes through a simple test case example, how …
In this post we will learn how to make Android Gesture Tutorial and give different functionality whenever a user Touch or Scroll android screen.
Viewers learn how to read error messages and identify possible mistakes that could cause hours of frustration. Coding is as much about debugging your code as it is about writing it. Define Error Message: Line Numbers: Type of Error: Break Down…
Viewers will learn one way to get user input in Java. Introduce the Scanner object: Declare the variable that stores the user input: An example prompting the user for input: Methods you need to invoke in order to properly get  user input:
Suggested Courses

876 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question