1. Practical Web Application Architectures using IBM WebSphere
Geoff Hambrick
IBM WebSphere Enablement Team

2. Introduction This session will include:
an overview of IBM WebSphere Standard and Advanced runtime architectures
each will be treated separately
practical details about the programming model:
components a developer has to program, and how
the kinds of services that are available and how are they used
best practices, from both bottoms up and top down perspectives
discussion of scenarios that you will likely encounter
hands on examples illustrating various "design patterns" useful in developing web applications

3. Why IBM WebSphere? Initial scenarios focused on Web Publishing
world wide access to essentially static information
not much distinction between clients
can get by with read-only non-transactional services
Kasparov
Internet
Client
Internet
Web Server
Client

4. Why IBM WebSphere? Rapidly evolving to personalized Web Applications
tie customers, business partners and employees together using the Web
need transactions, persistence and security under program control
drive the need for a Web Application Server to provide these services and necessary infrastructure
Internet
Banking Data Center
(CICS, IMS, DB2, Oracle)
Bank Customer
Extranet
Insurance Underwriter
Web Application Server
Intranet
Loan Officer

5. Why? IBM WebSphere Provides a Complete End to End Solution
1. Development Phase
Multi-author environment
library system
Multi-disciplinary team
HTML, Java and content
Publishing to web server
Web Team
IBM WebSphere Studio
Workbench
NetObjects Fusion
ScriptBuilder
VA java
Multiple Business Server Platforms
(AIX, SUN. NT, MVS...)
Data center
Existing
Apps & DBs
(CICS, IMS, DB2, Oracle)
Staging
Server
Development
Server
2. Production Phase
Runtime environment
Load balancing
Directory, Security
3. Evaluation Phase
Link checking
Site mapping
Usage patterns
Performance statistics
Clustered Production
Web App Servers
IBM WebSphere Application Server
Performance Pack
IBM Connector Series
IBM WebSphere Site Analysis Tools
Web master

6. Standard Runtime Architecture: Web Application Server
High level view
Assumes web applications consist of three logical tiers, but IBM WebSphere Standard only includes middle tier components
Web Server
Web Application Server
Client
Back-end
Web
Sphere plug-in
HTTP
Client
typically is a Web browser that communicates to the Web Server using HTTP
Middle Tier
requests for static pages are handled directly by the WebServer (Standard includes IBM HTTP Server)
dynamic requests are passed to the Web Application Server (in or out process) through the WAS plug-in
Back End
repository of enterprise function and data
communication with client depends on technology

7. Standard Runtime Architecture: Inside the Web Application Server
Java representations for each of the three logical tiers:
Web Server
Web Application Server
Client
Back-end
Web
Sphere plug-in
Servlet Services
Application Components
Connectors
JAVA
JAVA
HTTP
JAVA
JAVA
Servlet Services
standard Java APIs to handle HTTP requests from client
Application Components
standard artifacts programmed by Web Application developers using Java
Connectors (not included with IBM WebSphere Standard Edition)
Java APIs to handle access to back end resources

8. Standard Runtime Architecture: Web Application Components
Standard artifacts programmed by the developer for the middle tier, roughly one component for each logical tier
Web Server
Web Application Server
Client
Back-end
Web
Sphere plug-in
Servlet Services
Application Components
Connectors
JAVA
HTTP Servlet
JAVA
JAVA
JAVA
HTTP
Java
Server Page
Java Bean
JAVA
JAVA
JAVA
HttpServlets
Java programs that control the application flow from page to page
Java Server Pages
extend HTML to alllow fill-in-the blanks from programmatic components
Java Beans (no special support provided by IBM WebSphere Runtime)
provide an extensible contract between other application components

9. Web Application components:
HTTP Servlets
In general, Java servlets are an open standard for executing code on a server:
get all the advantages of Java
easy to code object model
platform independent
are called within the server process
have access to security and transaction context
remain resident once they are loaded for performance
service method handles one or more requests
are themselves stateless
servlets scale across clustered, multiprocessor, multithreaded environments
have access to various Java standard services to maintain state

10. Web Application components: HTTP Servlets (continued)
HTTP Servlets are a standard Java servlet subtype that:
can be found in javax.servlet.http.* package
installed into <IBMWEBAS>/servlets directory
have methods to handle various lifecycle events and HTTP requests
most common are doGet(), doPost(), doPut()
the service() method is overridden when the processing is the same across request type
the init() and destroy() method can be used for one time startup and shutdown logic
can be used to explicitly generate a reply on behalf of the Web Server
HTML, MIME, XML, DHTML
however, are best used to encapsulate conditional application flow logic
leave the presentation logic to Java Server Pages
encapsulate business logic in Java Beans, connectors

11. HttpServlets: A high-level end-to-end flow
Web Server
Web Application Server
Client
Back-end
Web
Sphere plug-in
Servlet Services
Application Components
Connectors 2.
JAVA
HTTP Servlet
JAVA 3.
JAVA
JAVA 1.
HTTP 4.
Java
Server Page
Java Bean
JAVA
JAVA
JAVA
Browser sends HTTP request for an HttpServlet to the Web Server
web server uses its specific mapping rules and determines it should route request to the Web Sphere plug in
plug in activates a Web Application Server (in or out process)
Web Application Server activates HttpServlet with appropriate Servlet Services
Servlet accesses information from servlet services to determine what to do
HttpServlet generates the appropriate HTML reply back to WAS through the Servlet Services based on result
WAS routes reply back to plug in, which passes though to the Web Server specific APIs
Web Server routes reply back to the Browser for handling
action depends on the reply contents

12. HTTP Servlets: HitCount1 example
Purpose:
shows how an HttpServlet can be used to generate any and all dynamic content
gets values from a number of sources (e.g. instance variables, session state)
shows basic structure of an HttpServlet class
implements service method anda private method to handle CHECKED radio button
however, at this point we don't care too much about the details of the code
graphically illustrates why "monolithic" servlets have development/maintainability problems
HTML is hidden in println statements and cannot be edited with WYSIWYG editors
changing layout requires testing of application flow logic and vice versa

13. HitCount1 example (continued)
HTTP Servlets:
HitCount1 example (continued)
How to run it:
put HitCount1.class in <IBMWEBAS>/servlets directory
URL will be
try various radio buttons and hit Increment to "count up" and note behaviors in various circumstances
servlet instance variable resets when WAS is brought down and is flaky in concurrent user situations
session state (create if necessary) resets when all browsers on client are stopped or on session timeout
existing session state only will fail first time browser is started or on timeout
sum of active sessions also fails the first time or on timeout, but may show a different count than session if:
there are other clients using HitCount* with the session options
you recycled your browser and "orphaned" a session state value within the timeout period

14. HitCount1 example (continued)
HTTP Servlets:
HitCount1 example (continued)
Statistics (a rough estimate of complexity):
number of new components: 1
source (bytes): 6054
Things to try:
change the logic, for example:
default to no action (rather than "SRV")
synchronize increment of count to make code thread safe
change the layout:
remove "no cache" calls and check out behavior differences
add session count to sum of active sessions choice
in any case you will have to:
edit the HitCount1.java file (use WordPad)
compile it (javac HitCount1.java)
move HitCount1.class to <IBMWebAS>/servlets

