Mark Whipple

Author
+ Follow
since Jul 21, 2003
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Mark Whipple

Thanks for the feedback.
We tried to build the chapters on real-world problems that a developer has to address. It is not a patterns book, but we do use patterns in some of the solutions.
Thanks,
Mark
You could build and 'EJB-like' model in Corba, but it would require a lot of work.
EJBs are more than remote object invocations where Corba is primarily exposing and API remotely. EJBs also have inherent patterns that must be followed (such as stateless or stateful session beans, and entity beans).
Corba is intended to provide language independant integration via marshalling mechanisms, where EJBs are a Java solution. You can provide external marshalling with an EJB solution (such as JSPs over HTTP).
They each have some similarities such as security, but the implementation is different.
If you speculate on the intent, the purpose of EJBs is to present a mechanism for building business logic in a container neutral fashion. The business logic is developed using certain patterns. This logic can be applied easily and integrated with other business logic built using the same mechanism.
The intent of Corba is a bit different. It is to expose business in a language neutral fashion, but does not necessarily define patterns for deploying or building the business logic.
In my opinion, there is a fine balance between too many EJBs, and too many methods in an EJB.
I try to use 2 rules from OO design to define the granularity of EJBs. The rules seem to fit well in the EJB model.
Rule 1) Coherency
Rule 2) Responsibility.
Rule 1 states that you do only the things that you are responsible for.
Rule 2 states that you do all that you are responsible for.
As an example, if you have a stock analysis program that has a Stock EJB, you would expose methods on the EJB that set the price, last trading volume, and other data pieces related to stocks. This covers rule 1. But, you would not have a method called addToPortfolio(String portfolioName) in the stock EJB. This would violate rule 2. The second method would belong in the Portfolio EJB.
If you follow these rules, your application definition and use cases will drive the granularity of your EJBs.
Mark
I am of course prejudiced, but think this would be a good reference book for a beginner. It provides examples of common problems seen in J2EE projects in the real world. We took feedback from developers in their work situations to come up with the recipes.
Mark
We used the Weblogic server for our examples. You should be able to use any container that you like. Some of the deployment descriptors will be a bit different, but they are noted in the sample code. The standard deployment descriptors will be the same.
I would recommend working with the JBoss container. It should not require any custom descriptors for the examples.
Depending on the container you choose, you need to include the client connectivity libraries in the applet jar. The client jar files may be RMI underneath, but typically, they define their own protocols for use. For example, the Webogic defines the t3 protocol, while the JBoss container defines jnp as the protocol.
Hope this helps,
Mark
I sounds like your needs might be met using a JMX MBean. Use of a singleton should not reduce scaleability, but spinning a thread in an EJB is not allowed by the spec. JMX provides the capability to have a 'service' that can monitor your report threads and collect the information that you need. It could be accessed via EJBs or external resources.
JBoss is a good example of using MBeans in an application server to provide 'services' to J2EE resources.
Mark