1. Course Number:
MSC..number
2. Course Title Java enterprise edition (JEE)
3. Credit Hours: 4
4. Contact Hours:
Lecture
Hours: 4
Lab Hours: 3
5. Suggested Prerequisites:
Object Oriented
Programming
6. course objective
Java Enterprise
Edition(JEE )
Objective: The objective of this course is to provide the student with
an expertise in Java Programming. This includes both the Core Java programming.
After successful completion of the course, the student should be able to
develop, design and maintain web-based enterprise applications effectively.
Computer software, reviews the basic
features and trends in the major types of application software and system
software used to support enterprise and end...
7.Exit Profile: After Completion of this Course, You can start working as
Programmer or software developer or webdesiginer in Java Enterprises Edition.
For M.Sc students in IT ,
|
8. Course Content:
|
|
|
1. Introduction
Java Enterprise Edition
Integrated Application
Development
Web Server or Application
Server
EJB 3 Basics
Projects in Java EE
EJB Security
EJB Deployment
2. Transactions
Need for transactions
Transaction Components
Distributed transactions
Java transactions API
3. Java Beans
EJB Development Overview
The Enterprise Bean Class
Enterprise JavaBeans
Communications
Session beans
Stateless beans
Message driven beans
The Remote Interface
The Home Interface
Deployment Descriptors and
EJB-JAR files
4. Entities and Persistence
Persistence
Entities v session beans
EJB Query Language
Entity relationships
Entity inheritance
5. Design Patterns
EJB Design Patterns
Case studies
6. Writing an EJB Client
Detailed guide
7. Java Message Service
(JMS)
The principles of messaging
systems
Features of the Java
Messaging Service (JMS)
|
|
|
Writing a message driven Bean
Message Driven Bean Clients
8. Web Services in Java
XML in Java
What are web services
Java Architecture for XML
Binding (JAXB)
Soap protocol
WSDL (web service definition
language)
UDDI (Universal Description
Discovery and Integration)
Java API for XML Web
Services (JAXWS)
|
|
9.Evaluation
Quiz 1: 10%
Quiz 2: 10%
Assignment 5%
Attendance &
Class Participation 5%
Lab 20%
Final
Examination: 50%
10.Attendance Policy: students are expected to
attend all class meeting and it is the student’s responsibility to make up any
work missed.
11.Text Book
Enterprise JavaBeans, Fourth Edition: Richard Monson-Haefel, Bill ...
Enterprise JavaBeans 3.1: Andrew Lee Rubinger, Bill Burke ...
12.References
Java
Servlet Programming, by Jason Hunter with William Crawford
Developing Java Servlets, by James Goodwill
Enterprise JavaBeans 3.1, 6th Edition - O'Reilly Media
Enterprise JavaBeans 3.1: Amazon.ca: Andrew Lee Rubinger, Bill ...
Enterprise JavaBeans For Dummies: Amazon.ca: Mac Rinehart: Books
13)· When
to use EJB?
I know it is a bad question, but if
my application use only stateless and statefull session bean. Do I still need
to use EJB and app. server, instead of using servlet with Tomcat??
Why EJB is more scaleable and cluster friendly? Someone said if I want a 24/7 server (which I do), I need to use an app. server. Is it true?
If I use Tomcat, I can still cluster it and failover etc..., what is the true benifit of using app server than just web container?
any help will be appreciated
Regards
Why EJB is more scaleable and cluster friendly? Someone said if I want a 24/7 server (which I do), I need to use an app. server. Is it true?
If I use Tomcat, I can still cluster it and failover etc..., what is the true benifit of using app server than just web container?
any help will be appreciated
Regards
You don't need EJB if you're only
developing a web client.
really? if I want to support pda,
mobile phone etc... do I need to use EJB?
Still you don't need EJB
When one uses EJB, the application
becomes multi-tired. Because of this presentation and business logics are
separated. Besides, for huge applications, one can rely on the services like
security, transaction and persistance provided by application servers. The
developer needs to concentrate on the implementation of business logic.
Some time back, I read an article by
Ed Roman on the same subject. I think it is available in the archives of
theserverside.com. The key points from that article and some other places are
given below:
The definition of EJB states that it is a distributed, transactional, persistent software component written in Java Programming Language. From this definition, it can be derived that EJBs are required in the following scenarios.
i. When the application is distributed: When the resources and data are distributed across multiple sites, then it is ideal to go for an application that is based on EJBs. Choose EJB when you know your application will need to scale beyond initial low usage levels and support multiple, concurrent users.
ii. When the application is performance-centric, use of EJBs and the application server provide high performance and very good scalability.
iii. Declaratively manage transactions. When transaction management is required to ensure data integrity, EJBs may be used. In EJB, you merely specify whether a bean's methods require, disallow, or can be used in the context of a transaction. The EJB container will manage your transaction boundaries appropriately. In a purely servlet architecture, you'll have to write code to manage the transaction, which is difficult if a logical transaction must access multiple DataSources.
iv. Declaratively manage security. The EJB model allows you to indicate a security role that the user must be assigned to in order to invoke a method on a bean.
v. Separation of Business Logic. The most significant difference between a web application using only servlets and one using servlets with EJBs is that the EJB model mandates a separation between display and business logic. This can be achieved using Servlets and DAO also
Hope it helps.
The definition of EJB states that it is a distributed, transactional, persistent software component written in Java Programming Language. From this definition, it can be derived that EJBs are required in the following scenarios.
i. When the application is distributed: When the resources and data are distributed across multiple sites, then it is ideal to go for an application that is based on EJBs. Choose EJB when you know your application will need to scale beyond initial low usage levels and support multiple, concurrent users.
ii. When the application is performance-centric, use of EJBs and the application server provide high performance and very good scalability.
iii. Declaratively manage transactions. When transaction management is required to ensure data integrity, EJBs may be used. In EJB, you merely specify whether a bean's methods require, disallow, or can be used in the context of a transaction. The EJB container will manage your transaction boundaries appropriately. In a purely servlet architecture, you'll have to write code to manage the transaction, which is difficult if a logical transaction must access multiple DataSources.
iv. Declaratively manage security. The EJB model allows you to indicate a security role that the user must be assigned to in order to invoke a method on a bean.
v. Separation of Business Logic. The most significant difference between a web application using only servlets and one using servlets with EJBs is that the EJB model mandates a separation between display and business logic. This can be achieved using Servlets and DAO also
Hope it helps.
Hi,
I have my points and questions :
When the application is distributed:
What does it really mean a distributed application ? Does it mean multiple users use one application connecting to a multiple database spread across network or something else ?
When the application is performance-centric
I think performance-centric has nothing to do with EJB.
Declaratively manage transactions
Hibernate and XA can do this as well.
Declaratively manage security
I agree at this point.
Separation of Business Logic
Spring + Hibernate + Struts do that as well.
This can be achieved using Servlets and DAO also
So, I think the only thing you use EJB is only when you have a security feature. Other than that, Hibernate is a good alternative to use.
Ben.
I have my points and questions :
When the application is distributed:
What does it really mean a distributed application ? Does it mean multiple users use one application connecting to a multiple database spread across network or something else ?
When the application is performance-centric
I think performance-centric has nothing to do with EJB.
Declaratively manage transactions
Hibernate and XA can do this as well.
Declaratively manage security
I agree at this point.
Separation of Business Logic
Spring + Hibernate + Struts do that as well.
This can be achieved using Servlets and DAO also
So, I think the only thing you use EJB is only when you have a security feature. Other than that, Hibernate is a good alternative to use.
Ben.
Hi,I have my points and questions :When the application
is distributed: What does it really mean a distributed application?
That the application consists of
multiple (physical) components. And note that database is not part of the
application.
When the application is
performance-centricI think performance-centric has
nothing to do with EJB.
EJB (when correctly applied) make
your application scalable, as they can be clustered. Of course you can achieve
scalability by clustering whole application and load-balance incoimng client
requests (e.g. HTTP) instead of intermediate, intra-application requests (e.g.
RMI/IIOP). Also EJB are thread-safe so it's rather trivial to avoid any
contentions due to locking in the application.
Another thing EJB have with performance is that they can greatly increase latency due to overhead, if their use is too fine-grained or if the app server sucks...
Another thing EJB have with performance is that they can greatly increase latency due to overhead, if their use is too fine-grained or if the app server sucks...
Declaratively manage transactionsHibernate and XA can do this as well.
Actually, Spring (Spring AOP to be
exact) can. With Hibernate and XA you can do it only programmatically.
Declaratively manage securityI agree at this point.
Again, this could be done with
Spring AOP. But as far as I know there are no pre-made "aspects".
To me this thread shows exactly what
is wrong with our profession. Too many people read the marketing literature and
take it as gospel.
You use EJB when and only when you need the container services. That is, transaction, persistence and security. Now if you follow the advice of most and don't use Entity beans that leaves you with security and transaction. Very few people use the security features on EJB so that leaves you with transactions. There are many other often easier ways to deal with transactions though so it is still questionable if you ever need EJB.
Let us examine some of the comments made so far.
1. Scalability - Why is it more scalable? If you are using Stateless session beans you are scalable because you are stateless. But if you are stateless it is just as easy to use POJOs (Plain old Java Objects) . Stateless design leads to better scalability but EJBs are not necessary to make your application stateless. Again the only advantage is the container services provides - otherwise it is just code folks - and your code will work just fine.
While we are at it lets address another common misconception. Lifecycle management. It is often claimed that EJB gives you some necessary lifecycle management and object pooling. It also is supposed to help you in a multi threaded environment. The trouble with this claim is that if you are stateless there are no threading issues and you only need one instance to handle all of your clients on a server. Servlets and stateless Session beans are essentially equivalent ( keep in mind that HTTPServlets are only one type of Servlet). In the world of Servlets the spec allowed you to either create a new Servlet for every client or to use one and make it thread safe. Every servlet container does it the second way and yet EJB only allows containers to do it the first way.
2. Performance - ??? What are they doing to improve performance. I can either call an object directly or go through layers of infrastructure - which do you think would be faster. Again only if we need the infrastructure is it an advantage (and NONE of the EJB infrastructure is to help with performance).
3. Maintainability - If I use OO programming methodology instead of the procedural based EJB I will be better off not worse off here. Why do people think that only EJB will get you modularity? Also testability is more difficult with EJB then POJOs and by decreasing testability I decress maintainability.
4. Different clients - Granted you need a server to handle the different clients but you don't need EJB for them to all call the same code. You just need the same object to call. Objects themselves don't care about who your client is. If I have some object Foo with method bar and that method is such that I can have copies of it in different app servers that are all the same ( a requirement for clustering) then all I have to do is have each client create a Foo and call foo.bar(). Why is it better to do the JNDI lookup to find the Foo (when they are all the same) and then use an RMI layer to call the bar. Even if we are calling the database here it is the conection pooling and the database that gives you your advantages - and there were connection pools long before there were app servers and you can use them in an AppServer even if you are a POJO.
5. Database access - One poster said if you use your JSP/Servlets to access the database all the time it will be slower because you don't get help from the container. This is a false dichotomy. I can still have an object layer and a data access layer and never have my JSP/Servlets directly make SQL calls. I don't need EJB for that and unless you are using Entity beans which means you have an extremely simple domain model, the container is doing nothing for you here.
History is important here. EJB arose out of a desire to make CORBA easier to deal with. The reason you would use CORBA is as an integration technology. You had a system (maybe an old batch system) that you wanted to access from an OO or other program. With a CORBA interface you could make it more object like to the client. When doing this properly there were some cross cutting concerns that crop up like Transaction management, Security etc that people designed frameworks to get around. EJB was supposed to help here. The problem is that the context - a wrapper for older technology or across system boundaries was lost and now people advocate using EJB when it is all one system, you don't distribute, and it is a brand new app. But why? I love JMS for integration but I don't think you should endlessly send messages to yourself within an application.
Most projects should have at most one or two EJBs but I see people create systems with hundreds of them. This is stupid and wasteful. You have made your build times longer, your deployments more complex, and your code harder to test. What would be better for our industry is for people to actually learn about OO Design and stop with trying to shove procedural technology in the way and calling that progress.
You use EJB when and only when you need the container services. That is, transaction, persistence and security. Now if you follow the advice of most and don't use Entity beans that leaves you with security and transaction. Very few people use the security features on EJB so that leaves you with transactions. There are many other often easier ways to deal with transactions though so it is still questionable if you ever need EJB.
Let us examine some of the comments made so far.
1. Scalability - Why is it more scalable? If you are using Stateless session beans you are scalable because you are stateless. But if you are stateless it is just as easy to use POJOs (Plain old Java Objects) . Stateless design leads to better scalability but EJBs are not necessary to make your application stateless. Again the only advantage is the container services provides - otherwise it is just code folks - and your code will work just fine.
While we are at it lets address another common misconception. Lifecycle management. It is often claimed that EJB gives you some necessary lifecycle management and object pooling. It also is supposed to help you in a multi threaded environment. The trouble with this claim is that if you are stateless there are no threading issues and you only need one instance to handle all of your clients on a server. Servlets and stateless Session beans are essentially equivalent ( keep in mind that HTTPServlets are only one type of Servlet). In the world of Servlets the spec allowed you to either create a new Servlet for every client or to use one and make it thread safe. Every servlet container does it the second way and yet EJB only allows containers to do it the first way.
2. Performance - ??? What are they doing to improve performance. I can either call an object directly or go through layers of infrastructure - which do you think would be faster. Again only if we need the infrastructure is it an advantage (and NONE of the EJB infrastructure is to help with performance).
3. Maintainability - If I use OO programming methodology instead of the procedural based EJB I will be better off not worse off here. Why do people think that only EJB will get you modularity? Also testability is more difficult with EJB then POJOs and by decreasing testability I decress maintainability.
4. Different clients - Granted you need a server to handle the different clients but you don't need EJB for them to all call the same code. You just need the same object to call. Objects themselves don't care about who your client is. If I have some object Foo with method bar and that method is such that I can have copies of it in different app servers that are all the same ( a requirement for clustering) then all I have to do is have each client create a Foo and call foo.bar(). Why is it better to do the JNDI lookup to find the Foo (when they are all the same) and then use an RMI layer to call the bar. Even if we are calling the database here it is the conection pooling and the database that gives you your advantages - and there were connection pools long before there were app servers and you can use them in an AppServer even if you are a POJO.
5. Database access - One poster said if you use your JSP/Servlets to access the database all the time it will be slower because you don't get help from the container. This is a false dichotomy. I can still have an object layer and a data access layer and never have my JSP/Servlets directly make SQL calls. I don't need EJB for that and unless you are using Entity beans which means you have an extremely simple domain model, the container is doing nothing for you here.
History is important here. EJB arose out of a desire to make CORBA easier to deal with. The reason you would use CORBA is as an integration technology. You had a system (maybe an old batch system) that you wanted to access from an OO or other program. With a CORBA interface you could make it more object like to the client. When doing this properly there were some cross cutting concerns that crop up like Transaction management, Security etc that people designed frameworks to get around. EJB was supposed to help here. The problem is that the context - a wrapper for older technology or across system boundaries was lost and now people advocate using EJB when it is all one system, you don't distribute, and it is a brand new app. But why? I love JMS for integration but I don't think you should endlessly send messages to yourself within an application.
Most projects should have at most one or two EJBs but I see people create systems with hundreds of them. This is stupid and wasteful. You have made your build times longer, your deployments more complex, and your code harder to test. What would be better for our industry is for people to actually learn about OO Design and stop with trying to shove procedural technology in the way and calling that progress.
Prepared by
D.Ramanjaneyulu
Department of
Information Technology
కామెంట్లు లేవు:
కామెంట్ను పోస్ట్ చేయండి