[prev in list] [next in list] [prev in thread] [next in thread] 

List:       odtug-java-l
Subject:    RE: Deploying J2EE Applications
From:       "Ted Farrell" <ted.farrell () oracle ! com>
Date:       2002-09-05 17:27:17
[Download RAW message or body]

Hey Sanjiv,

> BUT, my questions also inclues the MANAGEMENT and PLANNIG aspects of the packaging.
> I guess I as asking 
>  What is the BASIS for grouping the code?
> Say I have 100 JSPs, 50 Servelets, 50 EJBs (session and entity).
>  
> HOW do I decide how many JAR, EJB-JAR, WAR and EAR files I should make?
>   Is there White paper what helps programmers ( and I guess analyst also)  PLAN this packaging bundle?
>  
> Help on this front also will be gratly appreciated.

The idea is that you will build your war archives (JSPs, HTML & Servlets) 
and ejb archives based on some scheme and then assemble, and re-assemble 
the war, ejb and client archives into ear archives that would represent 
an application.

That said, I would recommend you break down your war and ejb archives into
the smallest self-contained entity you can.  This will give you the biggest
reuse and manageability.  This is much easier to do with EJBs then with 
JSPs & servlets.

In the EJB case this would mean you have a jar file for each EJB and
dependent EJBs. This would contain the 3-4 source files and maybe some 
helper classes for that EJB.  If an EJB relies on other EJBs, you would 
have to include those as well.  So ideally, if you had a customer EJB, 
you would have a jar file for that customer EJB.  You can then assemble 
that into one or more EAR files for the applications that use it.  
The EJB archives should start with an EJB and work out based off code 
dependencies.

Note that this scheme is for optimal reuse and if you really had 50 EJBs, 
and didn't want to deal with a huge number of ejb archives, you might decide 
to be less granular and start grouping your EJBs by logical boundaries to 
reduce the number of archives.  This would restrict you in terms of
reusing smaller components but if that isn't an issue it would save
you the overhead of the extra archives and projects.

In the WAR case, this is more of a logical breakdown (rather than a code
dependency breakdown like the EJB) and therefore more difficult.  You 
should build your WAR archives to contain the UI for the application.  
If you can logically break down the UI into segments or parts that can 
operate independently of each other and could conceivably be reused in other 
applications, that would be a good boundary.  This is usually a hard thing to 
do and in most cases you will have an EAR file with just one or two war files 
and then many ejb and client jar files.  

The EJB archives should each be able to be deployed as-in with no other
dependencies, where the WAR archives usually depend on one or more EJB
archives.  The loaders in the applications servers are aware of this and
will load the EJBs before the WAR and client archives in the EAR file
so you don't get the ClassNotFoundExceptions when loading the WAR files.

If you were deploying them as WAR & JAR files yourself (not in an EAR), 
you would need to deploy the EJB jars first.

This is a basic overview.  If you have specific questions
or would like to discuss this further, I would be happy to get into more
specifics with you as well.  Hope this helps.

	-ted

Ted Farrell
Sr. Director of Technology, App Dev Tools
Oracle Corporation
650-506-9812
ted.farrell@oracle.com 
 




Thanks to everyone for making ODTUG 2002 a great success!  Plan now
for next year's conference: Loews Miami Beach, Florida, June 22-27, 2003.
-- 
Author: Ted Farrell
  INET: ted.farrell@oracle.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ODTUG-JAVA-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

[prev in list] [next in list] [prev in thread] [next in thread]