This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
There is Entity Bean's persistenced via JDBC . Each of them has an attribute holding a document. This document can be accessed either via HTTP or Web Services (WS) on an other Application Server (AS) . There is some questions concerning architect: 1. Is it recommended / allowed to write the HTTP or WS client code within the EJB ? If not, what kind of design is recommended ? 2. If both AS's reside within an Intranet (DMZ), shoud be preferred the HTTP solution ?
Well, I would definitely seperate the call to either Http or Web Service outside of the EJB. Keep the responsibilities in seperate classes. So make a single class for accessing each type, and a Facade in front of it so the EJB doesn't need to know which assessing way is occuring.
No I didn't mean that there was or wasn't a need for the EJB. I was saying that the sooner you get to Plain Old Java Objects the more extensible it will be and the least coupled.
If you need managed Transactions, Security, CMP then you need to use EJBs. I just think that EJBs are just an interface to the outside world, a Facade so to speak. There should be zero, no business logic in EJBs. The EJB will delegate that to POJOs.