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
12.References
Java
Servlet Programming, by Jason Hunter with William Crawford
Developing Java Servlets, by James
Goodwill
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
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.
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.
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...
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.
Prepared
by
D.Ramanjaneyulu
Department of
Information Technology