15. Web Application components:
Java Server Pages
What is it:
provides a standard server side scripting language as extensions to HTML
JavaSoft standard (with IBM "template" extensions that are being considered for inclusion)
JSP files are deployed into webserver's HTML directory
WAS plug-in automatically "compiles" them into HttpServlets
best used when the content is mostly static, with some fill-in-the-blanks
can be edited using WYSIWYG tools
should be treated as a "view" component with no control logic
can be used to replace explicitly coded HttpServlets to eliminate compile step, however:
no longer easily edited by a WYSIWYG tool
should be treated as a "controller" component with no display logic

16. Web Application components: Java Server Pages (continued)
Most common tags:
set up a JavaBean to be used later using <%=beanname.property%> tags
can be created or not, and scoped to a request, session or user profile
<BEAN name="name in scope" varname="name above" type="class || interface name"
create="yes || no" beanName="class or .ser file name"
introspect="yes || no" scope="request || session || userprofile" >
<param "propertyname"="value to set after instantiation" ... >
</BEAN>
set a value or declare method to be substituted later using <%=variable> tags
<SCRIPT> runat=server>
String variable = code to set the value;
</SCRIPT>
to insert some java code that will directly generate output use <% ... %>, but mainly for:
"controller" JSPs (that call another JSP for layout)
read only data access code
dynamic tables and lists, or tags (like CHECKED or SELECTED) that can only appear on one item

17. Java Server Pages: A high level end-to-end flow
Web Server
Web Application Server
Client
Back-end
Web
Sphere plug-in
HTTP Servlet Response
HTTP Servlet Request
HTTP Session Context
HTTP Session
Servlet Services
Application Components
Connectors
JAVA
HTTP Servlet
JAVA
JAVA
JAVA 1.
HTTP 4.
Java
Server Page
Java Bean 2.
JAVA
JAVA
JAVA 3.
Browser sends HTTP request for a JSP to the Web Server
Web Application Server compiles the JSP into an HttpServlet and invokes it
JSP generates HTML reply back to Web Server
Web Server routes reply back to the Browser for handling as before

18. Java Server Pages: HitCount2a example
Purpose:
shows how to use a JSP in place of an HttpServlet
control logic is embedded in <% %> tags
JSP must now read values from request in <%= %>
illustrates similar problems with monolithic programs
still must test both logic and layout if either one changes
cannot use WYSIWYG tools to edit layout
cannot use IDE tools to edit logic
How to run it:
put HitCount2a.jsp in <WebServer>/<HTML> directory
URL will be
Functionally, there is no difference
However:
no need for an explicit compile step
performance is slower (a lot on first call)
Statistics:
number of new components: 1
source code (bytes): 4307
difference with HttpServlet is due to elimination of lots of Java syntax

19. HttpServlets plus Java Server Pages: A high-level end-to-end flow
Web Server
Web Application Server
Client
Back-end
Web
Sphere plug-in
Servlet Services
Application Components
Connectors 2.
JAVA
HTTP Servlet
JAVA
JAVA
JAVA 1. 3.
HTTP 5.
Java
Server Page
Java Bean
JAVA
JAVA
JAVA 4.
Browser sends HTTP request for an HttpServlet to the Web Server (as before)
Web Application Server activates HttpServlet with appropriate Servlet Services
Servlet accesses information from servlet services and connectors to determine which JSP to call
HttpServlet activates the appropriate JSP with appropriate services
details to be discussed later
JSP accesses information from servlet services to generate HTML reply back to Web Server
Web Server routes reply back to the Browser for handling as before

20. HttpServlets plus Java Server Pages:
HitCount2 example
Purpose:
shows how a Servlet can be used with JSPs to generate dynamic content
eliminates all the layout code from the servlet
sets string value for count message and source into HttpServletRequest
shows basic structure of a JSP
mostly HTML tags
use of <SCRIPT> tag to implement method to handle CHECKED radio buttons
use of <% %> tag to insert code to prevent caching of result and get attribute values from request
use of <%= %> tags to compute CHECKED attribute on radio buttons and insert count message
graphically illustrates how this MV architecture is easier to develop and maintain
HTML is in a separate file and can be edited with WYSIWYG editors
layout can be is independent of application flow logic and vice versa
however, shows the "looseness" of the contract between the HttpServlet and JSP
need something to document request attribute name/value semantics
not toolable, so cannot use drag and drop tools to generate <% %> and <%= %>

21. HttpServlets plus Java Server Pages: HitCount2 example (continued)
How to run it:
put HitCount2.class in <IBMWEBAS>/servlets directory
put HitCount2.jsp in <WebServer>/<HTML> directory
URL will be
starts with an empty page, but then behaves exactly like HitCount1
Statistics:
number of new components: 2 (HttpServlet, JSP)
source code (bytes): 5857 (4643, 1214)
has 97 fewer bytes of total source code than HitCount1 due to elimination of println related logic
Things to try:
change just the logic in HitCount2.java
follow steps from HitCount1
change just the layout in HitCount2.jsp
simply edit the .jsp in <WebServer>/<HTML>
change the "contract" between them by adding a new variable to display

22. Web Application components:
Java Beans
JavaSoft's "self descriptive, toolable" object standard
provide a means to encapsulate functions and data
tools and programs can query JavaBean about available methods and properties
Java Beans can be "externalized" and "internalized" (serialized)
to and from a .ser file
provides a degree of single instance persistence and configurability
controlled by program in which Bean is instantiated
Typical applications:
Applet Presentation classes (e.g. tables, dialogs)
not discussed here
Common data access classes (e.g. database queries)
will see an example of this later
Contracts between components (e.g. HttpServlets and JSPs)
basically a "pass by value" data structure

23. HttpServlets + JSPs + JavaBeans: A high level end-to-end flow
Web Server
Web Application Server
Client
Back-end
Web
Sphere plug-in
Servlet Services
Application Components
Connectors 2.
JAVA
HTTP Servlet
JAVA
JAVA
JAVA 1. 4. 3.
HTTP 8.
Java
Server Page
Java Bean 5.
JAVA
JAVA
JAVA 7. 6.
Browser sends HTTP request for an HttpServlet to the Web Server (as before)
Web Application Server activates HttpServlet with appropriate Servlet Services (as before)
HttpServlet creates and loads a JavaBean with the results
HttpServlet activates the appropriate JSP with a reference to the JavaBean
JSP requests result information from Java Bean
Java Bean returns values back to JSP
JSP generates HTML reply back to Web Server, filling in the blanks with the values requested
Web Server routes reply back to the Browser for handling as before

24. HttpServlets + JSPs + Java Beans:
HitCount3 example
Purpose:
shows how a Servlet can be used with JSPs to generate dynamic content using a JavaBean contract
HttpServlet news up JavaBean, sets its attributes, then adds it into the request attributes
JSP uses <Bean> tag instead of <% %> to get values for <%= %> tags
JavaBean encapsulates attribute values and checked method to handle conditional logic
illustrates need for extensions to JSP
need <NO_CACHE> tag to replace "shotgun" approach
possibly others, like for radio buttons to simplify logic to handle "CHECKED" attribute

25. HttpServlets + JSPs + Java Beans: HitCount3 example (continued)
How to run it:
put HitCount3.class and HitCountBean.class in <IBMWEBAS>/servlets directory
put HitCount3.jsp in <WebServer>/<HTML> directory
URL will be
Statistics:
number of new components: 3 (HttpServlet, JSP, JavaBean)
source code (bytes): 6129 (4718, 942, and 469, respectively)
HttpServlet is 75 bytes larger than HitCount2 due to overhead of creating Bean and setting values
JSP is 272 bytes smaller and much less complex due to elimination of:
<SCRIPT> tag to define checked method (resides in JavaBean)
code to get request attributes (replaced by <Bean> tag)
overall application is 272 bytes larger (coincidentally), however:
the JavaBean source code serves as project documentation (can use javadoc)
can use JavaBean wizards (like those in IBM WebSphere Studio) to code with it
the previous application did not consider this complexity at all...

