Please recommend me the best J2EE design pattern
Hello
I decided to rewrite my J2EE application.
This application will be installed on Websphere App Server 5.
My application should return XML's (as String) from remote requests, probably by webservice/es .
There should be 9 kinds of requests.
Which design do you recommend me to use ?
Please suggest a detailed suggestion, as like
1) how many webservices should i use ? 9 services or 1 ?
2) how many EJB's should I use ? What should they do ?
3) which EJB to use (Session ...facade... etc... )
4) should i use JMS & MQ ?
5) How can I avoid memory leaks ?
6) Can you give me a known design name ?
7) etc....
Thanks !
> Hello
> I decided to rewrite my J2EE application.
> This application will be installed on Websphere App
> Server 5.
>
> My application should return XML's (as String) from
> remote requests, probably by webservice/es .
That's one way to do it.
> There should be 9 kinds of requests.
OK.
> Which design do you recommend me to use ?
Follow the Java EE standards.
> Please suggest a detailed suggestion, as like
> 1) how many webservices should i use ? 9 services or 1 ?
Are the 9 requests related in some way? A service interface ought to group the methods into a sensible object that's cohesive. There's no right answer here. Use the number of services that makes sense for your problem.
> 2) how many EJB's should I use ?
You don't need any EJBs. Can you articulate the situations in which you should use EJBs? If you can't, find out what they are. If those situations don't apply to you, don't use them.
> What should they do?
Satisfy user requests.
> 3) which EJB to use (Session ...facade... etc... )
There is no such thing as a Facade EJB. There are stateless and stateful session beans, entity beans, and message driven beans. That's it.
How do services and stateless session beans co-exist? It seems that you'd want one or the other. What are you trying to do here?
> 4) should i use JMS & MQ ?
Do you have asynchronous processes? If yes, use JMS. If you're using WebSphere, you might be an IBM shop with MQ Series. If you know it well, use it. If not, use JMS.
> 5) How can I avoid memory leaks ?
Learn how to write code that doesn't leak. Profile your code.
> 6) Can you give me a known design name ?
Yes - Fred. Bob is good, too. But my favorite is Sally.
Are you getting the idea that you're asking questions that are too general with little or no information?
%
If you have to ask this stuff, it's likely that you don't know enough about Java EE to attempt it.
I'd recommend that you start with a simple web app that uses JSPs with JSTL, a front controller servlet, and Java Beans that implement the DAO pattern for persistence via JDBC. Work your way up from there.
Don't bother with EJBs or JMS or services or anything else until you feel comfortable with this kind of problem. You can always add the other complex bits in later. You can go a long way with just JSPs and JDBC. And it's still very much Java EE.
%
Thanks for answers !
Well let me be more specific.
The remote requesters are going to call one of 9 methods (even parallel), these methods are doing some complicated inspections and searches (not DB) .
Every method eventually should return a String to the requester.
That's all.
Now, I need to know if :
1) only one Stateless session EJB will be good with performance, or should I use more EJB's (say one for each method)?
2) does a webservice is the right way to let the requester access the system ? or should i demand the requesters to request by MQ ?
Thanks!
> Thanks for answers !
>
> Well let me be more specific.
> The remote requesters are going to call one of 9
> methods (even parallel),
Not if it's a web app. HTTP is request/response protocol.
You might have several clients that are all asking for stuff, but that's it.
> these methods are doing some
> complicated inspections and searches (not DB) .
Inspections and searches on what, if not a DB? The Web? File systems?
> Every method eventually should return a String to the requester.
Why a String? What does it represent? Could it be an object of some kind?
>
> That's all.
Still not enough. You haven't added any meaningful new information here.
> Now, I need to know if :
> 1) only one Stateless session EJB will be good with
> performance, or should I use more EJB's (say one for
> each method)?
I think I answered that. You won't know about performance until you measure it. You don't know if EJBs will be the deciding factor.
If you're doing inspections and searches and not writing data I'd say you don't need EJBs.
> 2) does a webservice is the right way to let the
> requester access the system ?
I'd say it's either web services or EJBs. Use the one you know best.
> or should i demand the requesters to request by MQ ?
I don't see a need for JMS, unless the searches are long-running. You still haven't answered whether this is asynch or not.
I don't think you know enough to attempt this. No insult intended, just my opinion.
%
duffymo, Thanks again for your attention:)
I think i know enough to handle this.
I'm just not sure about the architecture, because i'm not a java architect, although i know technically to build all the components and use them.
Sure I dont know everything, thats why i'm asking here in the forum :-)
Please I will answer your questions :
1) I have about 250 clients that are all asking for stuff at the same time.
2) The Inspections and searches are going to be in the file system.
3) Every method eventually should return a String to the requester. This string actually represents XML Response .
4) the requesters are not asking to write data, but only to receive information.
5) you say it's either web services or EJBs. Use the one you know best. - Well actually i know them both fine, but :
6) what is the advantage of any one of them ?
7) which of them is faster ?
8) if i giveup the EJB's so what is all the meaning of Middle Tear without an EJB's ?
9) can you recommend me now about a general architecture ?
Thanks & Bless
> duffymo, Thanks again for your attention:)
>
> I think i know enough to handle this.
OK, I'll take your word for it.
> I'm just not sure about the architecture, because i'm
> not a java architect, although i know technically to
> build all the components and use them.
> Sure I dont know everything, thats why i'm asking
> here in the forum :-)
Neither do I, so we're even. 8) You should take everything I say with a grain of salt. Put it up against your own experiences and see how it looks.
> Please I will answer your questions :
>
> 1) I have about 250 clients that are all asking for stuff at the same time.
The performance will depend on what those clients are doing and the memory and CPU requirements of your hardware. I don't think service versus EJB will be a deciding factor, but my prejudice would be to not use EJBs until I had a compelling reason to do so.
> 2) The Inspections and searches are going to be in the file system.
File IO will be your biggest bottleneck.
Are you using an indexed search engine like Lucene?
> 3) Every method eventually should return a String to
> the requester. This string actually represents XML
> Response .
What's in the response?
> 4) the requesters are not asking to write data, but
> only to receive information.
So everything is read-only? No need for EJBs or transactions.
> 5) you say it's either web services or EJBs. Use the
> one you know best. - Well actually i know them both
> fine, but :
> 6) what is the advantage of any one of them ?
If you have to ask, I'm arguing that you don't "know" them.
For example, you can write a web service so it uses an EJB in the back to do the work.
Both webservices and EJBs can be pretty heavyweight.
> 7) which of them is faster ?
I don't know - you'll have to measure. It's not a one size fits all thing.
> 8) if i giveup the EJB's so what is all the meaning
> of Middle Tear without an EJB's ?
Middle tier is very meaningful without EJBs. Go read about the Spring framework to see what I mean.
> 9) can you recommend me now about a general architecture ?
Yes, I'd recommend Java EE without EJBs or web services. Use Spring. It sounds like you need Lucene for document indexing, too.
> Thanks & Bless
You're most welcome. I'm sorry if I'm not helpful.
%
"For example, you can write a web service so it uses an EJB in the back to do the work".Thats what i have now : a webservice with stateless session EJB in the back to do the work.so my current app is doing well.
then why the questions?how are you measuring "doing well"?%
I measuring it by : 1) efficient & correct j2ee design (most important), which influences also on:2) high availability3) performancebecause of the j2ee complexity, its all about good design.
> I measuring it by :
> 1) efficient & correct j2ee design (most important),
How do you measure "efficient" and "correct"? Something besides your subjective opinion, I hop.e
> which influences also on:
> 2) high availability
Availability has little to do with whether or not you use web services or EJBs.
> 3) performance
Measured how? How are you defining performance? Roundtrip time for a request? Max? Average? Max # of concurrent users?
> because of the j2ee complexity, its all about good design.
Sometimes that same complexity causes bad designs, too. Java EE is no guarantee by itself.
How do you feel about XML as a web service wire protocol as opposed to RMI? Can you quantify what the extra overhead is?
I just don't think you can properly assess this stuff by eye. You don't have any data or hard measurements.
%
> > I measuring it by :
> > 1) efficient & correct j2ee design (most
> important),
>
> How do you measure "efficient" and "correct"?
> Something besides your subjective opinion, I hop.e
I've noticed that there is really a lot of room for creativity when designing J2EE applications. There are some definite patterns that need to be followed, but the most common anti-pattern is the overapplication of patterns. My process usually involves writing the application in the simplest possible way, and refactoring things into "black boxes" as the complexity grows and I need to reduce the detail level of various points of code.
The "black boxes" I mention can be one of a number of things. It could be a POJO, a DAO or an EJB (among other things). Unlike some people, I do have a preference for EJBs over DAOs (I've found the performance of Local CMP EJBs to be very respectable, and they save me a lot of fiddling with databases). So my code would look different from someone else's and still be "correct" J2EE design.
Efficiency is measured in terms of the profiler. If you can't prove that writing something one way is more efficient than another in the profiler, than it's really just a rearrangement of code. Arrange your code for overall maintainability, either by yourself many years hence, or by others on your project team. Sometimes clarity is more important than efficiency. Do you really need your webapp to handle 300 requests per second when it's an intranet application for a small company?
Brian
.> I've noticed that there is really a lot of room for
> creativity when designing J2EE applications. There
> are some definite patterns that need to be followed,
> but the most common anti-pattern is the
> overapplication of patterns.
Agreed.
> My process usually
> involves writing the application in the simplest
> possible way, and refactoring things into "black
> boxes" as the complexity grows and I need to reduce
> the detail level of various points of code.
Sounds like a good approach.
> The "black boxes" I mention can be one of a number of
> things. It could be a POJO, a DAO or an EJB (among
> other things). Unlike some people, I do have a
> preference for EJBs over DAOs (I've found the
> performance of Local CMP EJBs to be very respectable,
> and they save me a lot of fiddling with databases).
> So my code would look different from someone else's
> and still be "correct" J2EE design.
True. I happen to prefer DAOs, because I prefer not to have to use EJBs. Spring gives me that luxury. I can test POJO DAOs without a container. That's worth something.
You might be more skilled with EJBs than most folks. I've heard about people being burned by (n+1) query problems with entity beans (e.g., one round trip per attribute in some cases). They have to go with facades to cut down on network traffic. Is that what you're doing, Brian?
> Efficiency is measured in terms of the profiler. If
> you can't prove that writing something one way is
> more efficient than another in the profiler, than
> it's really just a rearrangement of code. Arrange
> your code for overall maintainability, either by
> yourself many years hence, or by others on your
> project team. Sometimes clarity is more important
> than efficiency.
This is a great point. Development and maintainence time are costs, too. Being clever for the sake of a millisecond or two isn't worth making the app harder to understand and maintain.
> Do you really need your webapp to
> handle 300 requests per second when it's an intranet
> application for a small company?
Excellent points.
%
> Do you really need your webapp to
> handle 300 requests per second when it's an intranet
> application for a small company?
YES!Thats what i need, this is the requirements from this app.
Where did i mentioned its a small intranet
application for my company ? Well its not !
Its going to be a small application indeed , but for a BIG company with a lot of consumers.
the reson i rewrite this application is because it isn't able to hande 300 requests per second - it crashes. (out of memory).
We are missing the point here, and its a pity...
crashes how? out of memory error? what does a crash look like?
is the app clustered? or do you have one app server and one database?
in that case, i'd wonder if web services were for you. xml on the wire means lots of extra bytes for the tags, more work to marshall and unmarshall, parsing, big DOMs in memory, etc. Might be more than you need, for little benefit.
%
> You might be more skilled with EJBs than most folks.
> I've heard about people being burned by (n+1) query
> problems with entity beans (e.g., one round trip per
> attribute in some cases). They have to go with
> facades to cut down on network traffic. Is that
> what you're doing, Brian?
EJBs are a little tricky. I make sure to remember two important points about them: 1) Don't pass references to EJBs anywhere outside the Enterprise tier itself. This is where the facade comes in. The facade should expose all the EJB methods you want to access. 2) EJB Entities are "heavyweight" objects. While it's nice to have all of the relationship data stored inside the object, there's a number of subtle side-effects that get missed. The noticeable one on the network is that passing an EJB Entity reference to a remote method can really cause high network load. Of course that's because all of those Collection member variables get transferred as well. Also, there's some restrictions about iterating through these Collections of child EJBs. The iteration must be done within transaction boundaries. Both are fixed with an application of the Flyweight pattern known as a Data Transfer Object (DTO). DTOs are best used at the "border" between layers. In my example, the "border" is between the Enterprise tier and the Session Facade (which most people place in the Service tier). Therefore, the Session Facade should expose methods which take and return the appropriate DTO type. Methods which use Collections in the Enterprise tier should use an appropriate Collection<DTO> type.
Brian
> YES!Thats what i need, this is the requirements
> from this app.
> Where did i mentioned its a small intranet
> application for my company ? Well its not !
> ts going to be a small application indeed , but for a
> BIG company with a lot of consumers.
Sorry, I only gave a generic overview of how I go about designing an application whose complexity exceeds my ability to visualize it in its entirity. I think most of my advice applies: Write the application in the simplest possible way. I would suggest that it is unlikely that you can write the application to support 250 simultaneous clients as a first attempt, otherwise you would be telling me how to write my J2EE code rather than asking for help. Thereforce, it is best to model the application in the simplest fashion that solves the problem for a few clients. (Not one, client, however. That will fail to create a design that accomodates more than one simultaneous user).
Reiterate this code. Put it into the profiler and find where the bottlenecks are. Identify the bottlenecks that are most likely to cause performance issues for multiple clients. Here, you will have to do stuff outside my experience. My design works well for J2EE applications that only have a few simultaneous clients and can run on a single app server. I know that there are changes that need to be made to better support higher simultaneous client loads. And I'd have to do research to find out what those changes are.
However, I doubt that my design strategy will fail for you. Well-written code is easily refactored (that's what makes it well-written). Once you've identified some strategies for reducing the bottlenecks, or distributing them across multiple clients, then the iteration(s) that improve the overall application performance are unlikely to change the applications overall O/R model.
> We are missing the point here, and its a pity...
I don't think I missed the point. You were asking for overall J2EE design suggestions, and that's what I provided. The bits of my suggestions that don't apply to your specific requirements should be either ignored or extrapolated as appropriate ;)
Brian
> > Hello
> > I decided to rewrite my J2EE application.
> > This application will be installed on Websphere
> App
> > Server 5.
> >
> > My application should return XML's (as String)
> from
> remote requests, probably by webservice/es .
>
> That's one way to do it.
>
> > There should be 9 kinds of requests.
>
> OK.
>
> > Which design do you recommend me to use ?
>
> Follow the Java EE standards.
>
> > Please suggest a detailed suggestion, as like
>
> > 1) how many webservices should i use ? 9 services
> or 1 ?
>
> Are the 9 requests related in some way? A service
> interface ought to group the methods into a sensible
> object that's cohesive. There's no right answer
> here. Use the number of services that makes sense
> for your problem.
>
> > 2) how many EJB's should I use ?
>
> You don't need any EJBs. Can you articulate the
> situations in which you should use EJBs? If you
> can't, find out what they are. If those situations
> don't apply to you, don't use them.
>
> > What should they do?
>
> Satisfy user requests.
>
> > 3) which EJB to use (Session ...facade... etc... )
>
> There is no such thing as a Facade EJB. There are
> stateless and stateful session beans, entity beans,
> and message driven beans. That's it.
>
> How do services and stateless session beans co-exist?
> It seems that you'd want one or the other. What are
> you trying to do here?
>
> > 4) should i use JMS & MQ ?
>
> Do you have asynchronous processes? If yes, use JMS.
> If you're using WebSphere, you might be an IBM shop
> with MQ Series. If you know it well, use it. If
> not, use JMS.
>
> > 5) How can I avoid memory leaks ?
>
> Learn how to write code that doesn't leak. Profile
> your code.
>
> > 6) Can you give me a known design name ?
>
> Yes - Fred. Bob is good, too. But my favorite is
> Sally.
>
> Are you getting the idea that you're asking questions
> that are too general with little or no information?
>
> %
trrtg rgtegt g rgt rgt rt r
> dao is the bestI hear that DAO won a Pattern Grammie 5 years running, and four out of five cats say they prefer it
