I think knowing design philosophy of some architecture its nice to compare it with Other similar architecture. Its OK that EJB is defined in certain way. But why it is so? There are not many resources which define the design philosophy like this. Much of the literature discusses 'how' it is done and none discusses 'why' it is designed in this way. Why EJB designers thought they need Stateless, Statefull and EntityBean?
Is there any good resource on EJB that discusses 'why'?
Read "Mastering EJB"
You can download the book in PDF format:
If you go through the books on EJB you will find the answer in initial chapters itself. Rather in first chapter itself.
Just to put the problem and solution in crux I will say that.
Every developer was bugged with the common set of problems
1. Transaction Management.
2. Resource Management.
3. DB Connectivity and DB synch. with the application objects
4. Load balancing.
5. Fail over recovery.
6. Asynchronous processing.
7. Message queues.
9. Unlimited number of concurrent users.
10. Remote Method Invocation.
11. Simplistic Interface exposure.
What sun ppl did is, they came up with a framework that will satisfy all these and many other basic problems. With all above-mentioned things in place, developers now need to concentrate on business domain and any logic needed to develop for specific business needs. With this kind of framework, developers save almost around same amount of time that will go in developing all the above-mentioned features and later testing and debugging the same. Addition to this, you solution for above problem will not a full proof and state of the art. With a community working on setting up standards for the same and many ppl contributing in idea, the solution is more robust that in-house solutions.
This was the reason why container the craziest object in software came to existence. Now this fellow container is a beauty in itself, what it does is it keeps all the objects like session bean, entity bean, message driven beans, db connection pool (if supported by app server vendor). in one basket. And makes sure that any fellow trying to touch the thing will have to first make a request and later container gives reference to the object which will be managed by container for the client.
The best part of the thing is, again this whole stuff is so object oriented that you will realize that same situation is faced by every human in his day-to-day life. Something like what librarian does or a bank does or for that matter a simple video library does. These entire things are real life container and we are all the clients that request some specific object.
The best example is a bank. Bank is a really big container. Imagine that u put in 10 bucks in a bank. And you note down the unique number on that bill. Later when u withdraw 10 bucks from the bank almost 99.99999999999 times u will find that u are getting a different bill from the bank. The bill number what u had does not match with the one what bank has given u. Now are you worried about the thing? The answer is big Nooooooooooooooooooooo
. Cause you are interested in functionality of bill. You are interested in the value of the bill. You are more interested in the interface of bill rather than the real object.
Now once u started using bank container for your money storage. You are least bothered about, putting the money safe from theft and natural hazards. So the common problem of all community is been taken care by bank container and you concentrate on ur day-to-day important activity rather than putting a guard on your 10 bucks.
Hope this helps
Thanks for a wonderful explanation. But still, there is difference between, standard object oriented transaction manager design and design decisions specifically taken for EJB. Most of the features you defined must be common design features of any component oriented transaction monitor. But why EJB design is the way it is?
I was expecting something like 'Design and Evolution of C++'. May good C++ books explain design features of C++ and OO and why they are needed and why they are good. But 'D&E' is the only book which discusses why certain things are there in C++ or are not there in C++.
To understand these things may not be essential to become better programmer, but knowing certainly improves the way you use particular methodology or language.
Thanks for asking the question in more elaborate way. The question is so tricky that you made me think of it for a while. Later I tried finding some of the reasons for why EJBs are the way they are today. Give me a chance to do some loud thinking. Of course what I am writing here is based on experience rather than written stuff, so the validity of these thing is up to personal interpretation. The problem with explaining this Why EJBs are the way they are will be more of story telling. Reason for this is EJBs came to existence to solve practical business oriented problems.
I guess more number of people shall contribute on this, as this shall be a group discussion to find out the reasons rather than monotonous blabber from single person. Having said that let me start thinking loud.
First of all we cant compare c++ with EJBs, reason being C++ was a language which was representing total change in the approach towards writing code and representing software as a whole. The approach was Object Oriented Design and Analysis. It was a milestone in software development, OODA was the step taken in a direction where whole software industry was going to change the way it functions. The way it writes code, the way it designs and the way it was going to deploy applications and support them.
With object oriented, plethora of possibilities opened up, people were able to treat an instance of a class as an operating component and make calls on it and get the work done. Possibility of distributing and reusing the code had increased n folds. Parallel new phenomenon of World Wide Web was weaving its net all across the globe. People where trying to make information the cheapest commodity in market. Once the information held by big institutions and libraries was now available on footpaths, sidewalks and garages.
As we all know the boom of .com, the enigma of .com was gripping the industry, every one was trying to ride the free for all bandwagon and everyone was trying to become rich by providing free services (He he he god only know how that was possible, the basic rule of profit and loss was kept on the shelf). (Yahoo, Hotmail, Lycos, Contest2Win, Bazee, 123Greetings)
Same time, microprocessor manufacturers where keeping up with their pace. Processing capability was reaching higher grounds year by year. Servers that were once housed in a 10,000 sq. ft. were now sitting on 3 by 4 ft tabletops. Computer memory was becoming cheaper and storage space was reaching infinity.
Many countries where agreeing that Privatization and opening up of economy was a way to go, Bill Clinton was talking about global village and Quality and Business process reengineering were the new buzz words. Business houses were trying to work
24 / 7, world was becoming a small place. Fast processing and fast delivery was the mantra to run the business. Respect for environment was a new concept and paperless office was becoming reality.(Even though 3M made millions on Post-it)
With all these factors coming together, simple LAN was not going to help run the businesses, WAN was the inthing and everyone was needed to have presence on it.
With WWW companies were able to use cost effective ways to connect multiple locations. Data that was distributed and redundant was getting refined. Companies were talking of virtual marts and online order processing.(Dell, Amazon, AOL, Ebay, EassJet)
Now lets start putting points for infrastructure that will support all above-mentioned changes and needs.
When CEO, CFO, COO of companies like Visa, MasterCard, P&G, GM, GE, AT&T, Pfizer, Kellogg, Wal-Mart, Barns & Nobel where meeting, they were trying to address these problems.
1. I want to connect all departments, and have proper workflow on global level.
2. I want my inventory to get all the information on the possible procurement of goods from dealers and suppliers beforehand.
3. I dont want to have multiple support systems, but want single system that will help me solve problems on global level.
4. I dont want my customer to wait in line, customer is kind and he/she shall be treated like that.
5. I want to use my money wisely and do not want waste single penny.
And many more
There were many systems, which were capable of doing these things, some of them were specifically designed for business domains, and some were capable of solving common problems.
Some of the names I can think of are, SAP, People Soft, Oracle Apps, Forte.
Now sun people were thinking on a big picture, they were thinking of coming up with a framework that will help all business houses to have all these facilities. Reason for acceptance to suns framework. Small businesses that have all these will operate at high efficiency and later after becoming giants dont need to go for change but can just use the same system.
Lets put the sun solutions along with business needs.
>>I want to connect all departments, and have proper workflow on global level.
Single applications deployed at multiple places, services, which are not available at one location, can be catered through other location by RMI calls.
>>I want my inventory to get all the information on the possible procurement of >>goods from dealers and suppliers beforehand.
Event driven background processing for any possible surprises. (JMS and MDB).
>>I dont want to have multiple support systems, but want single system that will >>help me solve problems on global level.
Clustered processing capabilities with load balancing and RMI.
>>I dont want my customer to wait in line, customer is kind and he/she shall be >>treated like that.
Web based support, leading to server farms, distributed processing, delegation models, Security, optimum utilization of resources (container manager object pooling).
>>I want to use my money wisely and do not want waste single penny.
Suns java philosophy write once run anywhere, With EJBs it can be extended to write once, run anywhere and run from anywhere.
Still EJBs are evolving trying to give state-of-the-art solutions trying to solve problems in more flexible-robust way ;). Some of the things which are going to become or have become integral part of J2EE are JDO, WebServices, Logging, JSF, MDB, DB Pooling and the list goes on
.. I guess I have put-up some good points for the reason of EJBs existence.
After writing all this I can think of only one song by Billy Joel.
We didn't start the fire
It was always burning
Since the world's been turning
We didn't start the fire
No we didn't light it
But we tried to fight it
Hope this helps
If the question was just Why EJB then Chetan Sahasrabuddhe's answer fits in well.But if the question was why EJB is done the way it is now ,then there are more justifications .
One of the reason I can think of is(having Home,Remote interfaces and the implementing Bean class) to have a clear logical separation.Home interfaces are used for Creating,Locating and Removing the EJBs(entities)and Remote interfaces for listing out Business methods.With this kind of approach,a clean separation of functionality is layed out.For a third party or whoever is looking at a pecific EJB,its becomes quite clear as to what this EJB can do in addition to all the container support we get.
In the next level(Entity beans)there is a separation for BMP and CMP which gives the flexibility to the user to either implement the DB related operations himself or depend on the container for this.Similarly in the SessionBean scenario also there is a provision to either have state management support or not.EJB specification this way has layed out a good architecture and at the same time giving lot of flexibility to application server vendors to implement it in their own proprietary fashion.
However EJB specification plays safe by suggesting the users not to depend on Multithreading concepts and File handling capabilities.
Hope this adds up a little more to the answers.
Most big books of EJB do define the necessarity of EJB. If that is the point in question then, you can get the description of it in most good text books on EJB.
But if your question is, why EJBs are categorized as Entity, statefull and stateless then it could be discussed. You rightly said that there is no material describing this. These questions are generally discussed by companies designing app servers like Pramati or Bea. They look to find the short commings in the design of EJB and other tech and try to include their customized technology. For instance weblogic had an analogus of QL much before the EJB2 specs were finalised!
A nice place to look into the issues would be the beta versions of various app servers. They would discuss the short commings in the design and would suggest a fix for it.
Thanks for ur comments .
Excepting same in future.
Is it possible to give some info about jsp and asp..
One more question .. advantages and disadvantaged jsp over asp.
Thanks for your comment again. But still my question was more on the technical ground than the 'big picture'. Why EJB has Session and Entity beans and MTS doesnt? (Comparing these two because these are the only two Component Trasaction systems) Why there is a Stateful Session bean? What factors of Java technology, JVM, runtime type information, excellent reflexive system that JVM has, affected design of EJB? Had it beed designed the same way, if we had different features in Java/JVM?
on slightly different note. I had similar questions on SOAP.
Why to use HTTP for RPC? Why to use XML as a transfer syntax? What drove creators of SOAP to think that way? Why did not they think of any binary protocol? Whats wrong with GIOP? Would they have thought differently if we did not have HTTP, established so well?
Here is the excellent article about why soap was designed the way it is, by one of the creators of SOAP, Don Box.
I wanted this type of literature on EJB.