26. Standard Runtime Architecture: Servlet Services
Represents the client tier within the Web Application Server
part of the javax.servlet.http.* package
Web Server
Web Application Server
Client
Back-end
Web
Sphere plug-in
Servlet Services
Application Components
Connectors
HTTP Servlet Request
JAVA
HTTP Servlet
JAVA
JAVA
JAVA
HTTP Session
HTTP
HTTP Session Context
Java
Server Page
Java Bean
JAVA
JAVA
JAVA
HTTP Servlet Response
HttpServletRequest
provides access to URL parameters, session state, and the session context
HttpServletResponse
provides methods to control and generate the reply or invoke other application components
HttpSession
used to maintain user session data between requests (can be clustered)
HttpSessionContext
enables coordination between multiple user sessions

27. Servlet Services: HttpServletRequest
What is it:
encapsulates WebServer API differences related to getting request data
reference is obtained from service() and do<XXX>() methods
Most commonly used functions:
determine what parameters can be found in the URL (if any)
String[] names = request.getParameterNames();
parse parameters from the request URL
String[] values = request.getParameterValues("name");
values is null if the named parameter is not found
get an existing user session associated with this request (if any)
HttpSession session = request.getSession(false);
will only return session state if it already exists
get an existing user session, or create it if necessary
HttpSession session = request.getSession(true);
set new values to pass to "chained" servlets (including Java Server Pages)
this is how request specific JavaBeans are passed to JSPs
((com.sun.server.http.HttpServiceRequest)request).setAttribute("name", value);
get an attribute passed from a chaining HttpServlet
<Type> value = (<Type>)request.getAttribute("name");
value is null if attribute does not exist

28. Servlet Services: HttpSession
What is it:
a standard interface to maintain user session (conversational) information
required because HTTP is a "stateless" protocol
data is stored on the server and mapped to user through a session ID
our implementation works with a cluster of Web Application Servers
reference is obtained from either:
the HttpRequest (for the one associated with the request)
the HttpSessionContext (given a specific session id)
trades quality of service for ease of use
cannot count on persistence of session data
can time out
do not use as a "poor man's" database
best to use for easily recomputable values, such as:
login tokens
references to objects that are expensive to obtain
values must be serializable to allow the data to be:
passed among servers in a cluster
cached in and out of memory

29. HttpSession (continued)
Servlet Services:
HttpSession (continued)
Most commonly used functions:
set an application specific value
session.putValue("name", value);
value must be a serializable Object for clustering and persistence to work
get an application specific value set previously
<Type> value = (<Type>)session.getValue("name");
value is null if the name does not exist in the session
get the session id
often used to provide cross linking between sessions in "collaborative” applications
String sessionId = session.getId();
get the session context
used to locate other user sessions in collaborative applications
HttpSessionContext context = session.getSessionContext();
"kill" the session (can trigger HttpSessionBindingListener event)
session.invalidate(); // remember: sessions are associated with the user, not an individual HttpServlet
session.removeValue("name"); // removes just the values desired, rather than whole session

30. Servlet Services: HttpSessionContext
What is it:
provides a standard interface to coordinate multiple sessions
for example:
on line auctions
multi-player games (checkers, bridge)
same user across multiple machines (or browser instances that don't share cookies)
reference is obtained from an HttpSession
like sessions, using HTTPSessionContext trades off quality of service, especially security, for ease of use
beware of inadvertently affecting other application session data (all is accessible)
probably best to use directory, database or EJB instead

31. HttpSessionContext (continued)
Servlet Services:
HttpSessionContext (continued)
Most commonly used functions
get a specific user session:
HttpSession session = context.getSession("session Id");
session returned is null if the session id is not found
iterate through the sessions in a context:
Enumeration ids = context.getIds();
while (ids.hasMoreElements()) {
String id = (String) ids.nextElement();
HttpSession session = context.getSession(id);
// Operate on the session returned (may be null) }

32. HttpServletResponse (continued)
Servlet Services:
HttpServletResponse (continued)
What is it:
encapsulates WebServer API differences related to generating the response to an HTTP request
reference is obtained from service() and do<XXX>() methods
Functions that can be ignored if using MVC architecture:
to write HTML sent to the browser in response to the request
should mainly be used within a Java Server Page, if explicitly at all (see HitCount1 vs. HitCount2)
PrintWriter pw = response.getWriter(); // retrieves object into which HTML can be written
pw.print(<HTML string>); or pw.println(<HTML string>);
pw.flush() // optional, to insure block of data is written
to set the header to avoid caching of dynamic pages instead of <Meta> tags
should mainly be used within a Java Server Page
response.setHeader("Pragma", "No-cache");
response.setHeader("Cache-Control", "no-cache");
response.setDateHeader("Expires",0);

33. HttpServletResponse (continued)
Servlet Services:
HttpServletResponse (continued)
Functions needed if using MVC architecture:
to directly invoke a Java Server Page from an HttpServlet (or another JSP)
this is the best performing method for generating HTML from within "read only" HttpServlets
downside is that browser redisplay functions (e.g. back, forward, resize, reload) re-execute servlet when caching is disabled using the above technique
see HitCount2 and HitCount3 for an example
((com.sun.server.http.HttpServiceResponse)response).callpage(
<JSP URL>, <HttpRequest> );
to redirect to another URL
done so that redisplay does not cause update HttpServlets to be executed over and over
response.sendRedirect(<url + query string>);

34. Servlet-JSP redirect using URL only: A high level end-to-end flow
Web Server
Web Application Server
Client
Back-end
Web
Sphere plug-in
HTTP Servlet Response
HTTP Servlet Request
HTTP Session Context
HTTP Session
Servlet Services
Application Components
Connectors 2.
JAVA
HTTP Servlet
JAVA 5. 3.
JAVA
JAVA 1.
HTTP 4.
Java
Server Page
Java Bean 8. 6.
JAVA
JAVA
JAVA 7.
Browser sends HTTP request for an HttpServlet to the Web Server as before
Web Application Server activates HttpServlet with appropriate Servlet Services as before
HttpServlet invokes a sendRedirect with the JSP after setting attributes into URL
Web Server sends URL redirection for JSP back to Client
Browser receives the redirection and sends an HTTP request for the JSP directly
WAS activates the JSP with attributes in the request
JSP generates HTML reply back to Web Server, filling in the blanks with the values requested
Web Server routes reply back to the Browser for handling as before

35. Servlet-JSP redirect using URL only:
HitCount4 example
Purpose:
shows how to use URL redirection when selected from page
display values must be appended to URL (requires string conversion)
JSP must now read values from request in <%= %>
also shows how cache disabling code can sometimes be eliminated in JSP
we can treat the JSP like a static page once it formats the results
How to run it:
put HitCount4.class in <IBMWEBAS>/servlets directory
put HitCount4.jsp in <WebServer>/<HTML> directory
URL will be
Check differences with previous examples
Increment button is the only event that causes a "hit" on the HttpServlet
performance is a little slower when the HttpServlet is hit
however, redisplay is faster unless cache is cleared (no traffic at all!)
even then, the JSP is directly invoked, eliminating the first round trip (flows 1-4)
Statistics:
number of new components: 2 (HttpServlet, JSP)
source code (bytes): 5729 (4653, 1076)
comparison with previous example is not as important (different behavior)

36. Servlet-JSP redirect using JavaBeans: A high level end-to-end flow
Web Server
Web Application Server
Client
Back-end
Web
Sphere plug-in
Servlet Services
HTTP Servlet Response
HTTP Servlet Request
HTTP Session Context
HTTP Session
Application Components
Connectors 2.
JAVA
HTTP Servlet
JAVA 6. 4.
JAVA
JAVA 1. 3.
HTTP 5.
Java
Server Page
Java Bean
11. 7. 8.
JAVA
JAVA
JAVA
10. 9.
Browser sends HTTP request for an HttpServlet to the Web Server as before
Web Application Server activates HttpServlet with appropriate Servlet Services as before
HttpServlet creates and loads a JavaBean with the results as before
HttpServlet invokes a sendRedirect with the JSP after setting JavaBean into session state
WebServer routes URL for JSP back to Client
Browser intercepts the reply and sends an HTTP request for the JSP directly
WAS activates the JSP with the Java Bean reference in session state
JSP requests result information from the Java Bean
Java Bean returns values back to JSP
JSP generates HTML reply back to Web Server, filling in the blanks with the values requested
Web Server routes reply back to the Browser for handling as before

37. Servlet-JSP redirect using JavaBeans: Hands on example (HitCount5)
Purpose:
shows how to use URL redirection with a Java Bean
display values must be set into a Bean
Bean must be set into session state
JSP must use Bean tag scoped to session state
shows first example of JavaBean reuse!
HitCount3Bean can be used as is...
How to run it:
put HitCount5.class in <IBMWEBAS>/servlets directory (HitCount3Bean.class should be there already)
put HitCount5.jsp in <WebServer>/<HTML> directory
URL will be
select URL redirection and check differences with HitCount4
URL line on browser has no parameters displayed
use of session state may have performance implications in a cluster under load
when session state expires, "defaults" are displayed if reload is forced
Statistics:
number of new components: 2 (HttpServlet, JSP)
Java Bean doesn't count as it is reused
source code (bytes): 5693 (4902, 791)

38. Standard Runtime Architecture: Connectors
A variety of Java APIs over connections to back end resources (not included with Standard Edition)
Web Server
Web Application Server
Client
Back-end
Web
Sphere plug-in
Servlet Services
Application Components
Connectors
HTTP Servlet Request
JAVA
HTTP Servlet
JAVA
JDBC
DB2 UDB
JAVA
JAVA
HTTP Session
CICS Java Gateway
CICS
HTTP
HTTP Session Context
Java
Server Page
Java Bean
MQ Connector
MQSeries
JAVA
JAVA
JAVA
HTTP Servlet Response
...
...
Java Data Base Connectivity (JDBC) over UDB
based on a JavaSoft standard
provides for dynamic SQL queries into relational database backed up by DB2 Universal DataBase
Others
in a nutshell, HTTPServlets and JavaBeans are excellent clients anywhere there are Java APIs provided
CICS, MQ, IMS, ComponentBroker, SanFransisco, CORBA ORBs, ...
just make sure to include the appropriate packages in the CLASSPATH (in bootstrap properties)

39. Java Data Base Connectivity
Connector APIs:
Java Data Base Connectivity
What is it:
provides a standard interface to execute dynamic relational database queries
is part of javax.sql.* package
the current implementation is based on DB2 Universal Database
can use other databases with appropriate driver

40. Connector APIs: JDBC (continued)
Most commonly used functions:
obtain a connection to the database (consider using connection manager)
use a "class" method (often handled in HttpServlet init() method)
Class.forName("COM.ibm.db2.jdbc.app.DB2Driver"); // only need be done once
Connection con = DriverManager.getConnection("database URL"); // once per connection
create an object through which to execute one or more SQL statements
Statement stmt = con.createStatement();
should close() statement when done
execute a command that is not expected to return a result
e.g. "insert" and "update"
do not forget to "commit" changes
stmt.executeQuery("statement");
execute a query that is expected to return a result
e.g. "select" statements
ResultSet result = stmt.executeQuery("statement");
while (result.next()) {
<Type> value = (<Type> )result.getObject(<item# in query select clause>);
// Operate on this or other values as desired }

41. HttpServlet-JDBC: A high level end-to-end flow
Web Server
Web Application Server
Client
Back-end
Web
Sphere plug-in
Servlet Services
Application Components
Connectors 2. 3. 4.
HTTP Servlet Request
JAVA
HTTP Servlet
JAVA
JDBC
DB2 UDB 5. 6.
JAVA
JAVA 1.
HTTP Session
CICS Java Gateway
CICS
HTTP
HTTP Session Context
Java
Server Page
Java Bean
MQ Connector
MQSeries
JAVA
JAVA
JAVA
HTTP Servlet Response
...
...
Web Server makes a request for an HttpServlet as before
Web Application server invokes the HttpServlet as before
HttpServlet directly accesses JDBC using connection and statement object
JDBC implementation sends SQL calls to DB2 UDB
DB2 UDB sends the result back to the JDBC client
JDBC implementation converts the results into Java variables and returns them to the HttpServlet
- ?. HttpServlet uses one of the previous techniques for generating HTML
directly embedded in the HttpServlet code
JSP from request attributes or a bean, using URL redirection or callpage

42. HttpServlet-JDBC: HitCount6 example
Purpose:
shows how to use JDBC within a Servlet
adds button to JSP
adds code to HTTPServlet (connection made in init method)
everything else is the same as HitCount5
reuses HitCountBean3 again in redirect call
How to run it:
put HitCount6.class in <IBMWEBAS>/servlets directory
HitCount3Bean.class should be there already
put HitCount6.jsp in <WebServer>/<HTML> directory
must have DB2 UDB 5.0 or better with samples installed
create table HITCOUNT (primaryKey varchar(251) not null primary key, theValue Integer)
URL will be
select database source and check behavior
counts up regardless of whether WAS or Browser recycles
shows error if database goes down
see what happens if you directly modify the database table using DB2 CLP
Statistics:
number of new components: 2 (HttpServlet, JSP)
source code (bytes): 7514 (6630, 884)
comparison with HitCount5 shows an additional bytes (1728, 93)

43. HttpServlet-JDBC though a JavaBean: A high level end-to-end flow
Web Server
Web Application Server
Client
Back-end
Web
Sphere plug-in
Servlet Services
Application Components
Connectors 2. 5.
HTTP Servlet Request
JAVA
HTTP Servlet
JAVA
JDBC
DB2 UDB 6.
JAVA
JAVA 1.
HTTP Session 8. 3.
CICS Java Gateway
CICS
HTTP
HTTP Session Context
Java
Server Page
Java Bean
MQ Connector
MQSeries 4.
JAVA
JAVA
JAVA
HTTP Servlet Response
...
... 7.
Web Server makes request to Web Server as before
Web Application server invokes the HttpServlet as before
HttpServlet instantiates JavaBean and invokes access methods
JavaBean accesses JDBC using connection and statement objects as appropriate
JDBC implementation invokes SQL on UDB as before
UDB sends result as before
JDBC converts reply to Java as before (except JavaBean is requestor)
JavaBean returns method result to HTTP Servlet
- ?. HttpServlet generates HTTP response as before

44. HttpServlet-JDBC through a JavaBean:
HitCount7 example
Purpose:
shows how to wrap JDBC calls with a JavaBean
replaces "gorpy" JDBC code in HttpServlet code with "cleaner" JavaBean access
JSP is basically the same (calls HitCount7 instead of HitCount6)
behavior is essentially the same as HitCount6
reuses HitCountBean3 again
How to run it:
put HitCount7.class and HitCount7Bean.class in <IBMWEBAS>/servlets directory
put HitCount7.jsp in <WebServer>/<HTML> directory
DB2 UDB should be set up as per HitCount6 instructions
URL will be
select database source and check that behavior is no different from HitCount6
use them simultaneously and see what happens
Statistics:
number of new components: 3 (HttpServlet, JSP, JavaBean)
source code (bytes): 7653 (5182, 884, 1587)
trading complexity (another bean) for reuse and a simpler, stable HttpServlet
can replace the JDBC access with that to another connector by modifying the bean
changes the behavior without changing the servlet
full Model-View-Controller separation!

45. JSP-JDBC though a JavaBean: A high level end-to-end flow
Web Server
Web Application Server
Client
Back-end
Web
Sphere plug-in
Servlet Services
Application Components
Connectors 5.
HTTP Servlet Request
JAVA
HTTP Servlet
JAVA
JDBC
DB2 UDB 6.
JAVA
JAVA 1.
HTTP Session
CICS Java Gateway
CICS
HTTP
10.
HTTP Session Context
Java
Server Page
Java Bean
MQ Connector
MQSeries 2. 3. 4.
JAVA
JAVA
JAVA
HTTP Servlet Response
...
... 9. 8. 7.
Web Server makes request to Web Server for a JSP as before
Web Application server invokes the JSP as before
JSP instantiates JavaBean and invokes access methods as part of <%= %> tag
JavaBean accesses JDBC using connection and statement objects as before
JDBC implementation invokes SQL on UDB as before
UDB sends result as before
JDBC converts reply to Java as before (except JavaBean is requestor)
JavaBean returns method result to JSP
JSP generates HTML to return to WebServer
Web Server returns HTTP reply to Client browser as before

46. JSP-JDBC using a JavaBean:
HitCount8 example
Purpose:
shows reuse of a data access JavaBean in a completely new "application"
this one does not test all the features of Standard, and just shows counting the value
also shows how a JSP can be used without ever accessing an HTTPServlet
replaces URL to HttpServlet in FORM action with that of this JSP
How to run it:
HitCount7Bean.class should be in <IBMWEBAS>/servlets directory already
DB2 UDB should be set up from HitCount6 or HitCount7
put HitCount8.jsp in <WebServer>/<HTML> directory
URL will be
Press increment button and watch count
use it from several clients and HitCount6-7 sequentially and simultaneously to see what happens
Statistics:
number of new components: 1 (JSP)
source code (bytes): 479 (only does one function)

47. Some best practices to consider: Programming model perspective
Web Application Architecture
use HttpServlets as as controller code that handles application flow logic
may want to use specialized JSP to eliminate compile step
in any event, no layout code
use Java Server Pages to handle layout logic
may use a JavaBean that directly accesses back end data
however, include no application flow logic
Servlet Services
HTTP request
using a JavaBean to pass more than one attribute value in chained requests
HTTP sessions
use to hold recomputable values rather than application data
minimize the size by storing "keys" to data stored in other sources
choose session state variable names to insure uniqueness across server
take care not to wipe out session data for other applications
best technique is to use (reuse) a single JavaBean named for the HttpServlet
Connectors
wrap calls with a Java Bean
do as much as possible in HttpServlet init method
use connection pooling techniques if not done transparently by connector

48. Some best practices to consider: Development role perspective
Application Assembler
Application Flow (Controller)
Page Producer
Page Layout and Content (View)
Web Master
Operational Environment (Application)
Bean Builder
Business Logic (Model)
Concern
Role
Components Produced
Java Server Pages, HTML, MIME types
HTTP Servlets, JavaBeans
Configuration Data, Site Usage Statistics
Java Beans
Components Used
Java Beans+ others
JavaBeans
JavaBeans
All
Programming
Skills Required
Little or None
Pure Java
Java + others
None
WYSIWYG Editors
Specialized Wizards
Java IDE
Tools
Admin
"Let the right expert do the work."

49. Some best practices to consider: A top down design perspective
Analyze business processes to be web enabled
state-transition modelling captures functional requirements
states capture information that is available
transitions capture events, conditions and actions that cause state changes
role analysis captures security requirements
information and transitions accessible by role
easiest if "granularity" is by state
Example "on-line mall" business process:
condition:
credit check (order.total cost) is OK
action:
order.status = confirmed
initiate
add/delete/change
line item
submit
Entry
Shipping
Fulfillment
final shipment
Customer
cancel
Products
Product ID
Description
Price, shipping, ...
Order (status = tentative):
Customer:
Name, address, etc
Method of Payment
Line Items:
Product ID & quantity
Completed
partial shipment
purge
Marketing

50. Some best practices to consider: A top down design perspective
Develop Web Application UI Architecture
add "usability" states/transitions to analysis model:
role & task based "home pages"
confirmation and error dialogs
may break large data entry screens into multiple pages
from the client (browser) perspective:
states are HTML "pages" (framesets, forms, tables, ...)
transitions are triggered by URL "links" (buttons, HREFs, ...)
Example Order Entry UI Architecture:
post
customer info
changes
Invalid Login
Confirm
Cancel ok
add
Order
Status
edit ok
back
invalid
back
show
product details
valid payment
Login
Customer
cancel
close
login
Product Details ok
Edit
Order
submit
invalid
payment
method
Confirm
Submit
back
back
post
product id &
quantity
next set of products

51. Some best practices to consider: A top down design perspective
Apply "design patterns" to determine server side components
variations based on the Model-View-Controller paradigm:
any "dynamic" content suggests a JSP to display the view; otherwise "pure" HTML
JSPs will likely have associated JavaBean(s) representing the underlying business model (driven out during analysis)
access should be read-only
any "dynamic" transitions (those with conditions or side effects) suggests an HttpServlet to control them; otherwise "direct" links
each dynamic transition should be represented by a single method call on some object (will facilitate evolution)
callPage() can allow inadvertent servlet execution, but never requires use of session state (can use request attributes)
sendRedirect() requires data in session state or query string
can be indicated graphically on the UI model (the "MVC baseball"):
JSP & Servlet
JSP
only
HTML & Servlet
HTML
only
direct
link
dynamic
callpage
dynamic
redirect

52. Some best practices to consider: A top down design perspective
Example Order Application High Level Design:
post
customer info
changes
Invalid Login
Confirm
Cancel ok
add
Order
Status
edit ok
invalid
back
back
show
product details
valid payment
cancel
Login Customer
Product
Details
close
login
Edit
Order ok
submit
Confirm
Submit
invalid
payment
method
back
back
post
product id &
quantity
next set of products
JSP & Servlet
JSP
only
HTML & Servlet
HTML
only
KEY:
direct
link
dynamic
callpage
dynamic
redirect

53. IBM WebSphere Standard Edition: Summary of features
Everything you need to program and serve up dynamic content to the Web
Web Server
Web Application Server
Client
Back-end
Web
Sphere plug-in
Servlet Services
Application Components
Connectors
HTTP Servlet Request
JAVA
HTTP Servlet
JAVA
JDBC
DB2 UDB
JAVA
JAVA
HTTP Session
CICS Java Gateway
CICS
HTTP
HTTP Session Context
Java
Server Page
Java Bean
MQ Connector
MQSeries
JAVA
JAVA
JAVA
HTTP Servlet Response
...
...
IBM HTTP WebServer
can be used where customer does not have a preference
WebSphere plug in
enables use of WebSphere with NetScape, IIS, Apache, ...
Servlet Services
full implementations of standard APIs required to gain access to client information
Application Components
Java runtime supports execution of HttpServlets and JSPs that use Java APIs and JavaBeans

54. IBM WebSphere Standard Edition: Advantages and disadvantages
Client
Server
Web Server
Web Application Server
Back-end
Web
Sphere plug-in
Client
Servlet Services
Application Components
Connectors
HTTP Servlet Request
JAVA
HTTP Servlet
JAVA
JDBC
???
DB2 UDB
JAVA
JAVA
HTTP Session
CICS Java Gateway
???
CICS
HTTP
HTTP Session Context
Java
Server Page
Java Bean
MQ Connector
???
MQSeries
JAVA
JAVA
JAVA
HTTP Servlet Response
...
???
...
Advantages
can exploit a "thin" (zero maintenance) client that only needs communicate using HTTP
standard set of Java components and services make programs easier to code and highly portable
more and more back end servers have Java clients available
Disadvantages
lots of different protocol stacks add unnecessary "thickness" to middle tier (client to back end)
connector's client code needs to be explicitly installed
without a standard set of connectors, ease of development and portability suffer
IBM WebSphere Advanced focuses on Client-Server with distributed objects and standard services

55. Advanced Runtime Architecture: Client-server view
Client (Java Virtual Machine)
Servers
Application Components
EJB Client APIs
Back-end
HTTP
Servlet
Java
Server
Page
Bean
DB2 Universal Data Base
MQ Series
CICS
...
IIOP
Standalone Java Application
Java
Applet
Includes the "clients" we have seen before
HttpServlets, JavaBeans, JSPs
Also includes Standalone Java Applications and Java Applets as clients, however:
not explicitly supported in IBM WebSphere Advanced
Back end services are the same as before, however:
the goal is to simplify and standardize access to them
Enterprise Java Beans is the emerging standard for distributed object services
Internet Inter ORB Protocol (IIOP) is the emerging standard on-the-wire transport protocol

56. Enterprise Java Beans What is it:
provides a standard framework within which to use distributable, transactionable, persistable, securable objects
is part of javax.ejb.* package
facilitates separation of interface on client and implementation on server
EJB developer packages various client interfaces
works together with JNDI and JTS
an EJB is actually a collection of related components packaged together into JAR file
developer creates a "deployable" jar file: <IBMWEBAS>/deployableEJBs/<Bean>.jar
at configuration time, it is "deployed" into another jar file: <IBMWEBAS>/lib/deployedEJBs/<Bean>.jar
quality of service depends on the container in which it is deployed
defers the decisions
makes coding simpler
"client" neutral
C, C++, any CORBA mappable language
Java applications, applets, Java Beans, HttpServlets, JSPs, Enterprise Java Bean implementations

57. Advanced Runtime Architecture: EJB Client API overview
Client (Java Virtual Machine)
Servers
Application Components
EJB Client APIs
Back-end
HTTP
Servlet
JNDI
Context
CICS
JAVA
IIOP
Java
Bean
JTS
User Transaction
MQ Series
JAVA
Java
Server
Page
...
JAVA
IIOP
Standalone Java Application
EJB
Key
JAVA
Java
Applet
EJB
Home
JAVA
IIOP
DB2 Universal Data Base
EJB
Remote Interface
JAVA
IIOP
Java Naming and Directory Interface
JNDI Context represents a node in the directory into which you can bind and lookup name value pairs
Java Transaction Service
JTS User Transaction represents the state of a unit of work, which can be begun, committed or rolled back by client
EJB specific classes and interfaces
EJB Home interface encapsulates methods used to create or find (for entities)
EJB Key class encapsulates data and methods associated with complex keys used to create and find entities
EJB Remote interface describes methods available to EJB client on a given instance of an entity or session bean

58. Enterprise Java Bean APIs: Java Naming and Directory Interface
What is it:
provides a standard interface to bind "global" names to values
is part of javax.naming.* package
the current implementation is based on CORBA Naming Service
provides for distributed objects, such as Enterprise Java Beans

59. Java Naming and Directory Interface (continued)
Most commonly used functions:
obtain a top level directory from which to search
use a "class" method (usually handled in HttpServlet init() method)
HashTable env = new HashTable(5); // tells class method which naming service to initialize
env.put(
"java.naming.factory.initial",
"com.ibm.jndi.CosNaming.CNInitialContextFactory" );
Context initCtx = new InitialContext(env);
find an existing name in the directory:
org.omg.CORBA.Object o = (org.omg.CORBA.Object) initCtx.lookup("name");
can get a "name not found" exception
<Type> value = <Type>Helper.narrow(o); // "safe" CORBA cast
associate a new name to a value (the name cannot exist in the directory)
for now, the name must be a CORBA object
initCtx.bind("name", value);
be prepared to handle a "Name already exists" exception
associate a name to a value (whether it exists or not)
initCtx.rebind("name", value);

60. Enterprise Java Bean APIs: Java Transaction Service
What is it:
provides a standard interface to control transactional behavior across multiple resources
is part of javax.jts.* package
the current implementation is based on the CORBA transaction service and only works with EJBs
part of the org.omg.CosTransactions.* package
also need com.ibm.ejs.client.* package
Most commonly used functions (if used at all):
to obtain a transactional control object
org.omg.CosTransactions.Current tx = EJClient.getCurrent();
can get javax.jts.UserTransaction from an EJB context (to be discussed later)
to start a transaction
tx.begin(); // same whether a UserTransaction or Cos Current
to commit a transaction (fails if not in the context of a transaction)
tx.commit(); // for a UserTransaction
tx.commit(<boolean to indicate report heuristics or not>); // for Cos Current
to register that the transaction should rollback when commit is attempted
tx.setRollbackOnly(); // with wrappered UserTransaction
tx.rollback_only(); // for Cos Current
to roll back the transaction (fails if not in the context of a transaction)
tx.rollback(); // same whether a UserTransaction or Cos Current

61. Enterprise Java Bean Client model:
Bean types
Sessions
have no persistent identity
usually created each time one is used and are relatively short lived
makes them very scalable
Entities
have a persistent identity where each is created only once
found afterwards (by key or query)
deleted only at the end of their logical lifecycle

62. Enterprise Java Beans Client model:
Components
EJB interface
provided by Bean Builder role
defines the methods that can be executed on a bean by the client program
EJB Home interface
defines methods by which associated EJBs are created, found and queried
is linked to a container in the Enterprise Java Server
EJB Key class
provided by Bean Builder role for Entity Beans with specialized keys
holds the state needed to uniquely identify an entity bean
must be serializable, have a hash value and an equals() method
EJB HomeHelper class
generated by CORBA and EJB packaging tools
used to safely cast a generic CORBA object reference to a Home interface
supports the narrow() method (can use javax.rmi.PortableRemoteObject)

63. Advanced Runtime Architecture: Client side end-to-end flow
Client (Java Virtual Machine)
Servers
Application Components
EJB Client APIs
EJB Client Impls
Back-end 1. 3. 2.
HTTP
Servlet
JNDI
Context
JNDI
Context
Stub
CICS
JAVA
IIOP 7. 6. 4. 8.
CORBA Object
JAVA
Java
Bean
JTS
User Transaction 5.
MQ Series
JAVA 9.
10.
11.
12.
Java
Server
Page
JAVA
EJB
Home
Helper
...
JAVA
IIOP 16 15 13
17.
Standalone Java Application
EJB
Home
Stub
EJB
Key
JAVA 14
18.
Java
Applet
19.
20.
21.
EJB
Home
JAVA
IIOP
DB2 Universal Data Base
24. 23 22
25.
EJB
Remote Interface
EJB
Remote
Stub
27.
26.
JAVA
IIOP
30. 29 28
Lookup home through JNDI Context (1-7)
Start transaction (8-9, optional, and not necessarily good practice)
Narrow CORBA Object to Home (10-16)
Create a Key (17-18, optional)
Create or lookup EJB through Home (19-24)
Execute methods on EJB remote interface (25-30)

64. HttpServlet using an EJB: Hands on example (HitCount)
Purpose:
shows use of an EJB
shows some techniques for holding on to the reference
How to run it:
HitCount.class should be in <IBMWEBAS>/servlets directory already (from advanced install)
DB2 UDB should be set up from HitCount6 or HitCount7
put HitCount.jsp in <WebServer>/<HTML> directory
URL will be
Press increment button after selecting EJB and various transaction options and watch count
use it from several clients and HitCount6-7 sequentially and simultaneously to see what happens
Statistics:
number of new components:
source code (bytes):

65. Advanced Runtime Architecture: Server side view
Client (Java Virtual Machine)
Servers
Application Components
EJB Client APIs
EJB Client Impls
Persistent Name Service
Enterprise Java Server
Back-end
HTTP
Servlet
JNDI
Context
JNDI
Context
Stub
CICS
JAVA
IIOP
CORBA Naming Skel-Impl
JAVA
Java
Bean
JTS
User Transaction
IIOP
MQ Series
JAVA
Java
Server
Page
EJB
Home
Helper
CORBA Object
Location Service Daemon
...
JAVA
JAVA
IIOP
IIOP
Standalone Java Application
EJB
Key
JAVA
Java
Applet
EJB
Home
EJB
Home
Stub
JAVA
IIOP
DB2 Universal Data Base
EJB
Impl
EJB
Remote Interface
EJB
Remote
Stub
JAVA
IIOP
Location Service Daemon (LSD):
registry for CORBA services
PNS and EJS are both registered
Persistent Name service (PNS)
implementation of CORBA name service
used to locate EJB Homes
Enterprise Java Server (EJS)
hosts implementations of EJB instances and homes
CORBA skeletons for Home, implementation and container

66. Advanced Runtime Architecture: Inside the EJS (n-tiers)
Client (Java Virtual Machine)
Servers
Application Components
EJB Client APIs
EJB Client Impls
Persistent Name Service
Enterprise Java Server
Back-end
HTTP
Servlet
JNDI
Context
JNDI
Context
Stub
CORBA Naming Skel-Impl
JNDI Context
JNDI Context Stub
IIOP
CICS
JAVA
IIOP
JAVA
Java
Bean
JTS
User Transaction
IIOP
MQ Series
JAVA
Java
Server
Page
EJB
Home
Helper
CORBA Object
Location Service Daemon
...
JAVA
JAVA
IIOP
IIOP
Standalone Java Application
Container Impl
JAVA
JDBC
EJB
Key
JAVA
Java
Applet
EJB
Home
EJB
Home
Stub
EJB
Home
Skel-Impl
JAVA
JAVA
IIOP
DB2 Universal Data Base
EJB
Impl
EJB
Remote Interface
EJB
Remote
Stub
EJB
Remote Skeleton
JAVA
JAVA
IIOP
JNDI Context and associated Stub
Container implementation and EJS use JNDI to bind Homes according to name in deployment descriptor
Container Implementation
maps EJB implementations to underlying persistence mechanisms (if any)
EJB Home Skeleton-Implementation
demarshals IIOP methods and delegates them to Container as appropriate
EJB Remote Skeleton
demarshals IIOP methods and delegates them to EJB implementation as appropriate
EJB Implementation
implements methods of EJB (can use other EJBs and connectors as necessary, making an n-tier model)

67. EJB Implementation model: Components developed by Bean Builder
<Bean>, <Bean>Home and <Bean>Key
see application assembler components
implemented by bean builder for use by client
<Bean>Bean
implements javax.ejb.* interfaces depending on the bean type
provides implementation of <Bean> interface methods
<Bean>FinderHelper (associated with IBM DB2 container)
aids in generating find and query methods
declares static strings associated with find methods on Home
string defines associates SQL 'where clause' used to find data
<Bean>DeploymentDescriptor
describes characteristics of the bean implementation
enables quality of service to be decided at deployment, not development

68. EJB implementation model:
Bean types
Session Beans
stateless sessions
simple stateful sessions
transactional stateful sessions
Entity Beans
self managed entities
container managed entities

69. Enterprise Java Bean implementation Stateless session beans
Considerations:
used for task oriented objects where:
all parameters required are supplied with method calls
no data need be kept between method calls
container can:
choose any available instance to execute method
create and remove instances as needed for current load
implementation notes:
implement javax.ejb.SessionBean interface
has a single ejbCreate() method with no parameters
mark as STATELESS in deployment descriptor
does not exist
newInstance()
setSessionContext(sc)
ejbCreate()
ejbRemove()
ready
<method>(...)

70. Enterprise Java Bean Implementation Simple stateful session bean
Considerations:
used for task oriented objects where:
state needs to be kept between invocations
container responsibilities:
route a method invocation to the appropriate instance
serialize non transient state variables when passivating
restore non transient state when activating
implementation notes
implement javax.ejb.SessionBean interface
activate and passivate are only needed if you cache computed values
mark as STATEFUL in deployment descriptor
does not exist
newInstance()
setSessionContext(sc)
ejbCreate(...)
ejbRemove()
ready
<method>(...)
ejbPassivate()
ejbActivate()
passive

71. Enterprise Java Bean implementation Transactionally aware session
Considerations:
used to wrapper (a few) resource oriented objects:
can participate in two phase commit process
container responsibilities
disallow methods not in proper context during a transaction
implementation notes
can mark methods as transactional in DD
also implement javax.ejb.SessionSynchronization interface:
afterBegin() - prepare for transaction start
beforeCompletion() - prepare for a commit if possible and vote commit or rollback
afterCompletion(true) - finally commit state (all resources voted to commit)
afterCompletion(false) - code to reset to pre-transaction state (rollback occurred)
does not exist
newInstance()
setSessionContext(sc)
ejbCreate(...)
ejbRemove()
non transactional
<Method>(...)
ejbPassivate()
passive
ready
ejbActivate()
beforeCompletion()
afterCompletion(true)
afterBegin()
afterCompletion(
false)
in trans
transactional
<Method>(...)

72. Enterprise Java Bean implementation Self managed entity bean
does not exist
Considerations:
used for identifiable objects that:
map to back end data sources not supported by a EJS container implementation
currently, DB2 UDB only
container simply executes the appropriate methods
implementation notes
implement javax.ejb.EntityBean interface
create handles check to see if key already exists
post create has active identity
activate and passivate are only needed if you cache computed values
mark BEAN_MANAGED in deployment descriptor
unsetEntityContext()
finalize()
newInstance()
setEntityContext(ec)
ejbFind<Method>(...)
pooled
ejbCreate(...)
ejbPostCreate(...)
ejbRemove()
ejbActivate()
ejbPassivate()
ready
ejbStore()
ejbLoad()
<Method>(...)

73. Enterprise Java Bean implementation Container managed entity bean
does not exist
Considerations:
used for identifiable objects that:
have no specific requirements for back end resources
container must
manage both the state and the identity of the entity
implementation notes
implement javax.ejb.EntityBean interface
mark CONTAINER_MANAGED in deployment descriptor
most methods are generated by container tools
may implement load, store, activate and passivate for computed values
IBM implementation of find methods is automatic given a <Bean>FinderHelper
newInstance()
setEntityContext(ec)
unsetEntityContext()
finalize()
ejbFind<Method>(...)
pooled
ejbRemove()
ejbActivate()
ejbPassivate()
ejbCreate(...)
ejbPostCreate(...)
ready
ejbStore()
ejbLoad()
<Method>(...)

74. Enterprise Java Beans: Development process (manual)
Define client side components
Remote and Home interfaces
Key class if necessary (complex keys only)
Provide server side components
choose implementation type and code appropriate methods
if using IBM Container Managed persistence, define FinderHelper class
define DeploymentDescriptor properties in config file
Package one or more beans together
compile the java classes and interfaces
generate the deployment descriptor.ser files
java -nojit com.transarc.jmon.util.MakeDescriptors -file <BEAN>.DD
create a manifest.stub to describe EJBs to be included
create a Java archive file (JAR):
jar cfvm <IBMWAS>/deployableEJBs/<Bean>.jar manifest.stub *.class *.ser
Deploy the bean(s) into one or more container(s)
create the deployed EJB JAR file:
java com.ibm.ivj.ejb.tools.deployment.EJBDeploy <Bean>.jar <IBMWAS>/temp <IBMWAS>/deployedEJBs/<Bean>.jar
add the jar to the desired container properties
in <IBMWEBAS>/properties/ejs.properties)

75. Enterprise Java Beans: Development (using admin tools)
Define client side components and implement EJB as before
Generate deployment descriptor using JET tool
make sure swingall.jar is in <IBMWAS>/samples/ejs
change to <IBMWAS>/samples/ejs
execute jet.bat
Deploy the bean(s) using the admin GUI
URL is
use EJB tabs to deploy new jars
don't forget to restart EJS to get access to new EJBs

76. Some best practices to consider: Programming model perspective
JNDI
get initial context in init method
do not use to bind non CORBA objects
JDBC
consider using Container managed entities instead (for DB2)
use connection pooling techniques where possible
JTS
consider wrapping unit of work in stateless session bean instead
Enterprise Java Bean clients
hold references in session state if possible
be aware of remote exceptions
Enterprise Java Bean implementations
wrapper task oriented code (new or existing) with sessions
wrapper existing (non DB2) data with self managed entities
wrapper resource managers with transactionally aware session beans
treat stateful session beans like HttpSessions (can go away at any time)
use large granularity methods where possible to decrease network traffic:
return JavaBeans with lots of properties, instead of one at a time
use session beans to make calls to multiple EJB (session or entity)

77. Some best practices to consider:
Development role perspective revisited
Application Assembler
Application Flow (Controller)
Page Producer
Page Layout and Content (View)
Web Master
Operational Environment (Application)
Bean Builder
Business Logic (Model)
Concern
Role
Components Produced
Java Server Pages, HTML, MIME types
HTTP Servlets, JavaBeans
Configuration Data, Site Usage Statistics
Java Beans, EJBs
Components Used
JavaBeans, EJBs
Java Beans, EJBs, + others
JavaBeans
All
Programming
Skills Required
Little or None
Pure Java
Java + others
None
WYSIWYG Editors
Specialized Wizards
Java IDE
Tools
Admin + EJB deployment
"Let the right expert do the work."

78. Some best practices to consider: A top down design perspective
Map to architecture components:
map objects with user clients to EJBs
data flowing on request and reply define method signatures
boundaries define method logic
minimize physical boundary crossings (rearchitect if necessary!)
use session objects where needed to avoid multiple functional calls
pass JavaBeans where needed to avoid multiple "CRUD" type calls
Analyze the object interactions of transitions from task analysis
indicate all instances of end users, sessions and entities
show assumptions ({}) and state changes ([])
show both request and reply data where applicable
Key:
User
Session
Entity
request(parms)
reply data
Bank Customer
ATM
Account
Transfer(1, 2, )
{lookup acct 1 and 2}
[ id = 1,
amount = ]
[ id = 2,
amount = ]
{create an ATM}
[ amount = ]
[ amount = ]
debit(100.00)
credit(100.00)

79. WebSphere Advanced scenarios: Evolution in the context of EJBs
HTTP Servlets as Controllers
exploit benefits of Java Servlets over CGI
JSPs as Views
separation of controller and view
Java Beans as a Local Model
formalize contract between client and server
may directly access back end and eliminate the need for a controller
Self Managed Entity or Stateless Session EJBs as Distributed Models
separation of controller and model
Container Managed Entity or Stateful Session EJBs
separate persistence from business logic in model
Repeat 3 & 4 as technology changes
may skip Self Managed Entities when/if container and server APIs are standardized
build your own persistent container one-time instead
would need to standardize how emitter tools are used

80. WebSphere Advanced scenarios: An architectural perspective
Client-Server (2 tier)
"thick" client programs with direct access to back end resources
Java Applications, Java Applets, Java Beans, and connectors/object services
Model-View-Controller (3 tier)
supports "thin" browser only clients handle presentation to user
"middle tier" application server controls the application flow
HTTP Servlets, JSPs, Java Beans and connectors/object services
Distributed Object (n-tier)
supports middle tier as a client to back end resources wrappered as EJBs
"n" tier because EJBs are implemented using object services/EJBs too
HTTP Servlets, JSPs, Object Services, Enterprise Java Beans (EJBs)
Client-Server (2-tier)
Model-View-Controller (3-tier)
Distributed Objects (n-tier)
JNDI, JDBC, JTS
Java
Applets
Java Beans
HTTP Servlets
Java Server Pages
EJB
EJP
Java standards introductions (cause or effect?)
IBM WebSphere support in:
Standard
Advanced
Future

81. IBM WebSphere Advanced Edition: Summary of features
Everything you need to build n-tier distributed object based applications
Client (Java Virtual Machine)
Servers
Application Components
EJB Client APIs
EJB Client Impls
Persistent Name Service
Enterprise Java Server
Back-end
HTTP
Servlet
JNDI
Context
JNDI
Context
Stub
CICS
JAVA
IIOP
CORBA Naming Skel-Impl
IIOP
JNDI Context Stub
JAVA
Java
Bean
JTS
User Transaction
IIOP
MQ Series
JAVA
Java
Server
Page
EJB
Home
Helper
CORBA Object
Location Service Daemon
...
JAVA
JAVA
IIOP
JNDI Context
IIOP
Standalone Java Application
JAVA
EJB
Key
JAVA
Java
Applet
EJB
Home
EJB
Home
Stub
EJB
Home
Skel-Impl
Container Impl
JAVA
IIOP
JAVA
DB2 Universal Data Base
JDBC
EJB
Impl
EJB
Remote Interface
EJB
Remote
Stub
EJB
Remote Skeleton
JAVA
IIOP
JAVA
Component provider key:
Application
Assembler
Bean Builder
Deployment tools
Platform
All of Websphere Standard
Set of standards based object services (JNDI, JTS, JDBC)
Enterprise Java Server (single process, simple administration and deployment tools)