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.
It is the creators of Java Application Servers that have to worry about whether their products are "J2EE compliant", not application developers. When the JCP (Java Community Process) publishes a specification of J2EE (Now called Java EE, by the way, not J2EE) If the creator of an Application Server makes a product that conforms to all the specifications, submits it for review, and pays a fee to Sun Microsystems, that manufacturer can claim that their product is J2EE or Java EE version x.x compliant.
As far as application developers are concerned, if they create an application and it runs on a J2EE Application server, it's automatically J2EE compliant.
If we can do all activities using jsp and servlet then why we will think for j2ee.IF we can make mvc pattern using jsp/servlet is there any need for j2ee.
The above question indicates a misunderstanding of what J2EE is. J2EE encompasses a number of other specifications, including the servlet spec, and the JSP spec. So, when you write servlets and JSPs, you are using J2EE.
I suspect that the question you may be meaning to ask is "If we can do everything with Servlets and JSPs, why do we need Enterprise Java Beans (EJBs)?". My answer is, it's true, you can get by without using them. However, they do offer some powerful features that you may want or need in your application, such as security, transactions, remote calls, etc. The EJB spec has been much criticised because of it's bulkiness and complexity. The latest EJB spec (Java EE 5) is much better than previous ones, and much simpler to implement.
My advice is to find out what functions are available in EJBs, and then decide if you need or want those functions. If you don't, then just continue happily developing your applications without them.