• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Henry Wong
Saloon Keepers:
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Tim Moores
  • Mikalai Zaikin
Bartenders:
  • Frits Walraven

To EJB or not to EJB

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,

I have some doubts using EJB in the FlyByNight project.
What is the rationale of using EJB here.
An architecture without EJB can be more performant and scalable.
Collacated architectures (web container based- single JVM) can be scaled well and more performant than EJB centric approach.

EJB here can only be good for its declarative transaction management and its capability of transparently handling transactions accros transaction resources behind the scenes.

Making FlyByNight project as a distributed application can be an overkill and over engineering.

Distributed applications can be better scaled when the session state is stoed in the web tier not in the EJB tier. Sun recommends us storing session state in the EJB tier. That makes the scability harder to handle. Cause EJB containers has more overhead then web containers when it comes to state replication.

The only thing I see here to use EJBs in this project is because SUN wants it being used, transaction handling can be done automatically by the EJB container and You do not need to write SQL for CMP beans.

By the way, Swing clients can be handled through a servlet. That way we do not need to open our business objects to outher world through a session bean. Getting browser and swing requests thru the web tier is a better approach and one do not get into firewall issues at all. (calling session bean from a swing client directly will get into firewall issues)


Are these reasons enough for EJB being used even when the perfomance and scability issues suffers...

One last thing, Session beans should be used just to wrap the business logic in POJO's. and Entity beans should be used only to access data sources. Putting business logic into EJB would not make that design maintainable. Say you want to remove EJB's for some reason in the future.If you kept your business logic in POJO's you can do that. But If you used EJB for business logic, you need to rewrite the whole thing in POJOS..

EJB does not make sense to me unless It is used in environment where scability is needed at highest levels, components are scattered around the world and a distributed architecture is needed and the state session is stored in web tier not in EJB tier...

Thanks

Cengiz
 
Ranch Hand
Posts: 1906
3
Hibernate Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Part of the assignment is deciding what you think is the best way to create a solution, which Java EE technologies you should be using, etc. You can determine for yourself which ones you choose, depending on which version of the specification you decide to utilize. If you decide that you can better do the assignment without EJBs, that is your right (as it would be if you decide that EJBs are the right thing to use), so long as you can justify it.
 
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I guess you are true for practical purposes.But this is an assignment , where the expectation would be to use EJB, I think the reviewers would be looking for EJB.I also tell my cleints that EJB should be used sparingly, even in clusters Web containers tend to perform better.
But the issue is persistance and data store management.When you want to persist data , web containers is ill equiped to take care of that , here in EJBs can be of much use.Session Beans and servlet controllers can be interchanged.But you need entity beans.You can pretty much use standard ORM tools like Hibernate but that is not recommended.In SCEA world it is expected that you should use EJB, JMS etc for you design assignment.

" Project teams are never 100% democratic ", one of my ex colleagues said that to me, and I found it to be absolutely true.Same here , may be there are better designs available, but the expectations here are like this.

 
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Cengiz,

I just wanted to say that if Swing accesses FBN via a servlet, this could be too slow to meet the response time for the travel agents.

If you are wondering which objects should be implemented as entity beans, take a look at composite entity pattern.

Regards,
Saha
 
Cengiz Kayay
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi

Yes I think you are right about the expectations of SUN for using EJB's in the project. And you might be right about using servlet could be slower due to XML parsing. Accessing a session bean from remote has also considerable overhead but I have not done the comparison in speed and throughput...

In short, We are not doing the most efficent architecture here but we are meeting the requirements with tradeoffs in place.

Thanks for the replies...
Cengiz
 
There's a hole in the bucket, dear Liza, dear Liza, a hole in the bucket, dear liza, a tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic