IBM WebSphere Application Server. J2EE Programming Model Best Practices

IBM WebSphere Application Server J2EE Programming Model Best Practices

Requirements Matrix There are four elements of the system requirements: business process and application flow dynamic and static aspects of each Models Dynamic Static Business Process (contract) Application Flow (user role) Units of work User initiated events Persistent data Visible data

What our business does create() modify line item add line item Entry submit() cancel() assign() Fulfillment [not all items pack line item Packer Marketing ship (shipper) [all items Completed purge

What our business does (cont.) Entry static object model show business objects, associated properties and relationships units of work from dynamic model should be in terms of these +sku + open Line Item quantity +product 0..1 + customer

An example application flow dynamic model 's application flow dynamic model high level requirements captured in a STD of a customer transitions may trigger events on the underlying BPM We will examine best practices in terms of the application flow for the customer of an "on line mall"... [qty = 0] {add item } add to order Cancel cancel {cancel order} edit line item {modify item } Result (order) submit [quantity < 0] {create order} open Submit {submit order} Open

An example application flow static model application flow static model one "entry point" object per state attributes and relationships show dynamic content products items orders productid Line Item productid quantity Result message action

Web enabled distributed object based Can be considered as a "thin" n-tier architecture Browser HTTP Web Application Server Distributed IIOP Object Server??? Enterprise Logic/Data Server productid products items orders Line Item productid quantity Result message action Application flow static model [qty = 0] {add item } add to order Cancel cancel {cancel order} edit line item {modify item } Result [qty < 0] (order) submit Application flow dynamic model {create order} {submit order} open Submit Open create() modify line item add line item Entry submit() cancel() Fulfillment Shipping ship (shipper) [all items [not all items pack line item Completed Business process dynamic model Marketing purge sku Line Item quantity product 0..1 customer Business process static model open advantage 1: client need not install anything because browsers are everywhere advantage 2: business logic does not execute on web server farm, eliminating need for enterprise access advantage 3: can share and load balance both application flow and business logic disadvantage: long end-to-end pathlength

Programming model overview After determining the basic architecture, the next step is to understand the programming model and design issues for each tier: components that you develop hosted on that tier mechanisms used to flow control between components sources used to flow data between components Component Control Flow Data Source Browser HTML, XML, Framesets HTTP requests, JavaScript URL Query String, POST Data, Coies Application Server Servlets, Java Server Pages, Java Beans sendredirect(), forward(), include() Request, Session, Servlet Context Distributed Object Server Session EJB, Entity EJB, Java Beans RMI/IIOP JNDI, JDBC, others Enterprise Server BMP Entity EJB, SessionSynch EJB beforexxx(), afterxxx(), ejbxxx() JNDI, JDBC, others

Browser hosted components First, we will lo at various approaches that make use of browser hosted components, like HTML, XML, Framesets and Applets Browser HTTP Web Application Server Distributed IIOP Object Server??? Enterprise Logic/Data Server products items orders Line Item Result productid productid message action quantity Application flow static model [qty = 0] {add item } add to order Cancel cancel {cancel order} edit line item {modify item } Result [qty < 0] (order) submit Application flow dynamic model {create order} {submit order} open Submit Open create() modify line item add line item Entry submit() cancel() Fulfillment Shipping ship (shipper) [all items [not all items pack line item Completed Business process dynamic model Marketing purge sku Line Item quantity product 0..1 customer Business process static model open Component Control Flow Data Source Browser HTML, XML, Framesets HTTP requests, JavaScript URL Query String, POST Data, Coies

Composing pages in our example How would you use framesets or composed pages to map multiple related states into a single page? Navigation area (order) open [qty = 0] {add item } add to order Cancel cancel {cancel order} Result area edit line item {modify item } Result [qty < 0] submit {create order} Submit {submit order} Open

Using custom composed pages (order) open [qty = 0] {add item } add to order Cancel cancel {cancel order} edit line item {modify item } Result [qty < 0] submit {create order} Submit {submit order} Open

Browser control flow mechanisms Next, we will lo at when to apply various browser managed control flow mechanisms like HTTP requests, JavaScript and Java applet UI events Browser HTTP Web Application Server Distributed IIOP Object Server??? Enterprise Logic/Data Server products items orders Line Item Result productid productid message action quantity Application flow static model [qty = 0] {add item } add to order Cancel cancel {cancel order} edit line item {modify item } Result [qty < 0] (order) submit Application flow dynamic model {create order} {submit order} open Submit Open create() modify line item add line item Entry submit() cancel() Fulfillment Shipping ship (shipper) [all items [not all items pack line item Completed Business process dynamic model Marketing purge sku Line Item quantity product 0..1 customer Business process static model open Component Control Flow Data Source Browser HTML, XML, Framesets HTTP requests, JavaScript URL Query String, POST Data, Coies

Browser controlled data sources Finally, we will lo at when to apply various browser controlled data sources like URL query strings, POST data and Coies Browser HTTP Web Application Server Distributed IIOP Object Server??? Enterprise Logic/Data Server products items orders Line Item Result productid productid message action quantity Application flow static model [qty = 0] {add item } add to order Cancel cancel {cancel order} edit line item {modify item } Result [qty < 0] (order) submit Application flow dynamic model {create order} {submit order} open Submit Open create() modify line item add line item Entry submit() cancel() Fulfillment Shipping ship (shipper) [all items [not all items pack line item Completed Business process dynamic model Marketing purge sku Line Item quantity product 0..1 customer Business process static model open Component Control Flow Data Source Browser HTML, XML, Framesets HTTP requests, JavaScript URL Query String, POST Data, Coies

Web page design summary Rule of thumb: separate concerns and minimize the number and size of trips to the server without duplicating logic on the client Component HTML XML/XSL Frame/Windows Control Flow HTTP GET HTTP POST JavaScript Data Source URL query string POST data Coies Best use specify both format and data for a given state encapsulate state data independently of format consolidate multiple states related to same task Best use read only transitions (flow into a state) update transitions (flow out of a state with side effects) confirmations, syntactic validations, menus and lists Best Use keys and other query data to next state unlimited amounts of form data for updates data used across the session or multiple sessions

Application server hosted components First, we need a brief overview of the types of components that can be hosted on a web application server, like Servlets, Java Server Pages, and Java Beans... Browser HTTP Web Application Server Distributed IIOP Object Server??? Enterprise Logic/Data Server productid products items orders Line Item productid quantity Result message action Application flow static model (order) open {create order} Open add to order cancel submit edit line item [qty < 0] Cancel [qty = 0] {modify item Submit } {add item {cancel order} } Result {submit order} Application flow dynamic model create() modify line item add line item Entry submit() cancel() Fulfillment Shipping ship (shipper) [all items [not all items pack line item Completed Business process dynamic model Marketing purge sku Line Item quantity product 0..1 customer Business process static model open Component Control Flow Data Source Application Server Servlets, Java Server Pages, Java Beans forward(), include(), sendredirect() Request, Session, Servlet Context

Application architecture mapping Now that we understand the basic component types, the next step is to choose an application architecture that maps physical tiers: Browser HTTP Web Application Server IIOP Distributed Object Server productid products items orders Line Item productid quantity Result message action Application flow static model [qty = 0] {add item } add to order Cancel cancel {cancel order} edit line item {modify item } Result [qty < 0] (order) submit Application flow dynamic model {create order} {submit order} open Submit Open create() modify line item add line item Entry submit() cancel() Fulfillment Shipping ship (shipper) [all items [not all items pack line item Completed Business process dynamic model Marketing purge into logical components that execute in the application server tier: View Controller Model HTTP products items orders productid Line Item productid quantity Result message Application flow static model action JAVA [qty = 0] {add item } add to order Cancel cancel {cancel order} edit line item {modify item } Result [qty < 0] (order) submit Application flow dynamic model {create order} {submit order} open Submit Open JAVA create() modify line item add line item Entry submit() cancel() Fulfillment Shipping ship (shipper) [all items [not all items pack line item Completed Business process dynamic model Marketing purge IIOP

Application architecture mapping (cont.) Model components encapsulate: units of work for the business process logic to access any distributed object servers or back ends View components encapsulate: visible data for the application flow logic to render the data into the client browser language Controller components encapsulate: user initiated event handlers for the application flow logic to gather data from model components based on the request logic to drive the appropriate view components based on the result

Application server control & data flow (cont.) What are the control and data flow mechanisms we have seen so far? between what components? Source Target Control Flow Data Source Browser Web application server Web server Servlet or JSP HTTP GET, HTTP POST service(), doget(), dopost() Servlet or JSP Access bean Java method call We will lo at the following control flow mechanisms and associated data sources: URL query string, POST data, Coies HttpServletRequest, HttpServletResponse Data structure Java Bean Source Target Control Flow Data Source Servlet orjsp Servlet or JSP forward(), include(), sendredirect() Request, Session, Servlet Context

Application server supported data sources Finally, we will lo at other sources that can be used to pass data from one component to another, such as session state and servlet context Browser HTTP Web Application Server Distributed IIOP Object Server??? Enterprise Logic/Data Server productid products items orders Line Item productid quantity Result message action Application flow static model (order) open {create order} Open add to order cancel submit edit line item [qty < 0] Cancel [qty = 0] {modify item Submit } {add item {cancel order} } Result {submit order} Application flow dynamic model create() modify line item add line item Entry submit() cancel() Fulfillment Shipping ship (shipper) [all items [not all items pack line item Completed Business process dynamic model Marketing purge sku Line Item quantity product 0..1 customer Business process static model open Component Control Flow Data Source Application Server Servlets, Java Server Pages, Java Beans forward(), include(), sendredirect() Request, Session, Servlet Context

Application server data source issues There are some important issues to consider: what are the data sources and when do they best apply? where should you cache data to minimize back end accesses? We will discuss each issue separately

HttpSession Consider caching the data structure Java Bean for a state in HttpSession to eliminate extraneous back end accesses Client Web Browser {repeat} HTTP GET Servlet?... advantage 1: handles timeout {...} Web Application Server doget(req, res) req.getsession(false).getvalue("") null Servlet {get()} req.getsession(true).putvalue("", Bean) [session = <"", Bean>] "HTML for " HTTP GET... doget(req, res) {JSP} advantage 2: session req.getsession(false).getvalue("") shared across Bean contexts "HTML for " {JSP} problem: cache consistency!

HttpServlet design approaches Think about what would happen if we only created a single HttpServlet to control the entire application... advantage: only one object to code and administer (order) problem 1: only one programmer could work at a open time add to order {add item } better approach: one servlet per state with dynamic transitions cancel edit line item {modify item Cancel } {cancel order} Result submit {create order} Submit {submit order} Open problem 2: the code would be rather complex to handle all the states and transitions problem 3: can't use servlet level security, monitoring...

The "page composition" problem Think about how you would deal with the situation where framesets or named windows cannot be used on the client Result adding an item to the order redisplays catalog page want to reuse code to render "substates" of a given page Result selecting or adding an order displays details Result modifying an item, or submit/cancel redisplays order

HttpServlet inheritance Use inheritance and factor common behaviors into an extensible HttpServlet class hierarchy Client Web Browser HTTP GET Servlet? start=101 Web Application Server advantage 1: naming convention makes it easy to extend hierarchy advantage 2: subclass methods focus on gathering data, handling updates advantage 5: can develop lo and feel separately "HTML for starting at item 101" doget(req, res) advantage 3: inherited convenience methods make developing & maintaining even easier Servlet advantage 4: can declare final & abstract for enforcement dogetonlinebuying(req, res) include( "", req, res) Online Buying Servlet problem: minimizing back end accesses {check authorization: if not, forward to Login JSP} could modify include to generate XML instead {append directory of user's preferred language to name and forward} {catch errors: if any, forward to Error JSP; otherwise compose page}

Summary for HttpServlet design HTTPServlets control states and associated transitions JSPs generate the HTML view associated with state Data beans encapsulate data model needed by JSP doget() gathers data to display dopost() handles updates and flows to next state Use sendredirect after update actions to avoid reload problem Design JSPs so that they can be composed Capture common lo-and-feel in inherited HttpServlets rather than "gateway" servlets Let superclass servlet decide whether to call JSP or generate XML for return to XSLT enabled browsers

Summary for servlet design (cont.) HttpSession should only maintain easily recomputable values to avoid timeout problem Check keys & remove session to avoid cache consistency problems Use client-server affinity or persistent sessions to avoid cluster consistency problem ServletContext should only cache stable readonly data init method on HttpServlet can be used to load cache

HttpServlet design approaches Think about what happens when business logic is coded in the HttpServlet... advantage: code probably achieves the best response time problem 1: increases code complexity add to order {add item } problem 2: makes testing and debugging harder cancel edit line item {modify item Cancel } {cancel order} Result (order) submit {create order} Submit {submit order} open problem 5: reduces opportunities for reuse Open problem 4: reduces opportunities for parallel development by different roles problem 3: makes maintenance more difficult

Enterprise Java Bean design points In this section we will discuss techniques for designing Enterprise Java Beans that provide the benefits of distributed objects to any client application type Browser Web Distributed HTTP Application IIOP Object Server??? Server Enterprise Logic/Data Server productid products items orders Line Item productid quantity Result message action Application flow static model [qty = 0] {add item } add to order Cancel cancel {cancel order} edit line item {modify item } Result [qty < 0] (order) submit Application flow dynamic model {create order} {submit order} open Submit Open add line item create() Shipping Marketing ship (shipper) Entry submit() [all items Fulfillment modify line item Completed purge cancel() [not all items pack line item Business process dynamic model sku Line Item quantity product 0..1 customer Business process static model open Component Control Flow Data Source Distributed Object Server Session EJB, Entity EJB, Java Beans Java, RMI/IIOP JNDI, JDBC, JMS

Likely evolution of stateful session EJBs Initially used to cache commonly used session data minimizes calls to the back end serves as a shared cache (affinity is managed by container) Timeout and failover become issues update methods write non transient data to backing store custom creates use a parameter to load data from store some go as far as to use session synchronization (discussed later) in either case, cache and cluster consistency become issues Tends to defeat the purpose of a stateful session EJB as a simple shared cache starts sounding a lot like an entity EJB with bean managed persistence (discussed later) would be better of with an entity EJB with container managed persistence (also discussed later) As you might guess, this is a "worst practice" or "anti-pattern"

Real Best Practices Initially used to cache commonly used session data minimizes calls to the back end serves as a shared cache (affinity is managed by container) servlet clients need HTTPSession to keep handle mark all but "key data" as transient to optimize passivation Timeout and failover become issues update methods write transient data to backing store custom creates use "key data" to load transient data from store some go as far as to use session synchronization (discussed later) "key data" is still lost on node failure Tends to defeat the purpose of a stateful session EJB as a simple shared cache starts sounding a lot like an entity EJB with bean managed persistence (discussed later) would be better of with an entity EJB with container managed persistence (also discussed later)

Session Enterprise Java beans Consider a session Enterprise Java bean patterned after each business logic access bean to implement logic What are the classes and methods? create() modify line item add line item Entry submit() cancel() Fulfillment [not all items pack line item Packer Marketing ship (shipper) [all items Completed purge

Session Enterprise Java Beans Use a session EJB in a business logic access bean when required for scalability or isolation Servlet singleton() new() Entry Access [static instance = EntryAccess] EntryAccess getopen(1111) advantage 1: no business logic in web application server Data home.create() Entry (Session) Entry Entry getopen(1111) {get open order for customer 1111} Data remove() JNDI Initial Context [static instance=null] tradeoff: remote method call overhead loup("entry").narrow() [home = Entry] Entry advantage 2: can use caching to minimize home loups issue: business object access beans must deal with persistence and transactions

Entity Enterprise Java Beans Consider an entity EJB patterned after each business object access bean to implement peristence layer +sku + open Line Item quantity +product 0..1 + customer

Entity Enterprise Java Beans Use entity EJBs in business object access beans to handle persistence and transaction logic transparently Entry (Session) singleton() new() Access (Entity) new().loup("").narrow() JNDI Initial Context [home = ] advantage: persistence logic Access provided by EJB container get(1000) home.findbyprimarykey(1000) {find Entity EJB and load CMP fields} {new Data} getp i () v i problem: multiple {repeat} {set v i remotable gets and sets into Data} Data tradeoff: remotable method call overhead (usually co-deployed)

Best Practices for WAS V5.0 Local (versus remote) interfaces Traditional Remote (RMI) Local Interfaces Interface extends EJBObject Interface extends EJBLocalObject extends EJB extends EJBLocal Remote method calls More efficient local calls Location Independent Parms passed by value Client and EJB need to reside in the same JVM Parms passed by reference Remote exceptions thrown on methods Regular Java Exceptions Use narrow() to cast Use regular Java class cast

Dependent value classes public abstract Bean implements EntityBean {... // container-managed persistent fields... public abstract AddressData getshippingaddress(); public abstract void setshippingaddress(addressdata data); public abstract AddressData getbillingaddress(); public abstract void setbillingaddress(addressdata data); // method worth promoting to interface public Data getdata() { Data data = new Data();... data.shippingaddress = getshippingaddress(); data.billingaddress = getbillingaddress();... return data; } } <cmp-version>2.x</cmp-version> <abstract-schema-name> Bean </abstract-schema-name> <cmp-field id="cmpattribute_1"> <field-name>id</field-name> </cmp-field> <cmp-field id="cmpattribute_2"> <field-name>name</field-name> </cmp-field> <cmp-field id="cmpattribute_3"> <field-name> shippingaddress </field-name> </cmp-field> <cmp-field id="cmpattribute_4"> <field-name> billingaddress </field-name> </cmp-field> no need to flatten fields from dependent value classes in CMP fields best not to promote get/set fields, though even less crucial if local

EJB Query language (EJBQL) Design issue: how do you implement custom finders? single and multiple cardinality with and without CMR independent of relational persistence mechanism @sku @id name shipping billing open Address line1, line2, city, state zip, country Line Item quantity @product 0..1 @id customer shipper Shipper @id company

EJB Query language (EJBQL) After: custom finders specified in the deployment descriptor independent of persistence mechanism (theoretically) can follow relationships, avoiding complex joins in finders Local definition: public interface extends EJBLocal { public create( Data data ) throws CreateException; } public findbyprimarykey( Key key ) throws FinderException; public Collection findsinstate( String ) throws FinderException; Deployment descriptor fragment: <entity id="containermanagedentity_3"> <ejb-name></ejb-name>... <query> <query-method> <method-name>findsinstate</method.. <method-intf>local</method-intf> <method-params> <method-param>string</method-param> </method-params> </query-method> <ejb-ql>select object(o) from o WHERE o.=?1 </ejb-ql> </query> </entity>

Message Driven Beans (MDB) Design issue: how do you enable asynchronous processing? loose coupling, but with reliable delivery and 2PC usually associated with major transitions in the business process create() modify line item add line item Entry submit() cancel() [no items] assign() Fulfillment pack line item Shipping Marketing ship (shipper) [all items Completed purge [items to ship]

Message Driven Beans (MDB) develop/generate a message driven bean (MDB) for major transitions get container managed messaging (CMM) qualities of service clients send messages through JMS to trigger MDB Typical Message Driven Bean class: public class SubmitMsgHandler implements MessageDrivenBean { private transient MessageDrivenContext context = null; public void ejbcreate() {} public void ejbremove() {} public void setmessagedrivencontext(messagedrivencontext mdc) { context = mdc; } // Message acknowledge and database update participate public void onmessage(message inmessage) { SubmitMsg msg = (SubmitMsg) inmessage; try { // The access bean passes thru to the session EJB to handle unit of work FulfillmentAccess.singleton().submit(msg.order); } catch(hasnoitemsexception e) { // The access bean passes thru to the session EJB which sends another message FulfillmentAccess.singleton().alert(e); } }

Message Driven Beans (MDB) may want to use local interface to session as "alternate" access path however, co-deployment and no local calls perform nearly as well Session Client Access 1. Jav a 12. 2. Java 11. Session Remote Interface 3. 4. 17.31. 5. 18. 32. IIOP 10. Session Bean Impl 16. 23. 30. 37. Jav a Java 9. 22. 36. Entity Client Access Java 8. 21. 35. Entity Local Interface 7. 20. 34. Jav a 6. 19. 33. J2EE Client App Session Local Interface Entity Bean Impl 15. 29. Jav a 24. 38. Web Services Client 13. HTTP 26. Web Services Servlet 14. Java 25. Session Alternate Access 28. Java Message Driven Bean 27. JMS 39. 40. Asynch Services Client

Summary for EJB design Consider session EJBs in business logic access bean to get benefits of distribution Use stateless session EJB s wherever possible to maximize scalability characteristics of application Only use stateful session EJBs when timeout and failover of cache are not issues, otherwise choose entity EJBs Consider entity EJBs in business object access beans to separate business logic from persistence logic Use custom creates, finds, gets, sets and updates in entities to minimize number of remotable calls Treat all entity EJBs as CMPs when programming for functional requirements