J2EE 1.4 new features

Abstract: J2EE 1.4 new features

<table CellSpacing=0 cellPadding=0 width="100%" border=0> <tr> <td bgColor=#d9d9d9 colSpan=11> <table cellSpacing=0 cellPadding=3 width="100%" border=0> < tr> <td class=darkgreylarge> Title: J2EE 1.4 new features: an overview </ td> <td> views: 1027 </ td> <td align=right> time :2004-04-29 </ td> < / tr> </ table> </ td> </ tr> <tr> <td bgColor=#d9d9d9 colSpan=11> </ td> </ tr> <tr> <td bgColor=#d9d9d9 colSpan=11> < table cellSpacing cellPadding = 3 = 0 width = "100%" border = 0> <tr> <td> Author: Dave Landers </ td> </ tr> </ table> </ td> </ tr> <tr> <td bgColor=#d9d9d9 colSpan=11> </ td> </ tr> </ table> <table cellSpacing=0 cellPadding=0 width="100%" align=center bgColor=#cccccc border=0> <tr> <td> <table cellSpacing=1 cellPadding=4 width="100%" bgColor=#cccccc border=0> <tr bgColor=white> <td vAlign=top width="99%">

J2EE developers necessary skills list is quite lengthy. In this article, we will not discuss J2EE technology, but also will not discuss new technologies. We will have to explore some of its major new features, and then you will know in J2EE What features used in the project.
J2EE 1.4 brings a number of new and interesting features. They always focus on three main themes: Web services, messaging and the Web more easily developed. To meet the needs of these themes, composed of all the major J2EE standards have been upgraded - most norms are very important. The most important (and most) upgrade is JCA 1.5 norms and JSP 2.0 specification, as well as J2EE spec itself. In addition, some of the norms of the new (or is the new J2EE) - For example: JAX-RPC, Web services and J2EE deployment and management practices.

J2EE 1.4 in the new specification includes a number of new standards and technologies. Generally speaking, the most important J2EE in the expansion of content, most of the support for the Web services or XML. One of the most important number is:

Web services for J2EE (JSR-109)
This new standard describes how the Web service as a servlet or stateless EJB Session Bean to deploy. The most striking change is to increase the deployment of the new descriptors, such descriptors as a component will support the deployment of Web services.

JAX-RPC 1.1
JAX-RPC is for the use of remote procedure call SOAP the Java API. The use of these API, we can use remote object called Web services. J2EE in the use of JAX-RPC Remote EJB methods and calls are very similar.

JAX-RPC standard also defines a Web services (through its WSDL) mapped to the Java interface approach. JAX-RPC include the realization of a number of tools for generating from WSDL interfaces, stubs and so on, or generated from the WSDL interface.

J2EE Web services in the server and client use the JAX-RPC. Realized in the J2EE Web services (as a servlet or EJB) will be used JAX-RPC interface. If a component of long-distance calls to Web services, it will be used as JAX-RPC remote interface.

SAAJ 1.2
SAAJ is SOAP with attachments API for Java (for the Java API for SOAP with attachments), which allow those who transfer in the SOAP call in the annex can be visited Java.

JAXR
JAXR for XML registry is a Java API, API used to access the Web services registry, such as UDDI, and OASIS ebXML. Unfortunately, support for the J2EE does not require a particular registry, but can be used to achieve the API and the API.

XML support J2EE 1.4 specification requirements now support SAX 2, DOM level 2, and the structure of XML namespace, also requested support for XSLT. If you are prepared by the manipulation of XML J2EE applications, you must now support the latest version to work.

Management and deployment of J2EE API (JSR-77 and JSR-88)

Both API and IDE tools were provided by the concern. They provide a vendor independent API, J2EE application server used to control the management and deployment activities. This makes IDE (or our own development tools) can be very easily with a variety of application server interaction, without the need to use certain vendors in the large number of API.

Changes in norms

J2EE contains all norms in the J2EE 1.4 in varying degrees, there are some changes. However, some changes are minor, but J2EE "four major pieces" (EJB, JCA, servlets and JSP) increases the important new features.

Below on one of the most important changes introduced:

Enterprise Java Beans 2.1
EJB 2.1 norms improvements mainly in Web services and messaging. This will give details below. However EJB 2.1 has also increased the timer service and enhanced management of the entity bean containers of EJB QL-query language.

The new services allow any EJB timer (with the exception of a state of the session bean) to register in order to obtain containers from the time-based callback function. EJB can request a specific time (eg 10 seconds), a single callback signal, or you can arrange for regular (eg every 10 minutes) callback. This feature in some cases would be helpful, but it also has been greatly misused the potential - this allows time to tell us the answer.

EJB QL-on the enhancement of the operator ORDER BY, SUM, COUNT, AVG, MAX, MIN and MOD. Most of the application server in their specific to the expansion of the provider will provide these operators. And now they were eventually written into the standards.

Enterprise Java Beans 2.1 - Web services endpoint of Web services, EJB have already joined the session bean-free status as a Web service to use the capacity. This capability can be used to achieve the new Web services or through the Web service interface to some published EJB out.

To a non-existing state of the session bean into a Web service endpoint is relatively easy. WSDL generated from a remote interface (using JAX-RPC tools), and then in the ejb-jar.xml document into a service-endpoint elements. This element of service-endpoint or with both appear to have access to your EJB like another interface - so your EJB now have all or part of the long distance, local and Web services endpoint interface. Then, add a webservices.xml deployment descriptors, contained in document service-impl-bean and ejb-link the two elements. This put WSDL connected to the EJB, and notify the application server through the Web containers announced it out.

Similarly, can the existing Web services as a non-state session bean to achieve unless you use JAX-RPC tools to generate from WSDL interface.

Enterprise Java Beans 2.1 - Web Service Client
EJB 2.1 standard now explicitly allow any one EJB can be a Web service client (through JAX-RPC interface). Calling Web services and call another EJB manner very similar. Deployment descriptors used in the service-ref elements, Web services will be mapping, so you can use the "java: comp / env /" in the name of JNNI enquiries in the service.

Incidentally show that this technology not only in EJB can be used, and can be used in any J2EE components - So, you can also servlets or JCA adapters to call Web services.

Enterprise Java Beans 2.1 - messaging
EJB on the improvement of messaging and Java Connector Architecture closely linked. EJB 2.1 norms improved message-driven bean (MDB: message-driven bean), which allows the arbitrary (JMS) news types. Similarly, a message connectivity tools have been added to the deployment descriptors in the information sent to the designated component of the MBD or JMS destinations (and ejb-EJB ref allow you to "hook" with a very similar way) .

J2EE Connector Architecture 1.5
JCA 1.5 norms has been greatly changed. JCA 1.5 of the new changes is the source of all station adapter, which allows an external services (such as an EIS system) application server to send information. So JCA now become a two-way street. It is accompanied by a message Connector, a tool that all of the tools to deal with this station adapter and linking information MDB. Here is the main use cases and news-driven bean (MDB) linked into the station adapter to receive information, process information, generating information, and then queue up for a news MDB for processing. This feature is the key to the changes in the use of non-MDB JMS news types.
JCA other aspects of the improvements include the management of all to achieve different threads into the station adapter for the work management system improvements. JCA work management allows the use of threads, but not its threads application management conflict.

Servlet 2.4
Servlet 2.4 specification changes in the Web services mainly in the category as JAX-RPC servlet deployment to achieve the ability of Web services endpoint. This Web service providers to achieve an easy way.

Based on the preparation of a servlet Web services endpoint and the creation of an endpoint based on EJB almost identical. Use JAX-RPC interface creation tools from WSDL (or from the interface to create WSDL), then an ordinary JAVA achieve this type of interface. Then servlet elements (but not the use of servlet-mapping) in the web.xml statement in the class, to create a service contains impl-bean-and servlet-link elements webservices.xml file descriptors.

Servlet 2.4 also increased listener to obtain property (which has been available as the existing session attribute sniffers).

SingleThreadModel also did not agree to use. If you used this interface, you must have been aware that in fact it does not really solve the problem with Serverlet real-time. SingleThreadModel Serverlet process can only protect the single-domain and methods, but there is no doubt that it did not have the ability to protect other resources (such as those used in the static methods, or in the HttpSession object). Therefore, we do not agree to the use of SingleThreadModel, will be a good, thread-safe, by the practice of alternative programming.

Java Server Pages 2.0
JSP norms finally ripe. In JSP 2.0, and finally to write a script pages (without any "<%â€¦%>" category of Java code).

The first is to increase the expression of improving language (expression language, EL), the expression of language from the JSP standard tags (JavaServer Pages Standard Tag Library, JSTL). EL is a simple, easy-to-use and sophisticated grammar, syntax no longer need this most of the "scriptlet." EL is based on the ECMAScript (JavaScript) and XPath, therefore, its syntax for the majority of Web developers, who will be feeling deja vu.

JSP 2.0 in the same library markings improved. Now, we have a simple API to write a marker. SimpleTag simple interface with a more simple life cycle - there is only one method and not doTag examples of the buffer pool and reuse. JSPFragment SimpleTag and its partner (used to assess body markings) can be completed Now the majority of the "classic tags" have done, but compared to the past, what will happen in more effort. In addition, these simple API means that more can be more easily labeled correctly, which means that fewer bug.

Another improvement is to mark the preparation of the document marked capacity. Such markings as a JSP document rather than to achieve the Java class. Marker is simple document preparation, and the deployment of more simple - you simply turn those documents in a similar foo.tag Add to the names of the WEB-INF/tags everything will be just fine. TLD descriptors do not need to prepare documents, because all the important information in the document marked its own in a statement.

Document marked the biggest advantage is in need of some visual HTML element when the marker. For example, the continuing format bean output. Previously, must be embedded in HTML or Java code contains pages approach. But marking of this type of document is the most natural function of usage. This also to the non-Java developers who opened the door to self-create markers. JSP 2.0 has also improved support for XML syntax, joined the JSR-45 support, as well as other languages debugging support.

JSTL
JSP standard marker library (JavaServer Pages Standard Tag Library, JSTL) is a very useful marker set. JSP2.0 these markers and in other areas to improve the integration of up very well. Unfortunately, JSTL JSP 2.0 specification is not necessary component. However, because it is such a useful, and with a wide range of support (for example, from Sun to Apache), we deserve to be mentioned here.

Summed up in the new version is full of new content, the question is how to use them?

Web Development
JSP regulate all of these changes have greatly improved the Web development experience. We finally have the possibility of preparing embedded Java code is not the JSP page. Moreover, a simple marker and marking the optional document marked become easier to prepare and easier to use. In the user interface (view) and back-end (controller), the separation between the better.

Messaging and messaging in the MDB JCA improvements in a lot of significance. First, it is evident that - EIS application server and the two-way communication between J2EE and would enhance the integration of existing enterprises.

But other benefits also far more than these. First of all, apart from those containers (RMI, HTTP and IIOP) owned by the socket, the adapter into the station a "right" to create and monitor socket. So, for instance, you can add a JCA adapter so you can telnet to the application server to perform some administrative tasks. Alternatively, FTP servers can be deployed as a standard component of the J2EE JCA, the mail server can be achieved. This possibility is endless.

Another possibility (which has been clearly stated in the standard) is a JMS provider. J2EE specifications must be achieved JMS application servers - but does not specify a particular messaging system of any demands. Therefore, every news providers usually to achieve their own information systems to support JMS. Moreover, they are usually there must be external systems can work together with them to communicate.

With J2EE 1.4, information providers now have made possible the creation of their support for JMS, J2EE, as a line with the standards of the JCA adapter can transplant the same. Adapter entry information can be dealt with end users, points out one end processing publisher. Then, the JCA can be deployed to any J2EE 1.4 application server. This will have to improve its application server interoperability between the potential, at least for the JMS message is this.

With Web services J2EE 1.4 specification, J2EE and Web services has been strong in the combination together. This has a variety of choices.

First, if you have existing systems based on EJB, just a simple deployment descriptors add JAC interface, as well as some entries, any non-state session bean can be published as Web services. This opened the existing deployment of Web services and interoperability.

The new Web service, you can prepare the same as above EJB the realization of the preparation can be a simple Java class (using JAX-RPC). Regardless of what way, you can pass some deployment descriptor entries deployment.

In addition, you can also use the J2EE application of any Web service, is in the implementation of any other long-distance calls, the use of JAX-RPC calls to Web services.

Concluding remarks on the J2EE 1.4 enhancements are unquestionable, and should enhance the usefulness of the J2EE platform and capabilities. JCA and the improvement in the MDB to enhance their back-end. To increase the support of Web services to improve the usefulness of the J2EE and interoperability. For those who wish to develop Web-based user interface of staff, the improvement is JSP lower the threshold for their use. In short, this is a great combination.

Now, the most difficult task for the things you - J2EE development - before, you need to determine how your project in the past in all these good things to choose choice. This will be a fun thing.

</ Td> </ tr> </ table> </ td> </ tr> </ table>

â†‘ Back

Tutorial for building J2EE Applications using JBOSS and ECLIPSE-6

Abstract: Tutorial for building J2EE Applications using JBOSS and ECLIPSE-6

Chapter 6.

Creating a CMP Entity Bean

This chapter covers how to create a Container Managed Persistence (CMP) EJB component. We will create two CMP beans, Item and Supplier as shown below. The Item bean will be responsible for storing the details of items, such as their availabability and their prices , for MyStore. The Supplier Bean stores details of Suppliers to MyStore. Both beans interact with corresponding tables in the database. In CMP this interaction is controlled by the container, in this case the JBOSS CMP container.

All Items have been assigned a unique itemId for housekeeping purposes within MyStore, and all suppliers have been assigned a unique supplierID in addition to their username which is what they use in accessing the services of MyStore.

Note: It is normal practice to access the business methods of CMP beans via a Session bean, that encapsulates the business logic and acts as an interface to the lower-level EJB components. In this case Supplier and Items are accessed via StoreAccess.

Tasks:

Create a CMP bean named Items under package au.com.tusc.cmp.
Implement the ejbCreate method, with the values of all attributes being passed as arguments and then assigned to the attributes using mutator (setter) methods.
Add a finder method named findBySupplierID with the following query and signature:

Query "SELECT OBJECT (b) FROM MyStoreItem as b where b.supplierID =? 1"

Method "java.util.Collection findBySupplierID (java.lang.String supplierID)"
Add a finder method named findByOutOfStock with the following query and signature:

Query "SELECT OBJECT (c) FROM MyStoreItem as c where c.quantity = 0"

Method "java.util.Collection findByOutOfStock ()"
Add a business method to get item details with the signature:

Public ItemData getItemData ()
Add another business method to register delivery of items with the signature:

Public void fillStock (java.lang.Integer quantity)
Add callback methods, required for getting / setting bean context for bean with signatures:

Public void setEntityContext (EntityContext ctx)

Public void unsetEntityContext ()
Deploy the Item Bean.
Add a field to the StoreAccess bean to store the Item reference (obtained from JNDI lookup):

Private ItemLocalHome itemLocalHome
In the ejbCreate method of the StoreAccess bean store this reference in the itemLocalHome variable by invoking the getLocalHome static method in ItemUtil.
Add a business method to StoreAccess Bean with the signature:

Public ItemData getItemData (String itemID)
Add another business method to StoreAccess Bean with the signature:

Public java.util.ArrayList getOutOfStockItems ()
Add another business method to StoreAccess Bean with the signature:

Public java.util.ArrayList getItemBySupplier (String supplierID)
Create a test client named SessionCMPClient under package au.com.tusc.client.
Run your client and test the bean.

Create Items CMP Entity Bean:

Go To Package Explorer> Expand Mystore (project) node> select src, right click and a menu will pop up.

On the pop up menu> New> Lomboz EJB Creation Wizard.

Enter the package name au.com.tusc.cmp, the bean name Item and select the bean type as Container Manged Entity as shown below.

Go to Next and a new screen will pop up as shown below.

Enter MyStoreItem as the Schema Name.

Enter Item as the Table name.

Under Persistent Fields first enter itemID as the Field, with a Field Type of java.lang.String, ITEMID as its Database column, and VARCHAR for its SQL Type.

Press Add ..> It will add this field in Fields section, select this new field> Press Make Primary Key.

Similarly, add all the rest of the fields of the items table as shown below.

Add .. Field: supplierID, Field Type: java.lang.String, Database Column: SUPPLIERID, SQL Type: VARCHAR.

Add .. Field: description, Field Type: java.lang.String, Database Column: DESCRIPTION, SQL Type: VARCHAR.

Add .. Field: quantity, Field Type: java.lang.Integer, Database Column: QUANTITY, SQL Type: INTEGER.

Add .. Field: price, Field Type: java.lang.Float, Database Column: PRICE, SQL Type: DECIMAL.

After adding all these fields, press Finish.

This will create a package named au.com.tusc.cmp under src, and ItemBean will be be created within that package as shown below.

Note: In comparison with our earlier BMP Entity Beans (Customer & Manager), the more tags have been generated at class level. Note also that CMP doesn't require a Data Access Object (DAO) interface, as communication between database and bean is controlled by the container.

Let's first the generate EJB classes and then we will examine these tags.

Go to node ItemBean under au.com.tusc.cmp> LombozJ2EE> Add EJB to Module> Select MyStoreMgr> Ok.

Go to MyStoreMgr node> LombozJ2EE> Generate EJB classes.

Note: All these steps are covered in previous chapters (chapters 3 and 1) in detail, so please refer to these if you have any queries.

Now, let's see what files have been generated by Xdoclet.

As shown below, the files generated are nearly the same as for BMP, except there are no Primary Key or DAO classes, and there is now ItemCMP which extends the ItemBean class. The remainder are the same as for BMP entity beans.

Now, let's examine these new tags, some of which have been covered in previous chapters.

@ Ejb.bean tag provides information about the EJB. It is the one compulsory tag for all EJBs.
@ Ejb.persistence tag is being used at two levels, at class level and method level. At class level it provides information about the persistence of a CMP entity bean, that is which database table this bean is going to interact with, which will provide that persistence. At method level it provides information about the mapping of the bean's persistent attributes to columns in that database table.
@ Ejb.finder tag defines a finder method for the home interface. This requires the EJB QL query to fetch the data and a signature for the method. This tag can be used for multiple finder methods.
@ Ejb.persistence-field method level tag is being deprecated in favour of@ejb.persistence tag, it provided information about persistent fields.
@ Ejb.pk-field tag defines the primary key.

The code snippet below shows how persistent attributes are declared in a CMP Entity Bean.

Note: All persistent attributes are declared with abstract accessor and mutator methods in ItemBean. Note also that in the case of a composite primary key you have to specify the@ejb.pk-field tag on all other attributes / properties which combine to form the overall key as well.

Implement ejbCreate Method:

The ejbCreate method is created by method is created by the Lomboz Bean wizard, but we still have to add some code to complete it. Modify the signature of ejbCreate, passing all the attributes as parameters and then setting all these attributes using their associated mutator methods , as shown below.

Errata note: - There is an error in the figure shown below. The Integer attribute 'qunatity' should be called the 'quantity'.

Note: The other interesting aspect of ejbCreate here is its return type, as its return type has to be same as the primary key type (eg it has to of type String, Integer, Float, or whatever). In this case it is String — the type of itemID, and when implemented it should return null. (Refer to the EJB Spec 10.5.1).

Add Finder Method:

Note: An entity bean's home interface defines one or more finder methods, to find an entity object or collection of entity objects. The name of each finder method starts with the prefix 'find', such as findPrice or findQuantity in our case. Every finder method except findByPrimaryKey (key) must be associated with a query element in the deployment descriptor. The entity bean provider declares the EJB QL finder query and associates it with the finder method in the deployment descriptor. A finder method is normally characterized by an EJB QL query string specified via the query element. Refer to the EJB Spec 10.5.6. This is covered in the Exercise section of this chapter.

Now let's add a finder method to our bean class to find items supplied by a particular supplier.

In order to add this finder method we have to declare a class level tag as discussed above, that is@ejb.finder.

So, add this tag:

@ Ejb.finder query = "SELECT OBJECT (a) FROM MyStoreItem a where a.supplierID =? A" signature = "java.util.Collection findBySupplierID (java.lang.String supplierID)"

Note: In EJB QL, instead of the name of the table, the schema name is used (in this case it is MyStoreItem, rather then specifying Item as you would for an SQL query). Similarly the column names that would be used in SQL are replaced by their corresponding attributes as declared in the bean.

Generate your EJB classes to see what this tag and the previous finder tag have created in the Home Interface as shown below in this code snippet from the ItemLocalHome interface.

It has four methods, including the two finder methods generated by the finder tags declared at class level. The other two, create and findByPrimaryKey are created by Xdoclet (because of the Tag in ejbGenerate.xml).

Add another finder method to find out-of-stock items in MyStore.

Add the following tag.

@ Ejb.finder query = "SELECT OBJECT (c) FROM MyStoreItem c where c.quantity = 0" signature = "java.util.Collection findByOutOfStock ()"

Code snippet from ItemLocalHome after generating EJB classes for these finder methods.

Now, generate your EJB classes and analyze the relevant classes. All the finder methods are complete. Let's add some business methods now.

Add Business Methods:

Now, add a business method with this signature:

Public ItemData getItemData ()

.. With Interface type as local.

Note: The steps to add a business method are covered in previous chapters (1 and 3), so please refer to them. Also we have chosen the Interface type as local because these methods will be invoked within the same Java Virtual Machine.

This will provide description of individual items in MyStore. Add some debug statements and return an instance of ItemData as shown below in this code snippet from the Item bean.

Add another business method with the following signature:

Public void fillStock (Integer quantity)

.. With Interface type as local. This will increment the items available to MyStore after the delivery of further items. Add some debug statements and following lines to complete the method.

Integer qty = new Integer ((quantity.intValue () + getQuantity (). IntValue ())); setQuantity (qty);

Code snippet of fillStock in ItemBean shown below.

Add Callback Method

Unlike BMP (where they were generated) we have to add callback methods which will be overridden in the ItemCMP class.

First import the following package: javax.ejb.EntityContext

Add a field to store the entity context.

Protected EntityContext eContext;

Add a method setEntityContext with entityContext as its parameter and assign that to your entityContext variable.

Similarly add a method unsetEntityContext, which sets the entityContext variable to null.

Code snippet for both methods is shown below.

Now all business and finder methods are complete, so it's time to generate EJB classes.

Let's examine the generated ItemCMP class, which is of most interest.

Unlike our BMP bean all persistent attribute behavior is being overridden by abstract methods. This is because the EJB container is responsible for maintaining their persistence.

All the callback methods we have implemented are being overridden as shown below.

Note: There are no ejbFinder methods in this class as with BMP beans, as all this is controlled by the container. Also as pointed out before, there is no PrimaryKey class generated and there is no need for a DAO class, as this too is controlled by the container.

Now, before we deploy our bean, we will just have a look at ejb-jar.xml and jboss.xml to see what descriptors are generated.

Note: We don't have to write any descriptors for the data sources as we did with Session and BMP beans, as the EJB container is responsible for that.

As shown in the code snippet above from the ejb-jar.xml file, all abstract methods are generated as persistent fields under the tag Because of the tag @ persistence-field declared at each accessor method. Also the primary key class descriptor is generated under the

Tag and the primary key field is generated under the

Because of the tag-field @ pk declared for the relevant attribute (s).

Descriptors for finder methods are generated along with the query defined to fetch the data as shown below. These finder tags are generated by the@ejb.finder tag declared at class level.

And in the jboss.xml file, the following descriptors are generated due to the tag@ejb.bean declared at class level, as shown below.

Note: @ ejb.bean tag has been covered in previous chapters.

Item Bean functionality is complete in and ready for deployment.

Deploy Item Bean:

Go to Lomboz J2EE View> expand node MyStore> expand MyStoreMgr> select Jboss 3.2.1 ALL.

Right click> select Debug Sever on the pop up menu.

Note: This is to start your server, if you are already running your server then skip these steps and go to the next one.

Go to MyStoreMgr node in LombozJ2EE view> right click> select Deploy on the pop up menu as shown below.

Note: All these steps have been detailed in previous chapters (1 and 3), so, please refer to them.

Messages in the console will indicate whether deployment of your bean has been successful or not.

Now, lets modify StoreAccessBean to invoke methods on ItemBean.

Add a field to store our Item reference (obtained from JNDI lookup).

Private ItemLocalHome itemLocalHome;

In the ejbCreate method store this reference in the itemLocalHome variable by invoking the getLocalHome static method in the ItemUtil class as shown in this code snippet below from StoreAccess Bean.

Add a Business Method to StoreAccess:

Add another business method to the StoreAccess Bean which will invoke this business method on our Item Bean.

Now, add a business method with this signature:

Public ItemData getItemData (String itemID)

.. With Interface type as Remote. As managers will log on to MyStore with username, once authenticated they will be identified by their userid. They can then retrieve their account details from MyStore using that userid. A Manager can invoke methods on the Item Bean to examine the inventory of MyStore.

Note: Steps to create business methods are covered in previous chapters.

Now invoke one of Item's finder methods via the reference variable we have created in the ejbCreate method.

ItemLocal item = itemLocalHome.findByPrimaryKey (itemID)

Now invoke the business method of Customer on this reference.

ItemData myItem item.getItemData = ()

Code snippet for this business method is shown below.

Add another business method to StoreAccess Bean.

Add a business method with this signature:

Public java.util.ArrayList getOutOfStockItems ()

.. With Interface type as Remote. This will return the items which are out of stock in MyStore.

Create two variables of type Collection and ArrayList respectively, as the finder method for Items returns a Collection and this method will return an ArrayList, after populating items which are out of stock from the returned Collection.

Collection items = null; ArrayListItemsOutOfStock = null;

Now invoke one of the finder methods of Item on the reference variable we have created in the ejbCreate method.

ItemLocalHome.findByOutOfStock items = ()

Now iterate through the collection of out of stock items and add to the ArrayList.

ItemLocal ItemLocal myItemLocal = (ItemLocal) iterate.next (); itemsOutOfStock.add (myItemLocal.getItemData ());

Code snippet for this business method is shown below.

Add another business method to StoreAccess Bean.

Add a business method with this signature:

Public java.util.ArrayList getItemBySupplier (String supplierID)

.. With Interface type as Remote. This will return the items which are provided to MyStore by a given supplier.

Create two variables of type Collection and ArrayList respectively as the finder method for Items returns a Collection and this method will return ArrayList, after populating items which are supplied by a particular supplier from the returned Collection.

Collection suppliedItems = null; ArrayList itemsBySupplier = null;

Now invoke one of the finder methods of Item on the reference variable we have created in the ejbCreate method.

SuppliedItems = itemLocalHome.findBySupplierID (supplierID)

Now iterate through the collection of items for this supplier and add to the ArrayList.

ItemLocal ItemLocal myItemsLocal = (ItemLocal) iterate.next (); itemsBySupplier.add (myItemsLocal.getItemData ()); Code snippet for this business method is shown below.

Now all the methods in StoreAccess Bean for accessing Item's business methods have been added. The only remaining bit is the deployment descriptors required for linking / referencing of StoreAccess and Item Bean. So we will the add two tags shown below.

First add the tag shown below at class level in StoreAccess Bean.

@ Ejb.ejb-ref ejb-name = "Item" view-type = "local" ref-name = "ItemLocal"

This tag will generate deployment descriptors in 'ejb-jar.xml', as StoreAccessBean has to know which bean it is referring to, what is its view-type and ref-name. This will generate these descriptors as shown below.

Note: View type is local as both are in the same Java Virtual Machine, otherwise it would be Remote. Secondly ref-name is generated as ItemLocalHome, as we are using that rather than ItemHome (which was also generated, but is used in the Remote case).

Now add a second tag (shown below) at class level in StoreAccess Bean.

@ Jboss.ejb-jndi ref-ref-name = "ItemLocal" jndi-name = "ItemLocal"

This tag will generate deployment descriptors in 'jboss.xml', as the application server has to know what jndi-name the Item bean has been registered with. This will generate these descriptors as shown below.

Note: Ref-name and jndi-name are used for bean as local (in same JVM).

Note: We can see in the code snippet above the deployment descriptors generated by tag @ jboss. For the view type 'local' it generates incorrect deployment descriptors, as discussed in the previous chapter. So every time we use this tag we have to change the To Before deployment. Caution here, and that you do this change manually when you finally finish regenerating your EJB classes, because every time you regenerate your classes, 'jboss.xml' will be overwritten.

Now our Item Bean is complete after these changes, so deploy your bean again now, from the Lomboz J2EE View, as per the steps shown above and in previous chapters. Messages will appear in the console showing the status of deployment.

Once the bean is deployed successfully, create a test client which will invoke the loginUser method on StoreAccess Bean, getCustomerData on Customer Bean, getManagerData on Manager Bean and getOutOfStockItems on Item Beam.

Create your Test Client:

Go Go to Project MytStore node> select src node and expand it> select au.com.tusc.client package> right click.

Select New on the pop up menu> select Lomboz EJB Test Client Wizard.

Select package name au.com.tusc.client, name as SessionCMPClient and select Ejb Home as au.com.tusc.session.StoreAccessHome and Ejb Interface as au.com.tusc.session.StoreAccess.

This will generate required methods for you in your SessionCMPClient class and you only have to invoke loginUser, getCustomerData, getManagerData (Manager Bean was developed as part of an exercise in the previous chapter) and getOutOfStockItems as shown below.

Now, the last step is to write the code for your client.

In order to access out of stock items we need an Iterator and an ArrayList for items. So, declare two variables of these respective types, and import the packages for these types (which are java.util.ArrayList and java.util.Iterator) .

Iterator itemsIterator = null; ArrayList items = null;

And now add these lines of code to invoke the methods mentioned above.

System.out.println ( "Request from client:"); String userID = myBean.loginUser ( "ANDY", "PASSWD"); System.out.println ( "Reply from Server: Your userid is" + userID); CustomerData cd = myBean.getCustomerData (userID); System.out.println ( "Andy your details with MyStore are" + cd); String mgrID = myBean.loginUser ( "RUSTY", "PASSWD"); System.out.println ( " Reply from Server: Your mgrid is "+ mgrID); ManagerData md = myBean.getManagerData (mgrID); System.out.println (" Rusty your details with MyStore are "+ md); System.out.println (" Manager Request: List items out of stock "); myBean.getOutOfStockItems items = (); itemsIterator = items.iterator (); System.out.println (" List Of Out Of stock Items "); while (itemsIterator.hasNext ()) (ItemData itemData = (ItemData) itemsIterator.next (); System.out.println ( "Item Data" + itemData);)

Test your Client:

Now, in order to test your client, Select SessionCMPClient node> Go at top level menu and select the icon with the 'Running Man'.

On that select 'Run as'> select Java Application, as shown below.

Now on your console, and if you get a reply saying two items out of stock which are 'CALCULATOR' and 'CLOCK', then your call is successful as shown below.

Exercise:

Now, here is an exercise for you. In order to proceed further, implement Supplier as a CMP Entity Bean. The tasks are given below:

Create a CMP Bean named Supplier under package au.com.tusc.cmp.
Implement the ejbCreate method, with all attributes passed as arguments and then assigned to attributes using mutator methods.
Add a find method named findUserID with query and signature:

Query "SELECT OBJECT (b) FROM MyStoreSupplier as b where b.userID =? 1"

Method au.com.tusc.cmp.SupplierLocal findUserID (java.lang.String userID)

Note: The method signature is find Instead of findByPrimaryKey, because finder methods for non-key CMP attributes use this convention. Accordingly the return type for finder methods will be either Collection or , As specified in the EJB specification, sections 10.5.6 and 10.5.2 respectively.
Add a business method to get supplier details with signature:

Public SupplierData getSupplierData ()
Add a business method to get request items from various suppliers with signature:

Public void requestItem (String itemID, Integer quantity)
Add callback methods, required for setting / unsetting bean context with signatures:

Public void setEntityContext (EntityContext ctx)

Public void unsetEntityContext ()
Deploy the Supplier Bean.
Add a field to StoreAcess Bean to store its reference:

Private SupplierLocalHome supplierLocalHome
In the ejbCreate method of StoreAccess Bean store a reference in supplierLocalHome variable by invoking the getLocalHome static method in supplierUtil.

Add a business method to StoreAccess Bean with signature:

Public ItemData getItemData (String itemID)
Add the following tags for deployment at class level for linking / referencing Supplier.

1. @ Ejb.ejb-ref ejb-name = "Supplier" view-type = "local" ref-name = "SupplierLocal" 2. @ Jboss.ejb-jndi ref-ref-name = "SupplierLocal" jndi-name = "SupplierLocal"

Test your Supplier Bean by running your Test Client created for Item named SessionCMPClient.

Note: All these steps are same as were done for Item. Implement this Bean which will be used in subsequent chapters.

In case you have difficulty, we have provided a SupplierBean class, modified StoreAccessBean class and SesiomCMPClient class. You can download these files under downloads below.

Downloads:

SupplierBean

StoreAccessBean

SessionCMPClient

â†‘ Back

Tutorial for building J2EE Applications using JBOSS and ECLIPSE -7

Abstract: Tutorial for building J2EE Applications using JBOSS and ECLIPSE -7

Chapter 7.

Creating a Message Driven Bean

This chapter covers how to create a Message Driven Bean (MDB) EJB component. We will create two MDB beans, DeliverItems and RequestItems as shown below. The DeliverItems bean will replenish the stocks of various items within MyStore, and the RequestItems bean will send requests to various suppliers to deliver items which are out of stock. The MyStore manager will issue / send this request.

Note: Both message-driven beans access the StoreAccess bean through its remote interface, even though the StoreAcessBean is in the same JVM. This is because we have implemented StoreAccessBean as a Remote Bean, so it only exposes its remote interface. However, in accessing the Manager and Item beans, which are also used by these message-driven beans we can use their local interfaces as they are in the same JVM, and we have exposed their local interfaces.

Tasks:

Create a MD bean named RequestItems under package au.com.tusc.mdb.
Create an Immutable Value Object named RequestItem under package au.com.tusc.mdb. Add attributes and implement their accessor and mutator methods. The attributes are:

Private String username

Private String passwd

Private String itemID

Private int quantity
Implement the onMessage method.
Deploy the RequestItems Bean.
Create your test client named RequestMDBClient under package au.com.tusc.mdb.
Add a method named testMDBBean with the following signature and implement it.

Public void testMDBBean
Run your client and test the bean.

Create RequestItems MDB Bean:

Go To Package Explorer> Expand Mystore (project) node> select src, right click and a menu will pop up.

On the pop up menu> New> Lomboz EJB Creation Wizard.

Enter package name au.com.tusc.mdb, bean name RequestItems and select bean type as Message Drive Bean (Queue) as shown below.

Press Finish.

This will create a package named au.com.tusc.mdb under src and RequestItemsBean within that package as shown below.

Note: Message-driven beans listen for messages from a JMS Producer, which gets information from a producer (perhaps another bean) and transfers it to the relevant Consumer bean. Since it is only responsible for processing such messages, it doesn't need any helper classes such as Remote and RemoteHome interfaces, Util classes, DAO class, etc. like our previous types of beans. The only helper classes we have to create are immutable value objects, which will be responsible for holding the information extracted from messages and then transferred to the bean (s).

Let's examine what methods and tags are generated by the EJB creation wizard ..

It creates one@ejb.bean tag which assigns the name, transaction type, destination type and some other properties as shown below.

Unlike our previous beans it has a setMessageContext method for setting the context.

It has ejbCreate and ejbRemove methods like the other types of beans, as shown below.

It has a new method named onMessage which is the one of significance to us, where all the business logic will be written (as shown below).

Once Once a message is received from the JMS producer as a Message object, and its data is extracted and filled into the immutable value object and then transferred to the relevant bean. This is covered later on in this chapter.

Now, before we add any functionality, create a class or immutable value object for extracting information from the message.

Create Immutable Value Object RequestItem:

Go to src> under package au.com.tusc.mdb> New> Class.

The java class wizard will pop up> Add class name as RequestItem, Superclass as java.lang.Object and Interfaces as Serializable as as shown below in figure.

This will generate a RequestItem class under au.com.tusc.mdb as shown below.

Add the following attributes to the RequestItem class as shown below.

Private String username; private String passwd; private String itemID; private int quantity;

Add accessor and mutator method for these attributes.

Select all attributes> Right click> Select source> Generate Getter and Setter as shown below.

Add a constructor for the class which has parameters with the same type as the attributes and assigns them to the attributes as shown below.

The RequestItem constructor is complete. Now to implement the onMessage method in the RequestItem Bean.

Implement onMessage Method:

This method is responsible for extracting the information from the message and transferring it to the relevant bean.

The MyStore Manager will check for items which are out of stock and generate a request to suppliers specifying the itemID and quantity required.

First import the packages java.util.ArrayList and java.util.Iterator.

Add the following variables to store references.

ArrayList outOfStockItems = null; Iterator itemsIterator = null; private StoreAccessHome storeAccess = null; private SupplierLocalHome suppLocalHome = null; private ItemLocalHome itemLocalHome = null;

Extract the data from the message into the immutable value object as shown below.

RequestItem ri = (RequestItem) ((ObjectMessage) message). GetObject ();

Add the lines of code shown below, so that the manager can login.

StoreAccess access StoreAccessUtil.getHome = (). Create (); String mgrAccessID = access.loginUser (ri.getUsername (), ri.getPasswd ());

Get items with zero quantity (no stock), by invoking getOutOfStockItems () on the StoreAccess Bean (which returns a Collection).

OutOfStockItems = access.getOutOfStockItems ();

Now, iterating over each item, get the supplierId associated with it by invoking the finder methods on the Supplier Bean, finally sending the required message to that supplier by invoking the business method requestItem () on the Supplier Bean.

ItemsIterator = outOfStockItems.iterator (); while (itemsIterator.hasNext ()) (ItemData itemData = (ItemData) itemsIterator.next (); String suppID = itemData.getSupplierID (); SupplierLocal supplier = this. SuppLocalHome.findByPrimaryKey (suppID); Integer quantity = new Integer (ri.getQuantity ()); String itemID = ri.getItemID (); supplier.requestItem (itemID, quantity);)

Code snippet of onMessage is shown below.

Now our bean is complete, and all that remains are the deployment descriptors for the bean.

Deploy RequestItems Bean:

In order to deploy this bean we have to add a few deployment descriptors. As shown below, five tags have been added.

First add the tag shown below at class level in the RequestItems Bean, to obtain a reference to StoreAccessBean, so that methods can be invoked on that bean.

@ Ejb.ejb-ref ejb-name = "StoreAccess" view-type = "remote" ref-name = "StoreAccess"

This tag will generate deployment descriptors in ejb-jar.xml when you generate your ejb classes, as this message bean has to authenticate, before transferring information to the relevant bean. This will generate these descriptors as shown below.

Add another tag as shown below, to obtain a reference to the Supplier Bean from this bean.

@ Ejb.ejb-ref ejb-name = "Supplier" view-type = "local" ref-name = "SupplierLocal"

This tag will generate also generate descriptors in ejb-jar.xml when you generate your ejb classes, as this message bean transfers information to the Supplier bean. The following descriptors are generated as shown below.

Note: Another descriptor which has been generated is , Which is generated by the tag@ejb.bean that was added by the EJB creation wizard.

This tag generates the following descriptors in ejb-jar.xml:

Add another tag as shown below. This tag is JBOSS-specific, and is used to register a message-driven bean with a jndi-name, using the format "queue / name."

@ Jboss.destination-jndi-name name = "queue / MdbQueue"

This will generate the following deployment descriptors in jboss.xml:

Note: For further documentation on MDB development with JBOSS, please refer to the JBOSS documentation.

Add another tag as shown below, required by JBOSS, for finding the Supplier bean using its JNDI NAME.

@ Jboss.ejb-jndi ref-ref-name = "SupplierLocal" jndi-name = "SupplierLocal"

Note: As discussed in chapter5, this tag generates incorrect descriptors within jboss.xml. For view-type = "local" it generates an Tag rather than an Tag.

Correct the following tags:

Find these tags in jboss.xml and change them to As shown below.

Now add this last tag as shown below for our StoreAccess Bean, to reference the StoreAccess bean using its JNDI NAME.

@ Jboss.ejb-jndi ref-ref-name = "StoreAccess" jndi-name = "StoreAccessBean"

This tag will generate the following descriptors in jboss.xml:

Now our RequestItems Bean is complete, so now add your bean and generate your EJB classes.

Go to the RequestItemsBean node under au.com.tusc.mdb> right click> select Lomboz J2EE …> Add EJB to Module> Ok.

Go to the MyStoreMgr node in Package Explorer> right click> select Lomboz J2EE …> Generate EJB classes.

Note: Since you have generated your classes you have to again fix the incorrectly-generated deployment descriptors in jboss.xml, under And .

Now, let's deploy our bean. Go to Lomboz J2EE View, start your server if it is not running, and deploy your bean.

Messages will appear in console showing deployment status.

Note: Steps for deploying beans have been detailed in previous chapters.

Once the bean is deployed successfully, create your test client.

Create Test Client:

Now, to create a test client in this case, the Test Client Wizard can't help us, because it requires a Home interface and EJB interface to be selected, whereas for Message Driven Beans there is no Home interface and EJB interface required (as discussed above).

So, write a class and the necessary methods to invoke operations on the RequestItems Bean.

Add a class named RequestMDBClient under the package au.com.tusc.mdb.

Add a method named getContext with the following signature:

Private InitialContext getContext () throws NamingException

Add the following lines of code to get the instance of IntialContext as shown below.

Add a method named testMDBBean with the following signature.

Public void testMDBBean ()

Now implement this method, in which the following steps are needed:

Add a Data Object which is to be sent as the message.
Create the Initial context reference.
Create the Connection factory reference.
Use this context to perform the lookup, where the lookup string is "queue / MdbQueue."
Create the QueueConnection.
Create the QueueSender.
Create the QueueSession for the bean.
Create the Object Message and pass the Data Object in message.
Send the message.
Finally, commit the session, and then close both the session and the connection. A code snippet of the testMDBean method is shown below.

Now your test client is complete, so let's test the client.

Test your Client:

To test your client, Select RequestMDBClient node> Go to the top level menu and select the 'Running Man' icon.

On that select 'Run as'> select Java Application.

Note: The steps to run test clients have been covered in previous chapters.

Now, under your console, you should get the following messages:

This message on the console doesn't tell us whether the message has been delivered to relevant beans or not. In order to verify that, go to the database using JMX Management Console View> Hypersonic> Invoke Database Manager and then run a query on table 'supplier' to see if a message has been added for the supplier.

Note: Details on accessing this Database Manager are provided in chapter 1.

Since a supplier named Sebastian has received our message, our message has been transferred successfully.

Exercise:

Now, to progress further, please complete the following exercise. Implement DeliverItems as an MD bean. Detailed tasks are given below.

Create an MD Bean named DeliverItems under the package au.com.tusc.mdb.
Create an Immutable Value Object named DeliverItem under the package au.com.tusc.mdb. Add some attributes and implement their accessor and mutator methods. The attributes are:

Private String username

Private String passwd

Private String itemID

Private int quantity
Implement the onMessage method in your DeliverItems Bean.

Add these two variables to store references.

Private StoreAccessHome storeAccess = null; private ItemLocalHome itemLocalHome = null;
Extract the data from the message into your immutable value object as shown below.

DelieverItem di = (DeliverItem) ((ObjectMessage) message). GetObject ();
Get the references for the StoreAccess and Item beans.

StoreAccess access StoreAccessUtil.getHome = (). Create (); itemLocalHome = ItemUtil.getLocalHome ();
Invoke the loginUser method for supplier to get the Supplier's userid (accessID) and then find the Supplier's ID by invoking the getSupplierData method.

String suppAcessID = access.loginUser (di.getUsername (), di.getPasswd ()); SupplierData sd = access.getSupplierData (suppAccessID); String suppID = sd.getSupplierID ();
If suppID is not equal to null, then invoke the finder method on the Item bean to get the details of the item to be delivered, by extracting itemID from message.

ItemLocal item = this. ItemLocalHome.findByPrimaryKey (di.getItemID ());
Get the supplier ID associated with the item found, so we can fill up the stock.

String itemSuppID = item.getSupplierID ();
Compare itemSuppID and ItemID, if these are the same then fill the stock for that item by invoking the fillStock method in Item bean.

If (suppID.equals (itemSuppID)) (System.out.println ( "Delivering items in store now …:"); Integer quantity = new Integer (di.getQuantity ()); item.fillStock (quantity); System . out.println ( "Stock of iten after dleivery is:" + item.getItemData ());)
Add the following tags for deployment at the class level for linking / referencing Supplier.

1. @ Ejb.ejb-ref ejb-name = "StoreAccess" view-type = "remote" ref-name = "StoreAccess" 2. @ Ejb.ejb-ref ejb-name = "Item" view-type = "local "ref-name =" ItemLocal "3. @ jboss.ejb-jndi ref-ref-name =" ItemLocal "jndi-name =" ItemLocal "4. @ jboss.ejb-jndi ref-ref-name =" StoreAccess "jndi - name = "StoreAccessBean" 5. @ jboss.destination-jndi-name name = "queue / DelMdbQueue"

Deploy your DeliverItems Bean.
Create a test client named DeliverMDBClient under the package au.com.tusc.mdb.
Add a method named testMDBBean with the following signature.

Public void testMDBBean
Implement testMDBBean, for this a few steps have to be carried out.

Add a Data Object which is to be sent as the message.

Create Initial context.

Create Connection factory.

Using this context perform the JNDI lookup, where the lookup string is "queue / DelMdbQueue."

Create QueueConnection.

Create QueueSender.

Create QueueSession for the bean.

Create Object Message and pass the Data Object in the message.

Send the message.

Finally, commit the session and close both the session and the connection.

Run your client and test the bean.

â†‘ Back

J2EE or. NET, this is a problem

Abstract: J2EE or. NET, this is a problem

Users of the Web services platform for the opposition camp has not yet feeling, but software developers have to follow a platform which are perplexed.

Microsoft. NET and Sun's J2EE, is played fiercely.

History from the viewpoint,. NET, and J2
EE war, is actually the Windows platform and Unix platforms continuation of the struggle. Because. NET all relevant applications to be based on the Windows platform, and all the J2EE application, there is no doubt that the establishment of the Unix foundation.

For software developers or users of the CTO, CIO, in the J2EE and. NET between the choice is a painful issue.

Relates to the choice of the future

For software developers, the option to decide the future fate of the company.

If you choose. NET, all future product development will be only one vendor - Microsoft. Employees to use Microsoft's operating system, using Microsoft's development tools, learning Microsoft's development rules, the final product can only run on Microsoft products. Microsoft product upgrades soon, and after updating platform there are still some places not compatible. Although the first implementation of the cost is relatively low, but the high cost of upgrading will enable users and providers of headaches.

Of course, Microsoft products cheaper, the development of low cost, ease of use development tools, the development of high efficiency. However, these strengths is the other side of the huge training costs. Microsoft product updates very frequently, the need for ongoing staff training. If the purchase of Microsoft's technical services, the cost of 8,000 yuan a day every software company is not able to bear.

And most customers have a preconceived impression: running on the Microsoft platform in the price of the product will not be too high. This means that developers based on Microsoft's platform products can only embark on the path of puerile.

Since an understanding of Microsoft products were too many people, almost all of the virus, the majority of hacker attacks are directed at the Microsoft platform. Therefore, some customers on the Microsoft platform security questionable. Involved in high-reliability, high-security, high traffic systems usually will be carefully considered by the Microsoft platform. Naturally, this is detrimental to developers.

As China's securities software leader, Hangzhou, the Hang Seng Electronics Co., Ltd. now went to the crossroads to make choices. The main products before they are on the Ministry of business development, mostly based on the Windows NT platform. Since entering the field of securities software much earlier, the Hang Seng is a lot of implementation of the programme or in the Windows NT 4.0. On the Hang Seng, the Ministry of thousands of business customers as resources, the burden is: If you want to upgrade, the workload would be astronomical; if we continue to use Windows NT 4.0, Microsoft also unable to get sufficient support.

Now the focus of the securities industry growing calls, the Hang Seng existing system faced the danger of being eliminated. In the recent Shenyin Wanguo Securities Co. Ltd. platform for a new generation of information systems 32 projects in the tender process, the marketing department has occupied half of the Hang Seng business systems even without a nominated products, which allow them to take into consideration the development of new products . After hesitation, the Hang Seng final stand on the side of the Sun, will focus on a new generation of securities trading systems ported to Unix platform.

Beijing Orient National Tsing Hua University (Mitac) Technology Development Co., Ltd. is a major industry for the procuratorate office system solutions and the case of smaller companies. As early as in 1998, they have developed the C / S system on the case by the procuratorate of the industry's praise. But in May 2001, this product has been nearly three years did not escalate. Development of new products will inevitably involve the development platform of choice, because it's Procuratorate units belonging to state secrets, from the market strategy, they very much hope that the choice of J2EE development environment, access to the system's Procuratorate core areas. However, the company's seven existing software development staff are master the Windows platform, and the original products are based on Microsoft's platform, the transition is risk î± widen? BR>

After three long months of discussion, the final choice of the National Tsing Hua University Oriental Microsoft. NET platform, and rapid introduction of new products, the price is to give up access to the procuratorate, the court core areas of opportunity. The high-chairman Dr. Cheng is still somewhat less willing to be: "If funds allow, I would like to develop a set can be used in Unix and Linux platform products."

Those in the industry have long-term accumulation of software companies who CTO, and many hope that at this critical moment seize development opportunities, the original system will be upgraded to J2EE platform. J2EE is by the open, cross-platform, security, and many big companies have their full support. Regardless of the hardware platform, operating system, database, middleware, application systems have a lot of choices, only one development, it will have different needs, different levels of completion of the programme.

However, Sun, Oracle, IBM and other big companies have declared full support although J2EE, but various options are different. IBM so-called provide comprehensive solutions, the use of DB2 for the database to WebSphere middleware as a development platform, development tools is VisualAge - all IBM's own system. As a Sun ONE open network environment the core J2EE claiming to be open system, which can be any part of the replacement of the other sub-standard products. However, in actual use, they still have all kinds of compatibility issues.

J2EE development tools Although there are many, such as Sun's Forte, Borland's J Builder, IBM VisualAge, and Microsoft. NET development platform compared with the database integration and ease of use there is still a gap. If a development with a project, the use of J2EE progress than might use. NET slower. This is a tight time of the project is not good news.

Although J2EE is common, but due to different manufacturers database, the Web server, middleware server, and so forth have some subtle differences, it is necessary to develop truly cross-platform products on the need for all the products are proficient, respectively with different settings different parameters, but also for long periods of time debugging, which is small and medium-sized software companies and the difficulty level.

In addition, programmers familiar with J2EE than familiar with Microsoft's product development staff to pay a higher, to a variety of good around the entire J2EE platform project managers and systems analysts higher salaries.

In fact, more important to software developers market strategy issues. If the new products abandon the original Microsoft platform, will allow users to increase the cost of migration platform, users also need re-training. If the two platforms at the same time developing products to increase their own equivalent to a competitor.

UFIDA Group in the development platform of choice on the same difficult choice, its original ERP-U8 products are basically on the Windows platform, and many high-end users to the Windows platform stability, reliability and scalability are the doubt, UF sales and technical staff to Bijinkougua explained to the customers.

As a new generation of products ERP UF-NC, the whole environment based on J2EE development, and positioning in the low-end customers in the ERP-U8 compared to this generation product positioning in the high-end customers, and system design from the start and ERP - U8 completely separate, with their own separate sales teams. Although UF groups of human, financial and material resources to support the development of the two teams to achieve two basic functions similar products, but in product sales, but encountered insurmountable problems: the two products customers in the ERP market mainstream — mid-market customers coincidence, product pricing, similar to basic services, two single sales forceæŠ¢it will be difficult to avoid.

Kai Technology Co., Ltd. Beijing in the transition to a more representative. The company in the struggle of the 1967 book industry, the main provider of Invoicing System. Two years ago, the company developed using ASP a simple online bookstore software, recognized by the market. But this year in the bidding Xinhua Bookstore outlet and the National Book distribution networks, the Xinhua Bookstore outlet for their existing products with the scalability of the system reliability was questioned. The project had to, the company vice president Pan Yi inspected almost all of the middleware vendors, the final choice of the hard-hearted BEA's middleware platform, and Huadaijiajian hired experts in this regard: "The input was justified , which is the company filed a chance, the company is also a breakthrough in the development bottleneck gambling. "

Although it is a small manufacturers, the Internet-based set up card, the Network Information Technology Co., Ltd. is not a low starting point, they Unix-based platform online securities trading system in the Huaxia Securities received positive feedback, but a higher development costs , a relatively high price, marketing heavy resistance. "Compared with the Windows platform, our products in terms of functionality, performance, reliability, scalability, there are certain advantages, but many customers was more focus on price." Card, a sales network said.

Demand everything

The end-users of the CIO how choice?

If the past is the use of Microsoft products, and they can continue to use, because not spend too much time learning. However, users must upgrade to Microsoft's frequent preparation. One of the first IT project investment costs may be relatively low, but the operating system, database, middleware, and other constantly upgrading, patching up the high cost of upgrading.

In addition, little pressure in the system, the use of the frequency is not high, based on the Microsoft platform maintenance costs may be relatively low. But if the rapid development of business, the system should be expanded, the system expansion costs may suddenly high, and multi-server cluster management is not general information management staff can do.

The development platform in the war, most of the users use their experience CIO judgement, and take into consideration their own business needs and the actual situation. Usually small and medium-sized users or in the non-core areas tend to Microsoft products, and medium and large business customers or core Unix environment preferred.

Northwest Corporation Limited only a dozen business department, the choice of online trading systems in the process of technical director Zhao Bing repeatedly grams hesitation, decided to use the Windows platform. "As a small firms, the business system now not so much need, our technical personnel to not familiar with Unix, we repeat here alsoç•™ä¸ä½Unix expert."

In the state-owned enterprises, China National Petroleum Corporation, the information system than the earlier. "We are a large state-owned enterprises nationwide, PC platform simply can not sustain the entire operational system, from the beginning, most of our core business platforms are Unix platforms, but also have a large number of reserves in this area. Now choose J2EE new business development on the natural systems that it is logical. "Information Center of the company told a reporter.

Precisely because of J2EE and. NET war, there will be advances in technology. While it is somewhat irreconcilable differences between the two major camps, but in the end is likely to Web Service-based moving toward integration, this is the hope of all the industry.

â†‘ Back

Tutorial for building J2EE Applications using JBOSS and ECLIPSE -4

Abstract: Tutorial for building J2EE Applications using JBOSS and ECLIPSE -4

Chapter 4.

Creating a Stateful Session Bean

This chapter covers how to create a stateful session EJB component. Unlike stateless beans, stateful bean instances are associated with a particular client session and can therefore maintain information useful during the lifetime of that session. A classic and familiar example of this in a web e - commerce context is that of a shopping cart.

We'll try something a little less ambitious for the time being! This bean is similar to the StoreAccess Bean created in the previous chapter except that it will store the userID of the client, after authentication is successful.

Note: This bean will not be used further in tutorial, as this chapter demonstrates how stateful beans are created.

Tasks:

Create a Stateful Session Bean named StoreAccessState.
Add a business method in the bean named loginUser with the signature

Public String loginUser (String username, String password)
Add a call back method ejbCreate with the signature

Public void ejbCreate (String userID)
Generate the DAO interface.
Access the DAO named StoreAccesDAOImpl under package au.com.tusc.dao, created and implemented in the previous chapter. This DAO has a method named loginUser, called by loginUser in the bean with the signature

Public String loginUser (String username, String password)
Deploy the StoreAccessState bean.
Create your test client named SessionStateClient under package au.com.tusc.client.
Run your client and test the bean.

Create Stateless Bean:

Go To Package Explorer> Expand Mystore (project) node> select src, right click and a menu will pop up.

On pop up menu> New> Lomboz EJB Creation Wizard.

Enter the package name au.com.tusc.sessionState, bean name StoreAccessState and select bean type as stateful> Finish.

This will create package named au.com.tusc.sessionState under src and StoreAccessStateBean under that package as shown below.

As we can see from the figure above it has created a class level tag@ejb.bean, which has assigned the bean type, name and its JNDI name which will be generated in the Home interface. This tag will also generate deployment descriptors in ejb - jar.xml and jboss.xml file as well once you generate your EJB classes, which is covered later on in this chapter.

Note: It will generate the bean name, jndi-name and type of bean in file. Also, the name of file is appended with word 'Bean' as you gave the name of the bean as StoreAccess only. So be careful with your naming convention, as you only need specify the bean name in the wizard (ie. without a 'Bean' suffix as the wizard will append that for you).

Create DAO Interface:

Since we are going to use a DAO to access the database for this Stateful Bean, we will use the StoreAccesDAOImpl class which was created and implemented in the previous chapter. This will provide the implementation for the generated DAO interface.

Now go to your Bean class and declare this tag at class level (i: e; at top), as described below to generate the DAO interface.

@ Ejb.dao class = "au.com.tusc.sessionState.StoreAccessStateDAO" impl-class = "au.com.tusc.dao.StoreAccessDAOImpl"

Expand the StoreAccessStateBean node under Package Explorer. Right click and a pop up menu will appear.

On that menu go to Lomboz J2EE> Add EJB to module. Select EJB MyStoreMgr> OK.

Note: This step is covered in previous chapter.

Expand MyStoreMgr node under MyStore Project in Package Explorer. Right click and a pop up menu will appear.

Go to Lomboz J2EE> Generate EJB Classes as shown in figure at right.

EJB interfaces and helper classes are generated under 'ejbsrc' directory as shown on the right.

Seven files are generated.

StoreAccessState is our remote object interface.

StoreAccessLocal is our local object interface.

StoreAccessStateSession extends our bean class named StoreAccesStateBean.

StoreAccessStateHome is our remote home interface.

StoreAcessStateLocalHome is our local home interface.

StoreAccessStateUtil is a helper class which has methods for accessing Home and LocalHome interface along with generating GUID.

StoreAccesStateDAO is the DAO interface, which be implemented by StoreAccessDAOImpl under au.com.tusc.dao.

StoreAccessStateDAO is generated by this tag declared in StoreAccesStateBean as shown below. If you don't declare this tag in that file it won't generate this interface.

@ Ejb.dao class = au.com.tusc.sessionState.StoreAccessStateDAO impl-class = au.com.tusc.dao.StoreAccessDAOImpl

Other files of interest which are generated are ejb-jar.xml 'and jboss.xml' under MyStoreMgr / META-INF.

</ Td> <td width="30%">

</ Td> </ tr> </ thEAD> </ table> <table cellSpacing=4 cellPadding=3 width="100%" border=0> <thEAD> <tr VAlign=top> <td width="42%">

As shown in figure at right, a few descriptors are generated in the 'ejb-jar.xml' file.

These descriptors are generated by the following tag declared in the StoreAccessBean file, which was generated by Lomboz.

@ Ejb.bean name StoreAccessSate jndi-name = = = StoreAccessStateBean type Stateful </ Td> <td width="58%">

</ Td> </ tr> </ thEAD> </ table>

This tag also generates the following descriptors in jboss.xml as shown below.

Add Business Method:

The next step is to add a business method to the bean.

Go to StoreAccesStateBean node> right click> select New on pop up menu.

Select Lomboz EJB Method Wizard.

Note: This step is covered in the previous chapter.

Add a business method with the following signature ..

Public String loginUser (String username, String password).

Select Method Type as Business and Interface as Remote as shown below ..

This wizard generates a loginUser method in our bean class, with the method level tag '@ ejb.interface' shown below.

This tag is responsible for generating this method in the Remote Interface (in this case it is StoreAccessSate which will be created once you generate your classes).

Now, this business method needs to invoke a method on the DAO, which encapsulates access to the database.

So, add another tag on this method so that a method with this signature is generated in the DAO interface. We can then implement that method in our DAOImpl class so that our business method can get the desired result.

LoginUser dao.call name = @

Add this tag at the method level as shown on the right.

Now generate your EJB classes again as shown in the steps earlier.

OK, for reference these are the steps you have to follow:

Expand 'MyStoreMgr' node under 'MyStore' Project in Package Explorer.

Right click> pop up menu.

Go to Lomboz J2EE> Generate EJB Classes.

</ Td> <td width="48%">

</ Td> </ tr> </ thEAD> </ table>

Add Callback Methods:

In contrast to the Stateless bean, the ejbCreate method will have an argument. This will be used to initialize a persistent field in the bean.

Add that field, and add accessor and mutator methods to access that field as shown below.

Public abstract class StoreAccessStateBean implements SessionBean (private String userID; / ** * * @ ejb.interface-view-type method = "remote" * / public void setUserID (String userID) (this. UserID = userID;) / ** * method * @ ejb.interface-view-type = "remote" * / public String getUserID () (return userID;)

Now add the ejbCreate method with the signature

Public void ejbCreate (String userID)

Assign userID to the persistent field userID we created above as shown.

Now, the other two callback methods required to complete this bean are

1. SetSessionContext.

2. UnsetSessionContext.

Add a field to store sessionContext.

Protected SessionContext ctx;

Add a method setSessionContext with sessionContext as its parameter and assign that to the sessionContext variable as shown below.

Similarly, add a method unsetSessionContext which sets the context variable to null as shown above.

Note: The StoreAccessStateSession class inherits the StoreAccessStateBean abstract class and implements SessionBean, which will override all methods of the interface SessionBean. So, after completing the methods in your bean class, and generate your EJB classes again. The SessionContext methods will be overridden, as discussed in previous chapter.

Generate EJB classes.

Note: The steps to generate the EJB classes are discussed above and in the previous chapter.

Implement DAO Interface:

We don't have to implement the DAO interface as we are using the StoreAccessDAOImpl class created and implemented in the previous chapter.

So go into the StoreAccessDAOImpl class and change the class declaration statement, so that it implements StoreAccessStateDAO interface, as shown below in code snippet.

Now, all methods are implemented, and only deployment descriptors remain to be done.

Deploy Bean:

In order to deploy our bean we have to declare a few tags in StoreAccessStateBean class as shown below.

Add the tag shown below in StoreAccessStateBean at class level (at the top).

@ Ejb.resource-ref res-ref-name = "jdbc / DefaultDS" res-type = "javax.sql.Datasource" res-auth = "Container"

This tag will generate deployment descriptors in ejb-jar.xml, as the bean has to know which datasource you are going to connect, and what is its type, etc. This will generate these descriptors as shown below.

Add this tag shown below in StoreAccessStateBean at class level (at top).

@ Jboss.resource-ref res-ref-name = "jdbc / DefaultDS" jndi-name = "java: / DefaultDS"

This tag will generate deployment descriptors in jboss.xml, as the application server has to know with what jndi-name the datasource has been registered with. This will generate these descriptors as shown below.

Add this tag shown below in StoreAccessStateBean at class level (at top).

@ Jboss.container-configuration name = "Standard Stateful SessionBean"

This tag will generate deployment descriptors in jboss.xml, as the application server has to know which configuartion is to be read for Stateful Bean from standardjboss.xml under / opt/jboss/jboss-3.2.1/server/all/conf /. This will generate these descriptors in jboss.xml as shown below.

StoreAccessState StoreAccessStateBean Standard Stateful SessionBean Jdbc / DefaultDS Java: / DefaultDS

Note: This configuration is for container in Jboss to read for Stateful Session Bean. Jboss comes with timeout of 60 mins for stateful session bean. Change the Attribute to 120 secs (i: e2 mins) and restart your server as shown below in code snippet from / opt/jboss/jboss-3.2.1/servaer/all/conf/standardjboss.xml.

Standard Stateful SessionBean False Stateful-rmi-invoker ————————————————– —————– ——————————— ————————————- ————- ————————————————– —— Org.jboss.ejb.plugins.LRUStatefulContextCachePolicy 50 1000000 120 120 To 120 secs (2 mins) and restart the server to read this config. 300 600 400 60 1 0.75 ————————————————– ——————– —————————— —————————————

Now, everything is complete, and it's time to deploy the bean.

First, regenerate your EJB classes as shown in the steps above for the final time.

Note: We have regenerated the classes again and again in order to explain every step and its result. Once you are familiar with these steps you will only need to generate your classes a few times as you go. Either way, it doesn't affect your implementation, so you can (re) generate your classes however you prefer to work.

Go to Lomboz J2EE View> expand node MyStore> expand MyStoreMgr> select 'Jboss 3.2.1 ALL'.

Right click> select 'Debug Sever' on the pop up menu.

Go to MyStoreMgr node in LombozJ2EE view> right click> select Deploy on the pop up menu.

Note: These steps are covered in the previous chapter.

And now wait for your deployment result.

If everything goes fine, you will have this message under your console as shown below.

So, now your bean is deployed successfully, let's create a test client, which will invoke the loginUser method on StoreAccessStateBean.

Create your Test Client:

Go to Project MyStore node> select src node> right click.

Select New on pop up menu> select Lomboz EJB Test Client Wizard as shown below.

Select package name au.com.tusc.client, with name SessionStateClient and select Ejb Home as au.com.tusc.sessionState.StoreAccessStateHome and Ejb Interface as au.com.tusc.sessionState.StoreAccessState as shown below.

This will generate the necessary helper methods for you in your SessionStateClient class and you simply have to invoke the loginUser method on bean.

So add the lines of code shown below in the testBean method.

Public void testBean () (String userID = null; try (au.com.tusc.sessionState.StoreAccessState myBean = getHome (). Create (userID); //————— ———————– / / This is the place you make your calls / / System.out.println (myBean.callYourMethod ()); System . out.println ( "Request from client:"); userID = myBean.loginUser ( "ANDY", "PASSWD"); System.out.println ( "Reply from Server: Your userid is" + userID); myBean.setUserID (userID); System.out.println ( "Going to Sleep for 1 min ……………………."); Thread.sleep (60000 ); / / sleep for a minute. System.out.println ( "Reply from bean after 1min" + myBean.getUserID ()); System.out.println ( "Again going to Sleep for 3 min … ………………. "); Thread.sleep (180,000); / / sleep for three minute. System.out.println (" Resuming after 3 mins … …………………. "); / / Next statement will not be executed as bean will timeout on the server side / / resulting in exception. System.out . println ( "Reply from bean after 2mins" + myBean.getUserID ());) catch (InterruptedException e) () catch (NoSuchObjectException e) (System.out.println ( "No Such Object Exception caught");) catch ( RemoteException e) (System.out.println ( "Remote Exception caught");) catch (CreateException e) (e.printStackTrace ();) catch (NamingException e) (e.printStackTrace ();) catch (EJBException e) ( System.out.println ( "EJB Exception caught");)) public static void main (String [] args) (SessionStateClient test = new SessionStateClient (); test.testBean ();)

Test your Client:

Now, in order to test your client, Select SessionStateClient node> Go at top level menu and select the icon with the 'Man running'.

On that select 'Run as'> select' Java Application '.

Now under your console, if you get your reply for 'ANDY' as' U2 'event after 1 min but after 3 mins NoSuchObjectException is caught then your stateful bean is successful as shown below.

Note: So our Stateful Session Bean is deployed and tested successfully. This particular Bean is not used again in this tutorial.

â†‘ Back

Tutorial for building J2EE Applications using JBOSS and ECLIPSE -5

Abstract: Tutorial for building J2EE Applications using JBOSS and ECLIPSE -5

Chapter 5.

Creating a BMP Entity Bean

This chapter describes how to create a Bean Managed Persistence (BMP) EJB component. We will create two BMP beans, Customer and Manager, as shown below. The Customer bean will be responsible for storing the details of customers of MyStore. The Manager bean stores details of the manager of MyStore. Both beans communicate with their respective tables in the database using Data Access Objects (DAOs) named CustomerDAO and ManagerDAO respectively.

All customers have been assigned a unique customerID for housekeeping purposes in MyStore in addition to their username for accessing the services of MyStore. Similarly the Manager of MyStore has been assigned a unique ManagerID.

Note: It is the usual practice to access business methods of BMP beans via a session bean, which encapsulates business logic and acts as an interface to further EJB components. In this case Customer and Manager are accessible via by StoreAccess.

This approach comes from a pattern called a Session Facade, whereby enterprise beans encapsulate business logic and business data and expose their interfaces. The session bean acts as a facade to encapsulate the complexity of interactions with the lower-level beans. The session facade is responsible for managing business objects and provides a uniform business service abstraction to presentation layer clients, thereby hiding the business object implementation in the lower-level beans.

This tutorial uses that pattern for business tier implementation.

Tasks:

Create a BMP bean named Customer under package au.com.tusc.bmp.
Create a DAO class named CustomerDAOImpl under package au.com.tusc.dao.
Add all attributes / properties to the CustomerBean, with getter and setter methods for each of the attributes.
Add a finder method named ejbFindByPrimaryKey with the signature

Public CustomerPK ejbFindByPrimaryKey (CustomerPK pk) throws FinderException
Add a finder method named ejbFindByUserID with the signature

Public CustomerPK ejbFindByUserID (String userID) throws FinderException
Add a business method named getCustomerData with the signature

Public CustomerData getCustomerData ()
Implement required methods in the CustomerDAOImpl class.
Deploy the Customer Bean.
Add a create method to the StoreAccess Bean.

Public void ejbCreate () throws javax.ejb.CreateException
Add a business method to the StoreAccess Bean.

Public CustomerData getCustomerData (String userID)
Create a test client named SessionBMPClient under package au.com.tusc.client.
Run your client and test the bean.

Create the Customer BMP Entity Bean:

Go To Package Explorer> Expand Mystore (project) node> select src, right click and a menu will pop up.

On the pop up menu> New> Lomboz EJB Creation Wizard.

Enter package name au.com.tusc.bmp, bean name Customer and select bean type as Bean Manged Entity> Finish.

This will create a package named au.com.tusc.bmp under src and CustomerBean under that package as shown below.

Note: It will generate the bean name, jndi-name and type of bean in file. Also, the word 'Bean' is appended to the name of the file.

As we can see from the figure above it has created a class level tag@ejb.bean, which has assigned the bean type, its name and its JNDI name which will be generated in the Home interface. This tag will also generate deployment descriptors in ejb-jar.xml and jboss.xml file once you generate your EJB classes.

Now we are going to generate all the interfaces including Home, Remote, DAO and other helper classes. We don't need to specify any tags in ejbGenerate.xml as we have already set up that for the MyStoreMgr EJB module in chapter 3.

Go to node CustomerBean under au.com.tusc.bmp> LombozJ2EE> Add EJB to Module> Select MyStoreMgr> Ok.

Go to MyStoreMgr node> LombozJ2EE> Generate EJB classes.

Note: All these steps are covered in previous chapters (chapter 3 and 1) so please refer to those sections if you need further details.

Now let's see what files are generated by Xdoclet.

As shown below there are two new files named CustomerData and CustomerPK in addition to what we had for our session beans. We also have a CustomerBMP which extends our CustomerBean class. The remaining files should be familiar from our work with session beans.

As discussed in chapter 3 regading the various ejbDoclet tags used in ejbGenerate.xml, to generate these classes, CustomerData and CutomerPk are generated by following tags as shown below in this snippet from ejbGenerate.xml:

The relevant tags are And .

Note: There is no CustomerDAO class, as we haven't generated that file by specifying the dao tag in the CustomerBean class.

Create Customer's DAO Interface:

Since we are going to use a DAO to access database for this bean, we have to create a DAOImpl class to provide an implementation for the generated DAO interface.

Go to src> package au.com.tusc.dao> Add a class CustomerDAOImpl in that package.

Now go to your bean class and declare this tag at class level (ie. at the top) as shown below to generate the DAO interface.

@ Ejb.dao class = "au.com.tusc.bmp.CustomerDAO" impl-class = "au.com.tusc.dao.CustomerDAOImpl"

Regenerate your classes and check that your DAO interface is generated.

Note: For reference the steps are as follows:

Expand MyStoreMgr node under MyStore Project in Package Explorer.

Right click and a pop up menu will appear.

Go to Lomboz J2EE> Generate EJB Classes as shown on the right.

As shown below, our DAO interface is generated.

</ Td> <td width=473>

</ Td> </ tr> </ thEAD> </ table>

If we look at the generated DAO class as shown below, it has four more methods than StoreAccess (which was a Stateless Session Bean) did when we first generated it (ie. prior to adding the method level @ dao: call tag).

Note: It's worth mentioning here that BMP Entity beans don't need the @ dao: call tag for generating DAO interface methods.

All these methods are generated by the tag described earlier for DAO interface generation, also shown below.

Also, let's look at the descriptors generated up until this step, in ejb-jar.xml under MyStoreMgr / META-INF.

These descriptors are generated by the following tag in CustomerBean.

@ Ejb.bean name = "Customer" jndi-name = "CustomerBean" type = "BMP"

This tag generates descriptors in jboss.xml as well, which will be covered later on.

</ Td> <td width="43%">

</ Td> </ tr> </ thEAD> </ table>

The next step is to add attributes / properties to our Customer Bean, which will be accessible to clients through the remote interface using getter and setter methods. These attributes are mapped to corresponding columns in the relevant table in the database.

In order to add these properties / attributes, and define all attributes (as private to encapsulate) and their corresponding accessors / mutators (getter and setter methods). Each accessor (getter) method will have two tags or three in the case of a primary key . The mutator (setter) method will have only one tag declared on it.

Add these tags for attributes / properties (in Bean terms) as shown below.

/ **

* Returns the customerID * @ return the customerID ejb.persistence * * @ * @ * @ ejb.pk-ejb.interface-field method * / public java.lang.String getCustomerID () (return customerID;) / ** * Sets the customerID * @ param java.lang.String the new customerID value * * @ ejb.interface-method * / public void setCustomerID (java.lang.String customerID) this.customerID = customerID;

)

Code snippet from CustomerBean is shown in figure at right.

</ Td> <td width=456>

</ Td> </ tr> </ thEAD> </ table>

Now, analyzing these tags,

@ Ejb.persistence specifies this as a persistent attribute. All accessor and mutator methods will be overridden in generated BMP class, in this case it is CustomerBMP, and all mutator methods will have a dirty flag in them, as persistence is controlled by ejbLoad ( ) and ejbStore ().
@ Ejb.pk-field specifies that this attribute is mapped to a primary key in database and and is assigned as a primary key in the PrimaryKey class, in this case the CustomerPK class.
@ Ejb.interface generates these methods in the Remote interface.

Now, in the case of mutator methods (that is' setCustomerID ') the only tag required is@ejb.interface-method for generating this method in the remote interface.

Similarly, add methods and their tags for rest of the persistent fields. There will be no@ejb.pk-field tag as customerID is the primary key.

Note: In the case of a composite primary key you have to specify@ejb.pk-field tags on the other attributes / properties which make up the composite key.

Similarly, Add tags and methods for rest of the persistent fields, which in this case are, firstName, lastName, Address, phone and shareholderStatus as shown in this code snippet from CustomerBean.

Generate EJB classes and examine what methods are generated in the various classes, particularly in CustomerBMP and CustomerData.

Add Finder Methods:

Now let's add a finder method to our bean class.

Add a method with this signature:

Public CustomerPK ejbFindByPrimaryKey (CustomerPK pk) throws FinderException

Put some debug statements in it and return null as shown below.

Now when we generate our EJB classes this method will be overridden in CustomerBMP. Also this method will call a corresponding method from CustomerDAO interface as shown below in this code snippet from CustomerBMP.

This will also create methods in the Home interface and DAO interfaces as shown below.

Add another finder method to CustomerBean, with the signature

Public CustomerPK ejbFindByUserID (String userID) throws FinderException

Put some debug statements in it and return null as shown below.

Note: As stated in the EJB spec 12.8.1 all finder methods should return the Primary Key.

Again, regenerate your EJB classes, and there will be methods created in the CustomerHome interface, CustomerBMP and CustomerDAO, similar to those that were created for ejbFindByPrimaryKey.

A code snippet from the CustomerDAO class, after generating the EJB classes.

Add Business Methods:

Now, add a business method with the signature

Public CustomerData getCustomerData () with Interface type as local.

Note: The steps to add a business method are covered in previous chapters (1 and 3), so please refer to them. Also, we have chosen the interface type to be local because these methods will be invoked in the same Java Virtual Machine. In this case they will be invoked by the stateless bean StoreAccess.

This will provide the details of an individual customer. Add some debug statements and return an instance of CustomerData as shown below in this code snippet from CustomerBean.

Make sure you generate your EJB classes again before you start implementing Customer's DAO interface.

Implement Customer's DAO Interface:

Now let's implement our methods in CustomerDAOImpl class.

CustomerDOAImp class under package au.com.tusc.dao implements methods generated in CustomerDAO class under package au.com.tusc.bmp.

First import the following packages.

Javax.naming.InitialContext; javax.sql.DataSource; java.sql.Connection; java.sql.PreparedStatement; java.sql.ResultSet; java.sql.SQLException;

Change your class declaration so that CustomerDAOImpl implements CustomerDAO.

Add a field to store the JDBC resource factory reference.

Private DataSource jdbcFactory;

In the init () method, locate the reference jdbc / DefaultDS using the JNDI API, and store the reference in variable jdbcFactory.

The lookup string is "java: comp / env / jdbc / DefaultDS."

Code snippet is shown below.

In method load (), first get the connection to the database using field jdbcFactory. Create a SQL statement which searches for a record corresponding to customerid in table Customer, where customerid is the primary key. Code snippet is shown below.

In method store (), first get the connection to database using field jdbcFactory. Create an SQL statement which updates a record corresponding to customerid in table Customer, where customerid is the primary key. Code snippet is shown below.

In method ejbFindByUserID (), first get the connection to database using field jdbcFactory. Create an SQL statement which searches for the customerid corresponding to a given userid in table Customer, where customerid is primary key. Code snippet is shown below.

In method ejbfindByPrimaryKeystore (), first get the connection to database using field jdbcFactory. Create an SQL statement which searches for customerid in table Customer, where customerid is the primary key. Return the primary key. Code snippet is shown below.

Also, you should implement methods remove and create. We're leaving those as an exercise for you (you've probably got the idea by now!), Or you can leave them as stubs as shown below.

Now our CustomerDAOImpl class is finished. Generate your EJB classes again.

After generating your EJB classes, let's look at the Home Local Interface and the Remote Local interface.

In the Remote Local Interface (which is CustomerLocal in this case), there is one business method exposed, and the rest are all the methods to access the attributes / properties of the bean (as we also declared these methods as interface methods in CustomerBean) , as shown below. These methods are generated by@ejb.interface-method tag.

In the Home Local Interface, which is CustomerLocalHome in this case, there are two finder methods as shown below. It has also generated JNDI_NAME and COMP_NAME (logical name to lookup the component).

These names are generated by the following tag declared in CustomerBean as shown below.

Note: We are not currently interested in the Customer interface (which is a Remote interface) and CustomerHome (which is a Remote Home interface), because we are accessing bean methods in the same Java Virtual Machine, so we need only Local interfaces.

Note: In CustomerBean we haven't implemented any methods for the setting and unsetting of context, because it is generated by Xdoclet in the CustomerBMP class, as shown below.

Now Customer Bean and its DAO implementation is complete and we can deploy this bean.

Deploy Customer Bean:

In order to deploy this bean we have to add a few deployment descriptors to it. We will add the two tags shown below.

First add the tag shown below at class level in CustomerBean.

@ Ejb.resource-ref res-ref-name = "jdbc / DefaultDS" res-type = "javax.sql.Datasource" res-auth = "Container"

This tag will generate deployment descriptors in ejb-jar.xml, as the bean has to know which datasource you are going to connect to, and what is its ts type, etc. This will generate these descriptors as shown below.

Add this second tag required for the JBOSS application server.

@ Jboss.resource-ref res-ref-name = "jdbc / DefaultDS" jndi-name = "java: / DefaultDS"

Now everything is complete, and it's time to deploy the bean. So, regenerate your EJB classes.

Note: As noted in earlier chapters we are regenerating classes over and over to properly illustrate each step and its result. Once you are proficient you will be able to forgo most of this.

Go to Lomboz J2EE View> expand node MyStore> expand MyStoreMgr> select 'Jboss 3.2.1 ALL'.

Right click> select 'Debug Sever' on pop up menu.

Note: This is to start your server, if you are already running your server then skip these steps and go to the next one.

Go to MyStoreMgr node in LombozJ2EE view> right click> select 'Deploy' on pop up menu as shown in figure below.

Note: All these techniques have been shown in previous chapters (1 and 3) so please refer to them.

The messages in the console will show whether your bean has been successfully deployed or not.

Now our Customer Bean is complete, and in order to create a client to invoke operations on this bean we have make some modifications to our StoreAccess Bean.

Note: As shown in the diagram at the beginning of this chapter that client will invoke operations on Customer Bean through Store AccesBean, as it is a good practice to access Entity Beans in this manner. As a result we need a Local view of Customer Bean rather than Remote, because both are in the same Java Virtual Machine.

Add Create Method in StoreAccess:

In StoreAccess Bean add an ejbCreate method, which will create a BMP Entity Bean (in this case a Customer Bean) with the following signature

Public void ejbCreate () throws javax.ejb.CreateException

Now, add a field to store the reference obtained by locating Customer in JNDI.

Private CustomerLocalHome customerLocalHome;

In ejbCreate method store the reference in the customerLocalHome variable by invoking the getLocalHome static method in CustomerUtil class as shown in the code snippet below from StoreAccess Bean.

Add Business Method in StoreAccess:

Add another business method in StoreAccess Bean which will invoke the corresponding business method on Customer Bean.

Now, add a business method with this signature public CustomerData getCustomerData (String userID) with Interface type as Remote. As customers will log on to MyStore with username, once they are authenticated they will be identified by userid and they can retrieve their account details from MyStore using this userid.

Note: Steps to create business methods are covered in previous chapters.

Now invoke one of the finder methods of Customer on the reference variable we have created in the ejbCreate method.

CustomerLocal myCustomer = customerLocalHome.findByUserID (userID)

Now invoke the business method on Customer using the myCustomer reference variable.

MyCustomer.getCustomerData CustomerData cd = ()

Code snippet of this business method is shown below.

All methods in StoreAccess Bean have now been added for the accessing the Customer's business method. All that remains are the deployment descriptors required for linking / referencing the StoreAccess and Customer beans. We will add the two tags shown below.

First add this tag at class level in StoreAccess Bean.

@ Ejb.ejb-ref ejb-name = "Customer" view-type = "local" ref-name = "CustomerLocal"

This tag will generate deployment descriptors in ejb-jar.xml, as StoreAccessBean has to know which bean it's referring to, and what is its view-type and ref-name. This will generate these descriptors as shown below.

Note: View type is local as both are in the same Java Virtual Machine, otherwise it would be Remote. Note that ref-name is generated as CustomerLocalHome rather than CustomerHome. Both are generated but we are using Local in this case.

Now add the second tag shown below at class level in StoreAccess Bean.

@ Jboss.ejb-jndi ref-ref-name = "CustomerLocal" jndi-name = "CustomerLocal"

This tag will generate deployment descriptors in jboss.xml, as the application server has to know what jndi-name Customer Bean has been registered with. This will generate these descriptors as shown below.

Note: Ref-name and jndi-name are used for bean as local (in same JVM).

Note: As we can see from the code snippet above, the deployment descriptor generated by tag @ jboss is wrong, because for local referencing of Customer tag Should be . There seems to be a bug in this tag, so we will correct this manually by changing the tag in the jboss.xml file as shown below.

Caution here: Make sure that you do this change manually after you finish regenerating your EJB classes, because every time you regenerate your classes, 'jboss.xml' will initially have the wrong descriptors generated by this tag.

Now our changes to StoreAccess Bean are complete, so deploy your bean again now from the Lomboz J2EE View. The steps to do that are shown above and in previous chapters. Messages will appear in the console showing the status of deployment.

Once your bean is deployed successfully, create a test client which will invoke the loginUser method on StoreAccessBean and getCustomerData on CustomerBean.

Create your Test Client:

Go Go to Project MytStore node> select src node abd expand it> select au.com.tusc.client package> right click.

Select New on pop up menu> select Lomboz EJB Test Client Wizard.

Note: These steps are covered in previous chapters.

Select package name au.com.tusc.client, name as SessionBMPClient and select Ejb Home as au.com.tusc.session.StoreAccessHome and Ejb Interface as au.com.tusc.session.StoreAccess as shown in figure below.

This This will generate required methods for you in your SessionBMPClient class and you simply invoke the loginUser and getCustomerData methods as shown.

Now to add some code to your client.

Add these lines under the testBean method as shown below.

Test your Client:

Now, in order to test your client, Select SessionBMPClient node> Go at top level menu and select the 'Man running' icon.

On that select 'Run as'> select Java Application, as shown below.

Now under your console, if your reply for 'ANDY' is' U2 ', and his details for CustomerID are' C2 'as well, then your call is successful (see below).

Exercise:

Here is an exercise for you. To progress further, implement Manager as a BMP Entity bean similar to Customer, with the same behaviours. The detailed tasks are given below.

Create a BMP Bean named Manager under package au.com.tusc.bmp.
Create a DAO class named ManagerDAOImpl under package au.com.tusc.dao.
Add all attribute / properties in ManagerBean, add accessor and mutator methods for each attribute.
Add a find method named ejbFindByPrimaryKey with signature

Public ManagerPK ejbFindByPrimaryKey (MangerPK pk) throws FinderException.
Add a find method named ejbFindByUserID with signature

Public MangerPK ejbFindByUserID (String userID) throws FinderException
Add a business method named getManagerData with signature

Public ManagerData getManagerData ()
Implement methods in ManagerDAOImpl class. Lookup string required for JNDI API is the "java: comp / env / jdbc / DefaultDS."
Deploy Manager Bean.
Add a field in StoreAccess Bean to store reference after lookup in JNDI for Manager

Private ManagerLocalHome managerLocalHome;
In ejbCreate method of StoreAccess Bean store reference in managerLocalHome variable by invoking getLocalHome static method in ManagerUtil.
Add a business method in StoreAccess Bean.

Public MangerData getManagerData (String userID)
Add the following tags for deployment at class level for linking / referencing Manager.

1. @ Ejb.ejb-ref ejb-name = "Manager" view-type = "local" ref-name = "ManagerLocal" 2. @ Jboss.ejb-jndi ref-ref-name = "ManagerLocal" jndi-name = "ManagerLocal"
Test your Manager Bean by running your Test Client created for Customer named SessionBMPClient.

Note: Don't forget to fix the generated descriptors in jboss.xml as mentioned above in relation to Customer Bean.

Note: All these steps are the same as those for Customer. Implement this Bean which will be used in subsequent chapters.

In case you're unable to do that, we have provided ManagerBean, ManagerDAOImpl, modified StoreAccessBean and modified SessionBMPClient classes. You can download these files from downloads below.

Downloads:

ManagerBean

ManagerDAOImpl

StoreAccessBean

SessionBMPClient

â†‘ Back

J2EE Best Practices

Abstract: J2EE best practices

Introduction In the past five years, many people have written on the J2EE best practices in the books and articles. Now there are about 10 (or more) books and numerous articles on how to build their applications to the J2EE insights. Indeed, the reference in this regard so much, and these references often also exist some contradictions on the recommendation, when you move through these confusing times, these deluded itself on the use of J2EE formed a kind of barrier. In order to be able to have this confusing provide some simple guidelines, so we set out the following "the most important 10" list, we feel they are the most important J2EE best practices. Unfortunately, the 10 not on the content of all the contents, especially when your Web services development as part of J2EE. Therefore, in order to enable J2EE development, we have decided to use the "12 most important" rather than a list of "the most important ten" list.

In order not to complicate the issue, we use - the most important 10 (+ 2) J2EE best practicesâ€¦â€¦

Best practice

Always use MVC framework.
In the application of each layer are automatically unit testing and test management.
In accordance with the norms for development, rather than in accordance with the application server for development.
From the outset, plans to use J2EE security.
Create your know.
When using EJB components, always use the session Facades.
The use of non-state session bean, and not state the session bean.
Management of the affairs of the use of containers.
JSP as a layer that will be the first choice.
When using the HttpSession, only to the needs of the current state of preservation firm which, not other content stored in the HttpSession.
In WebSphere, launched dynamic cache, and use WebSphere servlet caching mechanism.
In order to improve the efficiency of the work of programmers, CMP entity bean as O / R mapping the preferred solution.

1. Always use MVC framework.

MVC framework can be business logic (Java beans and EJB component), the logic controller (Servlets / Struts action), that layer (JSP, XML / XSLT), left to clear. Stratification can be a good many benefits.

MVC framework for the successful use of J2EE is so important that no other par with the best practices can be. Model - View - Controller (MVC) design is the basis of J2EE applications. MVC your code a simple divide between the following points:

Responsible for the business logic of the code (ie model - usually use EJB or ordinary Java objects to achieve).
Responsible for the user interface shows that the code (ie view - usually through the JSP and markings to achieve, and sometimes also used to achieve XML and XSLT).
Responsible for the application process code (ie controller - normally used as Struts or Java Servlet controller to achieve such a category).

There are many excellent on the MVC Review particular, we recommend interested readers can refer to [Fowler] or [Brown] article (see reference), you can get on the MVC comprehensive and deeper understanding.

If you do not follow the basic MVC framework in the development process there will be many problems. The most common problem is that in the view of adding too many components, for example, there may be labeled using JSP to implement database access, or in JSP applications for the process controls, which in small-scale applications in a more often see, but, with the latter part of the development, it will be a problem, because JSP gradually become more and more difficult to maintain and debug.

Similarly, we often see will be built on the view of the business logic situation. For example, a common problem in the building is the view of the use of XML technology directly applied to the analysis of the business. On the business of business should be targeted - not bind to the specific data that view operate.

However, only a suitable component does not necessarily mean that you can make the appropriate application procedures are stratified. We often see some applications include servlet and JSP and EJB all three components, however, its main business logic is in the servlet layer, or in the navigation application in JSP processing. You must carry out stringent checks and Reconstruction code your code to ensure that the application's business logic layer only in the model (Model layer) with only navigation through the application layer controller (Controller layer) processing, and your view (Views) will only transfer from the model object to the form of HTML and JavaScript that out.

2. In the application of each layer is the use of automatic unit testing and test management.

Not just to test your graphical user interface (GUI). Hierarchical test to test and maintenance work has become extremely simple.

In the past few years, in the way the field has been considerably innovations, such as the new emerging called Agile (such as SCRUM [Schwaber] and Extreme Programming [Beck1], see references) lightweight method now has been very common applications. Almost all of these methods in a common characteristic is that they are advocating the use of automated testing tools, these tools can help developers with less time for regression testing (regression testing), and can help them avoid the regression testing inadequate the wrong, it can be used to improve the efficiency of the work of programmers. In fact, there is a Test-called First Development [Beck2] approach, which even advocates in the development of the code before the actual preparation of unit testing first. However, in your test code, the code you need to be separated into a number of test pieces. A "big mud ball" is difficult to test, because it is not only the realization of a simple function for easy identification. If each of your code snippet achieve many aspects of the functions of such a code will be difficult to ensure its complete accuracy.

MVC Framework (J2EE, as well as the realization of MVC) is one of the advantages of the component elements can be (in fact, quite simple) on your application procedures for unit testing. Therefore, you can easily entities on the bean, bean and JSP session to prepare an independent test case, without considering other code. There are many tests for the J2EE framework and tools, frameworks and tools make this process more simple. For example, JUnit (from junit.org is a development of open-source tools) and Cactus (from the Apache open-source development tools) testing J2EE components are very useful. [Hightower] discussed in detail how to use these tools in J2EE.

Despite all these elaborate on how thoroughly test your application, but we still see some people think that as long as they test the GUI (perhaps Web-based GUI, or a standalone Java application), then they fully testing the entire application. GUI test difficult to achieve a comprehensive testing, the following reasons. First, using a GUI to thoroughly test the system to test every one path, GUI is only a way to influence the system, there may be background operation, the script and a wide range of other access points, this also needs to be tested. However, they usually do not have GUI. Secondly, GUI-level testing is a very coarse-grained tests. This test is only at the macro level test systems. This means that once the problem, and this problem must be related to inspect the entire subsystem, which makes identifying bug (defect) will be a very difficult task. Third, GUI testing usually only in the latter part of the entire development cycle can be a good test, because this is the only GUI that time they were the definition of integrity. This means that only can be found in the latter part of the potential bug. Fourth, the development of general staff may not be automatic GUI testing tool. Therefore, when a developer to make changes to the code, there is no easy way to re-test the affected subsystems. This is actually not conducive to good test. If developers with automatic code-unit testing tools, developers will be able to easily run these tools to ensure that the changes will not disrupt the function already exists. Finally, if the added function of the automatic building, constructed in the process of automatically add an automated unit testing tools is a very easy matter. Upon the completion of these settings, the whole system can have a law to carry out reconstruction, and regression testing with virtually no people's participation.

Moreover, we must emphasize that the use of EJB and Web services for distributed, component-based development allows testing individual components become very necessary. If there is no "GUI" need to be tested, you must carry out low-level (lower-level) test. The best way to start this test, you will be properly distributed in the components or Web services as your application part of the process, you have to mentally re-test.

In short, through the use of automated unit testing, the system can be quickly found deficiencies, and these deficiencies can easily be found, making the tests become more systematic and therefore the overall quality can be improved.

3. Accordance with the norms for development, rather than in accordance with the application server for development.

To standardize memorize well in mind and if we deviated from the norms, to go through careful consideration before they can do so. This is because when you deviate from the rules, you are not doing what you should do.

When you want to deviate from J2EE allows you to do things, this makes it easy for you to the unfortunate. We found that there are some developers delve into some J2EE permission of the things that they can do so "slightly" to improve the performance of J2EE, and they will eventually be found to do so would cause serious performance problems, or in subsequent transplant (from the one vendor to another vendor, or from a more common version to another version) will emerge. In fact, this problem is so serious graft, which [Beaton] this principle is called the basic transplant best practices.

Now there are several places if we do not provide direct use J2EE approach will certainly create problems. A common example is the development staff through the use of modules to replace JAAS J2EE security, rather than using the built-in follow standardized application server mechanisms for authentication and authorization. Attention should be paid to not depart from the standard J2EE certification mechanism, if out of this specification, it will be a security system vulnerabilities and the main reason for manufacturers compatibility issues. Similarly, it is necessary to regulate the use of EJB servlet and the licensing mechanism, and if you want to deviate from these norms, to ensure that the use of well-defined API (such as getCallerPrincipal ()) to achieve a foundation. In this way, you will be able to use vendors to provide strong security infrastructure, and operational requirements to support complex licensing rules.

Other common problems include the use of non-standard J2EE follow lasting mechanism (which makes it difficult to manage affairs), the procedures used in J2EE inappropriate J2SE methods (such as threads or singleton), and use your own solutions procedures to the process (program - to-program) communications, rather than J2EE internal support mechanisms (such as JCA, JMS, or Web services). When you follow a J2EE server migrate to other servers, or migrate to a new version of the same server, the design choice will cause untold problems. The only deviated from the norms of the matter is that when a problem can not be solved within the framework of norms of the time. For example, the timing for the implementation of business logic in the EJB2.1 there is a problem before, in similar circumstances, we have suggested that when the companies are not providing solutions on the use of vendors to provide solutions (such as WebSphere Application Server Enterprise in the Scheduler tool), and in the absence of the vendor solutions on the use of third-party tools. If the use of vendors to provide solutions, applications, as well as the maintenance of its migration to the new standardized version will be a vendor problem, not your problem.

Finally, we must take care not too early adoption of new technology. Too enthusiastic about using J2EE has not yet integrated into the rest of the norms or not integrated into the vendor's products in the technology often will bring disastrous consequences. Support is key - If your vendor does not directly support a particular aspect of the JSR in the technology, but the technology has not been accepted by J2EE, then you should not be using this technology. After all, we have the majority of people engaged in resolving business issues, rather than to promote technological development.

4. Plan from the outset, using J2EE security.

Opening WebSphere security. This makes your URL at least EJB and that all authorized users can visit. Do not ask why -ç…§ç€åšyourself.

In cooperation with our customers, a plan to start commissioning WebSphere J2EE safety of customers is very small, this has been for us by surprise. According to our estimates only about 50% of the customers beginning to use this feature. For example, we had some of the major financial institutions (banks, agents, etc.) worked, they did not intend to enable security. Fortunately, this problem prior to deployment on the checks can be resolved.

Not using J2EE security is a dangerous thing. Suppose your application needs security (almost all applications need), you bet your developers to build their own security system, and this system than you bought from the J2EE makers better. This is not a good bet for distributed applications to provide security is extremely difficult. For example, you need to use network security encryption token control of EJB visit. With our experience, the majority of construction of the security of their own system is unsafe, and there are significant gaps, this system is very fragile product (please refer to [Barcia] Chapter 18).

Some do not use J2EE security reasons include: worried that the decline in performance, I believe that the safety of the other (for example, Netegrity SiteMinder) can replace J2EE security, or do not know WebSphere Application Server security features and functions. Not to fall into such traps, in particular, despite such as Netegrity SiteMinder product can provide excellent security features, but not only to protect its own entire J2EE applications. These products must be J2EE application servers can be combined with comprehensive protection for your system.

Other non-use of a common J2EE safety of the reasons are: role-based model does not provide sufficient granularity access control to meet the complex business rules. This despite the fact that, but it should not become the non-use of J2EE security reasons. On the contrary, should be verified and J2EE specific J2EE roles and the expansion of the rules together. If the complex business rules needed to be made safe decision-making, then the preparation of the corresponding code, the security of decision-making must be based on direct access to the J2EE certification, as well as reliable information (user ID and role).

5. Create you know.

The development of repeatedly will allow you to gradually get hold of all the J2EE module. From the creation of small and simple modules start from the beginning and not immediately related to all modules.

We must recognize that J2EE is a vast system. If a development team is only beginning to use J2EE, which will be difficult to grasp all of a sudden it. In J2EE There are too many concepts and API need to have. In such circumstances, master J2EE is the key to start with simple steps.

This method can be adopted in your application in the creation of small and simple modules to be best realized. If a development team through the creation of a simple domain model and the sustainability of the back-end system (perhaps using the JDBC), and the integrity of its testing, which will enhance their self-confidence, so they would use the domain model to and use the servlet and JSP front-end development. If a development team found it necessary to use EJB, they will be started in containers similar to the management of persistent EJB component on the use of a simple conversation Facades, or use the JDBC-based data access object (JDBC-based Data Access Objects, DAO ), rather than skip these to the use of more complex structures (such as JMS and message-driven bean).

This approach is nothing new methods, but rarely in such a manner Development Group to develop their skills. On the contrary, since the majority of the development group to immediately build all the modules, at the same time involved in the view of the MVC model layer and controller layer, the result of this is that they often will fall into the progress of the pressure. They should consider some agile (Agile) development methods, such as Extreme Programming (XP), which adopted an incremental development methodology learning and development methods. In XP there is a call ModelFirst [Wiki] process, and this process involves construction of the first domain model as a mechanism to organize and achieve users scene. Basically said, you want to build your domain as a model to achieve the primary users of the scene, and then in the domain model on building a user interface (UI) as the user scenes to achieve results. This method is very suitable for a development group at a time to learn a technique, rather than allow them to face a range of conditions (or let them read many books), they will collapse.

Moreover, the duplication of each application layer may include the development of appropriate models and best practices. If your application from the start of the bottom of some models such as data access object and speak Facades, you should not be in your view JSP and other objects used in the domain logic.

Finally, when you develop some simple modules, in the early stages can be started on your application performance testing procedures. If the application until late in the development of a performance test, it is often catastrophic consequences, as described in [Joines].

6. When using EJB components, always use the session Facades.

Never entity bean to direct exposure to any user type. The entity bean can only use local EJB interface (Local EJB interfaces).

When using EJB components, the use of a session Facades undoubtedly is a confirmation of best practices. In fact, this common practice has been widely applied to any distributed technology, including CORBA, EJB and DCOM. Fundamentally speaking, your application distribution of "cross-regional" more bottom of the small pieces of data due to multiple network relay time consumption caused by the less. To achieve this objective is by means of: creating a large granularity Facades object, and this object contains logic subsystems, and can call on the adoption of a method to be completed some useful business functions. This approach can not only reduce network overhead, but also in the whole EJB internal business functions through the creation of a panel environment can greatly reduce the number of visits to the database ([Brown] to a detailed discussion of this [Alur] the standard model said. [Fowler] (including addition and outside the EJB), and its [Marinescu] also was described. see references).

EJB local interface (from the beginning of the use of EJB 2.0 specification) for the coexistence of EJB provide performance optimization method. Local interface must be your application to visit Explicit, which requires code changes and prevent future configuration EJB applications need to change. Facades and conversation because it contains the whole EJB for each other, has to be local, we propose to the session bean Facades behind the use of local entities interface. However, the realization of their conversation Facades (typical examples such as stateless session bean) should be designed for remote interface.

In order to optimize the performance, a local interface can be added to the conversation Facades. This use of this fact: In the majority of cases (at least in the Web application), your EJB client and EJB will co-exist in the same Java Virtual Machine (JVM). Another, if Facades in the local session is called, can use J2EE application server configuration optimization (configuration optimizations), such as the WebSphere "No Local Copies." However, you must take note of these options will be available for interaction by way of transfer from the (pass-by-value) for the change cited by transmission (pass-by-reference). This may be in your code in a very subtle errors. When you want to make use of these options, you should consider at the outset of their viability.

If you have your conversation Facades used in the remote interface (rather than local interface), you can also Facades in the same conversation in a J2EE 1.4 compatible Web services as a way to configure. This is because the JSR 109 (J2EE 1.4 in the deployment of Web services) require the use of stateless session bean interface as a remote EJB Web services and achieving EJB interface. It is worth it, because it can be for your business logic to increase the number of client types.

7. Use of non-state session bean, and not state the session bean.

This can make the system can withstand the wrong end. HttpSession storage and the use of user-related condition.

To our point of view, the concept of state of the session bean has become obsolete. If you are careful to consider the state of a session bean with a CORBA object in the system is exactly the same structure, is nothing more than an object example, bundled with a server, and rely on servers to manage its life cycle. If the server shut down, and this kind of object also does not exist, then the bean client information also does not exist.

J2EE application server for the state's failure to provide session bean transfer (failover) to solve some problems, but the state of non-state solution no easy solutions to expand. For example, in the WebSphere Application Server, stateless session bean to the request by the state to the deployment of a conversation cluster members to achieve load balancing. On the contrary, not on J2EE application server at the request of a state bean load balancing. This means that your server clusters in the loading process is not balanced. Moreover, the use of a state bean session will be to add some to your state of the application server, this is bad practice. This will increase the complexity of the system, and the failure of the problem has become complicated. Create robust distributed systems as a key principle is to maximize the use of non-state acts.

Therefore, we suggest that the majority of applications to use non-state session bean method. Any need to use in dealing with the relevant state and users should be sent to the parameters in the form of EJB methods (and through the use of a mechanism such as HttpSession to store it) or from the back of persistent storage (such as through the use of entity bean ), as part of EJB Affairs retrieval. In appropriate circumstances, this information can be cached in the memory, but we should pay attention to in the distributed environment preservation of such cache of the potential challenges. Cache is very suitable for read-only data.

In short, you want to ensure that from the outset it is necessary to take into account and can be extended. Inspection of all the design ideas, and when you take into account the number of applications to run on the server when they can be in normal operation. The rules for the application of the code, but also to management such as MBean interface and other circumstances.

Avoid the use of not only the state of the IBM / WebSphere proposal, which is a basic J2EE design principles. See [Jewell] Tyler Jewell state bean with the criticism of their views and the views are the same.

8. Affairs administered by the use of containers.

J2EE learning about the two-stage submitted to the Panel, and this approach is used, instead of opening your own business management. Containers in the affairs optimization almost always quite good.

Use containers Management Service (CMT) offers two key advantages (if not support this vessel is almost impossible): The combination of robust modules and the work of the Panel.

If your application code explicit use of the beginning and ending Service (javax.jts.UserTransaction or even perhaps the use of local resources), and the requirements of the future needs of portfolio module (code may be part of reconstruction), kinds of circumstances often need to change Affairs code. For example, if the beginning of a module A database services, update the database, and then submitted to the Panel, and a module B to the same address, please consider when you try to use C module of the two modules, what will happen? Now, C module is the implementation of a logical action, and this action will in fact be calling two independent matters. If the module B in the implementation of the failure, and the module A business still can be submitted. This is what we do not want to see the acts. If, conversely, modules A and B are used CMT module if the module can also start a C CMT (usually through configuration descriptor), and modules A and B of the Service Module will be with the implicit part of a panel, This will no longer need to rewrite the code complex work.

If your application in the same operation need access to a variety of resources, you should use a two-stage submitted to the Panel. For example, if you delete from the JMS queue a message, and subsequently updated based on the records of this news, then, to ensure that these two operations will be implemented or will implement it becomes particularly important. If a message has been deleted from the queue, and this system has not been updated with information relevant records in the database, then the system is unstable. Some serious commercial disputes from customers and inconsistent state.

We often see some client application procedures to achieve their own solutions. Perhaps through the application procedures code in the database updated when the failure of "revoke" the operation of the queue. We do not advocate doing so. This realization of the imagination than you were much more complex, and there are many other cases (Imagine if the application in the implementation of this operation in the process of the sudden collapse). As an alternative means should be used in two phases submitted to the Panel. If you use CMT, and in a single visit to the CMT in the two-phase commit resources (such as database and most JMS), WebSphere will handle all the complex work. It will ensure that the Service was not implemented or being implemented, including a system crash, the collapse of the database or other circumstances. In fact, the transaction log is now kept in a state of affairs. When the application access to a wide range of resources, how we use CMT Affairs stressed the need not be overemphasized.

9. JSP will be the first choice as that layer.

That only need a variety of output types, and output type by a single controller and back-end support when using XML / XSLT.

We often hear argued that why you chose XML / XSLT rather than as a JSP that layer technology. Choose XML / XSLT people's view, the JSP "allows you to view and model mix", and XML / XSLT there will be no such problems. Unfortunately, this view is not entirely correct, or at least not as black and white points clear. In fact, XSL and XPath programming languages. XSL is completed Turing (Turing-complete), although it does not meet the definition of most programming languages, because it is rule-based, and programmers do not have the habit of control.

The problem now is that since the granting of this flexibility, developers will use this flexibility. Although everyone agreed that JSP developers to easily view by adding "similar model" behavior, and in fact, also in the XSL may make some of the same things. Despite a visit from the XSL in the database such things will be very difficult, but we have seen some extremely complex XSLT style sheet implementation of complex change, and this is actually model code.

However, the JSP should be chosen as the preferred technology that the most basic reason is that the JSP is now the most widely supported as well as the most widely understood view J2EE technology. Along with the definition of the markings, JSTL JSP2.0 and the introduction of new features, making it easier to create JSP, and does not require any Java code, as well as model and the view can be separated from clear. In some environments (such as WebSphere Studio) joined the JSP (including debugging support), with strong backing, and many developers found using JSP to develop than using XLS simple, some support for the JSP graphic design tools and other features (especially in the framework of this JSF) enables developers can WYSIWYG approach to the development of JSP, and the XSL sometimes not easy to achieve.

Finally, we should be prudent to consider using a JSP reason is speed. In contrast IBM's relative velocity XSL and JSP performance tests: In most cases, the JSP in the same generation of HTML, many times faster than XSL, and even the use of the XSL compiler as well. Although in most cases this is not the issue, but in the high performance requirements of the situation, this will become a problem.

This, however, can not say that, you will never do not use XSL. In some cases, the XSL to a group that fixed data, and can be based on a different style sheet (see [Fowler]) in different ways to display these data show that the ability of view the best solution. However, this is an exceptional situation, instead of generic rules. If you only generate HTML pages to express each one, then, in most cases, XSL is an unnecessary technology, and it gives you the development of the problems caused by staff than it can solve problems.

10. When using the HttpSession, only to the needs of the current state of preservation firm which, not other content stored in the HttpSession.

Persistent opening session.

HttpSessions applications for the storage status information is very useful. Its easy-to-use API and understanding. Unfortunately, developers often forgotten HttpSession purpose - to maintain a state of temporary users. It is not arbitrary data cache. We have seen too many system for each user's session Add to the large amount of data (up to megabytes). Well, at the same time if there are 1,000 users log system, each with 1 MB of user session data, it would require a G or more of memory for these sessions. For these smaller number of HTTP session data, otherwise, your application performance will be reduced. About a more appropriate amount of data for each user should be in session data between two K-4K, this is not a hard and fast rule, 8 K still no problem, but obviously than 2 K at the slower speed. We should pay attention to, not to allow the accumulation of data HttpSession into place.

A common problem is the use HttpSession cache some very easy to create information, if necessary. The session is persistent, and unnecessary sequence, as well as write data is a very extravagant decision. On the contrary, should be used in the hash table memory to cache data, and to preserve a conversation this data cited in the game. This way, if it can not be successful login to another application server, the data can be re-created. (See [Brown2])

When talking about persistent conversation, do not forget to enable this function. If you do not have opening session persistence, or the server for some reason stopped (server failure or normal maintenance), all the current users of the Service's session will be lost. This is a very unhappy thing. Users had to re-login, and re-do something they have already done things. Conversely, if the opening of the session persistence, WebSphere users will be automatically (and their session) moved to another application server. Users do not even know there is such a thing from happening. We have seen some of their products because of the system of local code is intolerable bug (not IBM's code!) And the sudden collapse of the situation, under such circumstances, these functions can still be running well.

11. WebSphere, the use of dynamic cache, and use WebSphere servlet caching mechanism.

By using these functions, system performance can be greatly increased, and overhead is very small. And would not affect the programming model.

Cache to improve performance through the benefits of the well-known things. Unfortunately, the current standard does not include a J2EE for servlet / JSP caching mechanism. However, WebSphere provides a page fragment caching, as well as the support of this support through its dynamic caching capabilities to achieve, and does not require the application to make any changes. Its cache is a statement of strategy, and its configuration through XML configuration descriptor to achieve. Therefore, your application will not be affected, and maintain compatibility with the J2EE standard and transplanted, but also from the WebSphere servlet and JSP caching mechanism to be performance optimization.

Servet from JSP and the dynamic caching mechanisms to improve the performance is obvious, depending on the application's characteristics. Cox and Martin [Cox] pointed out that on an existing RDF (resource description format) Site Summary (RSS) servlet, when using dynamic cache, its performance can be increased by 10%. Please note that the experiment involved only a simple servlet, the performance of the growth may not reflect a complex application.

In order to improve performance more, WebSphere servlet / JSP results cache and ESI Fragment WebSphere plug-in processor, IBM HTTP Server Fast Response Cache Accelerator (FRCA), and Edge Server cache features. Based on the reading of the heavy work load, using these functions can be many additional benefits. (See reference in the [Willenborg] described the improvement of the performance)

12 In order to improve the efficiency of the work of programmers, CMP entity bean as O / R mapping the preferred solution.

Through WebSphere Framework (readahead, cache, isolation level, etc.) to optimize performance. If possible, have a choice of some models to achieve the purpose of improving performance, such as the Fast-Lane reader [Marinescu].

Object / Relational (O / R) mapping is used to create enterprise-class Java application procedure. Almost every J2EE application procedures all need some type of O / R mapping. A J2EE vendors O / R mapping mechanism, such a mechanism in different manufacturers is one of the portable, efficient, and can be some good tools and standards to support. This is the standard EJB CMP (container management of persistent).

CMP to the early realization of poor performance and does not support many SQL structure is known. However, with EJB 2.0 and 2.1 standard, as well as being adopted by some vendors, and with as IBM WebSphere Studio Application Developer the emergence of these problems is no longer a problem.

CMP EJB component has now been widely used in many high-performance applications. WebSphere includes some optimization features to enhance the performance of EJB components, and optimization features include: on the life cycle and read-ahead cache capacity. These two functions are optimized configuration options, and does not require the application to amend or affect portability.

In a state of the life cycle cache cache CMP and to provide data on the state of the invalidity of time. In the buffer status from the life cycle of the performance improvement can be achieved Options A cache performance, and you can still provide the application of the extension. Read-ahead capacity and the relationship between the management of containers used in conjunction. This feature through the same query to retrieve arbitrary data related to the father as a data reduction and database interaction. If relevant data through the use of enquiry to visit with the case, this method can be performance improvements. [Gunther] provided a detailed description of these features are, as well as through improving the performance of the details.

Furthermore, in order to fully optimize your EJB components, when designated isolation level, should pay special attention to. As far as possible, using the lowest level of segregation, and still maintain the integrity of your data. Lower levels of segregation can provide the best performance, and can reduce the risk of a database deadlock.

This is the most controversial best practices. Has been a large number of articles praised CMP EJB, the same sound denigration also prevalent. However, the fundamental issue here is the development of the database is difficult. When you start using any lasting solution, and you need to have the database lock on these basic knowledge of how to work. If you choose to use CMP EJB, you want to ensure that you have adopted a number of books (such as [Brown] and [Barcia]) know how to use them. Compete in the lock and there are some subtle interaction difficult, but you spend a certain amount of time and effort will be at their disposal.

Concluding remarks in this brief summary, we have introduced you to the core J2EE patterns and best practices, which makes J2EE development into a managed process. Although we do not have all given in practice the use of these models in the necessary details, but we hope to give you enough guidance and guidance, to help you decide what to do next.

References

[Alur] Deepak Alur, John Crupi and Danny Malks of the "Core J2EE Patterns (Second Edition)", Addison-Wesley, 2003
[Bakalova] R. Bakalova waiting for the "WebSphere Dynamic Cache: Improving WebSphere Performance," IBM Systems Journal, in 2004 the first two volumes 43
[Barcia] Roland Barcia, such as writing "IBM WebSphere: Enterprise Deployment and Advanced Configuration," IBM Press, 2004
[Beck1] Kent Beck's "Extreme Programming Explained: Embrace Change", Addison-Wesley, 1999
[Beck2] Kent Beck's "Test Driven Development by Example", Addison-Wesley, 2002
[Beaton] Wayne Beaton's "Migrating to IBM WebSphere Application Server, Part 1: Designing Software for change," IBM DeveloperWorks
[Brown] Kyle Brown, and other co-authored the "Enterprise Java Programming with IBM WebSphere (Second Edition)", Addison-Wesley, 2003
[Brown 2] Kyle Brown, Keys Botzum's "Improving HttpSession Performance with Smart Serialization," IBM DeveloperWorks
[Cox] J. Stan Cox and Brian K. Martin's "Exploiting Dynamic Caching in WAS 5.0," Part1, e-Pro Magazine (2003 7 / 8 monthly)
[Fowler] Martin Fowler's "Patterns of Enterprise Application Architecture", Addison-Wesley, 2002
[Gunther] Harvey Gunther wrote, such as "Optimizing WebSphere 5.0 Performance Using EJB 2.0 caching and Read-Ahead hints," WebSphere Developers Journal, March 2003
[Jewell] Tyler Jewell wrote Stateful Session Beans: Beasts of Burden, OnJava.com
[Joines] Stacy Joines, Ken Hygh and Ruth Willenborg's "Performance Analysis for Java Websites", Addison-Wesley, 2002
[Marinescu] Floyd Marinescu's "EJB Patterns", John Wiley & Sons, 2002
[Schwaber] Ken Schwaber and written by Michael Beedle Agile Software Development with SCRUM, Prentice-Hall, 2001
[Wiki] Wiki Web site: http://c2.com/cgi-bin/wiki?ModelFirst
[Willenborg] R. Willenborg, K. Brown, G. Cuomo's "Designing WebSphere Application Server for performance: An evolutionary approach," IBM Systems Journal, in 2004 the first two volumes 43

â†‘ Back

J2EE pet store (1)

Abstract: J2EE in the enterprise Java technology is the application of computing, which includes a variety of computing standards such as EJB component architecture, JDBC database computing, JMS information transmission, Java Servlets / JSP Web components, such as procedures

J2EE in the enterprise Java technology is the application of computing, which includes a variety of computing standards such as EJB component architecture, JDBC database computing, JMS information transmission, Java Servlets / JSP Web components, such as procedures, powerful and the content is extensive and profound. To enable users to design a framework for J2EE application templates, Sun made a system called "Java Pet Shop (Pet Store)." Online pet shops example of this is already familiar with Java programs for the design and the concept of J2EE. The system is designed to use the formal manner, making use of the J2EE architecture has been the basis for a reference. This example one out, it was soon used as a comparison of the various products based on J2EE compatible. Oracle's J2EE Application Server (Oracle 9iAS), BEA WebLogic Server, IBM WebSphere have corresponding products. The spirit of the original Java standard is the individual manufacturers to develop technical standards, and then in accordance with this standard to the optimal product selection.

Java Pet Store using the framework of the so-called design of the MVC design pattern. MVC is Model-View-Controller's initials, to design a model, from Smalltalk. MVC-operated objects are divided into three categories, Model objects devoted to the state of packaging applications, View responsible for the display on the screen, the Controller is responsible for the definition of the application's various moves and response. Java pet shops MVC pattern design system uses the entire system architecture, each floor will be clearly separated from the object. Java is the purpose of pet shops display a scalable enterprise computing architecture is the adoption of the three-tier (3 - Tiers) Design: display information in the outermost layer, the middle is the implementation of enterprise computing logic of the middle layer components, is the back-end simply storing data relational database. Java pet shops originally intended only as a J2EE architecture design templates, and did not specifically address the additional acceleration performance for the design.

System architecture and pet shops Introduction

System Architecture

Pet Store web site design system uses loosely coupled architecture, and a number of data sources, interactive EIS. This example divided into four parts:

1.Web shopping site;

2. Management, including sales statistics, the manual accept / reject orders;

3. Order processing, which includes the following four parts:

â—† accepted by JMS / order processing information;

â—† using Java Mail to notify customers;

â—† JMS orders placed through to the supplier;

â—† database maintenance orders.

4. Providers, this section include the following:

â—† through JMS orders;

â—† delivery of the goods to the user;

â—† provide a Web-based inventory management;

â—† maintaining inventory database.

Pet shops online stores function

Through the browser can access this store. Customers browsing, the goods can Add to Cart, Register / login to your account, create orders, and then through credit card payments.

Pet shops structure

Pet shops web site services from the top down. At the top are the WAF (Web Application Framework) to control applications Jump screen, a view, and then call commercial components to complete business process (as shown in Figure 1).

Figure 1 Java Pet Store Structure

WAF provides many services for Web applications, including requests for filtration and distribution template view of the emergence of a series of reusable Taglib, screen and process control. Application components of the package to deal with logic, they represent the business data and operate their business data, EJB entity representing business entities, such as customers, address, accounts. EJB session provided some methods, such as landing a user, a user output, such as management Cart. Other session EJB provided some common methods, such as a sole identifiers. Traditional JavaBean components has become a target value, EJB components used in the transmission of data and applications. XML document type is used to order information.

WAF pet shops example of this is the blueprint for the J2EE Web layer specification can be achieved. A Web layer can be divided into four general steps (as shown in Figure 2):

â—† explain a request;

â—† implementation of a business logic;

â—† choice view;

â—† have this view.

Figure 2 WAF layer of the Web

Pet shops Module Design

Pet shops by independent modules:

â—† control module to its request to the various distribution business processing logic, control screen Jump to deal with the corresponding components and users;

â—† login and registration control module by WAF to achieve and expansion;

â—† Cart module users shopping cart tracking process;

â—† Login module requires users to log in some pages Login;

â—† news from the module, such as pet shops to a single center for asynchronous transfer orders;

â—† types of modules based on user needs to provide for a category of view;

â—† client module that customer information, such as address, credit cards, contact information, etc. (shown in Figure 3).

Figure 3 Java pet Store Module Design

In Figure 3, the control module controls all interaction and the implementation of each user session has a Cart counterparts.

Pet shops components

1. EJB, representatives of the commercial implementation of business logic and data processing;

2. JSP pages, definition of the view of the entire application framework template (template.jsp) and the composition of the various templates JSP documents, as well as various documents cited graphics;

3. XML documents, to define screen, the screen Jump control, bundled URL to a HTML Action, as well as customized signOn the deployment of J2EE deployment of XML documents;

4. Servlet worry, used to check the safety of users of the landing and output coding;

5. Asynchronous messaging components, the use of XML Packaging transmission of orders to order processing centres;

6. An installation program, the database used to produce examples.

Application of a pet store

Below the MVC framework and in accordance with the level of application model to analyze this application.

Model - View - control structure

1. Methods of Application Model

Analysis can be a practical application of the three methods: a partition method as a model - view - Control (MVC) architecture. Application of this method to decompose into data, display and control in three parts. The second application of the method in accordance with the different roles divided into different levels, from the client, Web layer, EJBs bottom layer and the data layer or layers of legacy systems, that is, the level of J2EE application method. The third division is the traditional function module division.

Division is to make the complex issues clear, and coherent. Although each of the additional increase in the complexity, but also has its advantages. MVC framework for the application components to provide a flexible, reusable and easy to test, which can be expanded and the design of a clear role. Multi-layer design technology to achieve flexibility in the choice of at the same time can be upgraded and scalability. Modular design of the system is decomposed into smaller modules directly, a separate analysis, testing and understanding.

Now enterprise applications than in the previous years, it is necessary to support the use of more different types of interfaces, multi-type users, such as online stores need to HMTL Home Web customers for wireless customers XML Home for the system administrator to provide JFC / Swing interface for providers of XML-based Web services (see Figure 4).

Figure 4 Java Pet Store support of the relationship of various types of users

When support for the development of a single type of client application, data access logic can be that control logic and interface logic intertwined. However, to support multiple types of client enterprise systems, it is very troublesome. Therefore:

â—† For each type of client interfaces to the development of different applications;

â—† each application interface code is the non-repetition, in the realization, testing and maintenance required duplication of work;

â—† reproduce the work itself is expensive, because the interface with the non-interface code intertwined;

â—† inevitable duplication of work, it is flawed and slow.

2. Use of models - View - control structure

J2EE applications through the use of models - View - control framework, the core data and data access functionality with the use of these functions separately from the display control logic, as shown in Figure 5. This separation allows more sharing the same view of enterprise data model.

Figure 5 MVC architecture

MVC architecture originated in Smalltalk, the first used in the traditional graphical user interface model mapping input, processing and output tasks. However, it can be directly used in the mapping of the multi-enterprise applications related concepts, the specific concept introduced as follows:

Model (Model), on behalf of corporate data and business rules used to control access and data updates. Model is close to the real world of software services, real-world modeling techniques can be applied model.

View (View), on behalf of the content model. Through access to enterprise data model and assign the data show. View of the state responsible for the changes to the user's data has also changed accordingly. Can be pushed through (Push) model to achieve that view in the model Register for the update instructions, or pull (Pull) model, that is, the view is responsible for the need for the latest data model to be called.

Control (Controller) with the view of the interactive implementation of the model into action. Operate independently in the GUI client, user interaction is the button or menu, and Web application is GET and POST HTTP request. Model implementation of the action including the activation process or change the business processes of the state. And the user interaction model based on the results of action, control by selecting the appropriate function corresponding to complete view.

MVC architecture has the following advantages:

â—† use the same multi-view model. Model and View separation allows enterprises to use the same multi-view model. Therefore, enterprise-level application model components easy to achieve, testing and maintenance.

â—† find it easier to support new types of client. Support for a new type of client, simply write a view and control, and then it connected to the existing enterprise model.

Application of Java Pet Store

View

View is the user interface and application program interface. In the Java Pet Store, view the Web layer. There are three components to achieve View: JSP pages, JSP custom marking and JavaBean. View Part of this involves three elements:

1. Screen

Screen is a page of all of its contents. According needs, ScreenDefinitions.jsp defined in the following screen:

Name: MAIN_SCREEN, DEFAULT_SCREEN Name: CATEGORY_SCREEN Name: SEARCH_SCREEN Name: PRODUCT_SCREEN Name: PRODUCT_DETAILS_SCREEN Name: CART_SCREEN Name: CHECKOUT_SCREEN Name: PLACEORDER_SCREEN Name: COMMIT_ORDER_SCREEN Name: SIGNIN_SCREEN Name: SIGNUP_SCREEN

</ Td> </ tr> </ table>

2. Template

Because for the entire site pages have the same features, such as each page must have Logo, the same elements, such as Banner, a template definition of the different components of pages. Examples of this element in the definition of a template footer.jsp, such as banner.jsp and index.jsp. ScreenDefinitions.jsp defined screen templates include these elements through the include directive contains pages.
â†‘ Back

Tutorial for building J2EE Applications using JBOSS and ECLIPSE -2

Abstract: Tutorial for building J2EE Applications using JBOSS and ECLIPSE -2

Chapter 2.

Overview Of J2EE Technology and Concepts

The Java 2 Enterprise Edition (J2EE) is a multitiered architecture for implementing enterprise-class applications and web based applications. This technology supports a variety of application types from large scale web applications to small client server applications. The main aim of J2EE technology is to create a simple development model for enterprise applications using component based application model. In this model such components use services provided by the container, which would otherwise typically need to be incorporated in application code. Note this may not be ideal in all scenarios: for example , a small scale application might be a better fit for a light-weight Java technology solution (eg Servlets, JSPs, etc).

J2EE Components:

J2EE applications are made up of different components. A J2EE component is a self-contained functional software unit that is assembled into a J2EE application with its helper classes and files and that communicates with other components in the application. The J2EE specification defines the following J2EE components:

Application clients and applets are components that run on the client.

Java Servlet and JavaServer Pages technology components are Web components that run on the web server.

Enterprise JavaBeans components (enterprise beans) are business components that run on the application server.

All these J2EE components are assembled into a J2EE application, verified to be well formed and in compliance with the J2EE specification, and deployed to production, where they are run and managed by the J2EE application server.

In addition to these primary components, it includes standard services and supporting technologies which are:

Java Database Connectivity (JDBC) technology provides access to relational database systems.

Java Transaction API (JTA) or Java Transaction Service (JTS) provides transaction support for J2EE components.

Java Messaging Service (JMS) for asynchronous communication between J2EE components.

Java Naming and Directory Interface (JNDI) provides naming and directory access.

Note: All J2EE components are written in the Java programming language

J2EE Clients:

There are normally two types of J2EE client: a Web client and an Application client as shown above in figure.

A Web client consists of two parts, dynamic Web pages containing various types of markup language (HTML, XML and others), which are generated by Web components running in the Web tier, and a Web browser, which draws the pages received from the server . Another category of web clients are sometimes called as thin client. Thin clients usually do not do things like query databases, and execute complex business rules, or connect to any legacy applications. When we use a thin client, heavyweight operations like these are handled by enterprise beans executing on the J2EE server where they can leverage the security, speed, services, and reliability of J2EE server-side technologies.

A Web page received from the Web tier can include an embedded applet. An applet is a small client application written in the Java programming language that executes in the Java virtual machine installed in the Web browser. However, the client systems will need the Java Plug - in and possibly a security policy file in order to execute applets successfully in the Web browser. Web components are often a preferred API for creating a Web client program because no plug-ins or security policy files are needed on the client systems. Moreover this allows cleaner and more modular application design because they provide a means to separate application logic from Web page design.

An Application client runs on a client machine and provides a way for users to handle tasks that require a richer user interface than can be provided by a markup language. It normally has a graphical user interface (GUI) created using the Swing or Abstract Window Toolkit (AWT) APIs. Application clients directly access enterprise beans running in the business tier. But if there is need for a web client it can open an HTTP connection to establish communication with a servlet running in the Web tier.

Note: If required, and a command line interface can be used.

Web Components:

J2EE Web components can be either servlets or JSP pages. Servlets are Java programming language classes that dynamically process requests and construct responses. JSP pages are text-based documents that execute as servlets but allow a more natural approach to creating static content. HTML pages and applets are bundled with Web components during application assembly, but are not considered Web components by the J2EE specification. Similarly, the server-side utility classes can also be bundled with Web components like HTML pages, but are not considered Web components by the J2EE specification. Shown below in figure is Web components communication.

The Web tier might include a JavaBeans component to manage the user input and send that input to enterprise beans running in the business tier for processing as shown above in the figure ..

Business Components:

Business code, which is logic that solves or meets the needs of a particular business domain such as banking, retail, or finance, is handled by enterprise beans running in the business tier.

The figure above shows communication with business components, where an enterprise bean receives data from client programs, processes it (if necessary), and sends it to the enterprise information system tier for storage. An enterprise bean also retrieves data from storage, and processes it ( if necessary), and sends it back to the client program.

There are three kinds of enterprise beans: session beans (stateless and stateful), the entity beans (bean managed and container managed), and message-driven beans. A session bean represents a transient conversation with a client. When the client finishes executing, the session bean and its data are gone. In contrast, an entity bean represents persistent data stored in one row of a database relation / table. If the client terminates or if the server shuts down, the underlying services ensure that the entity bean data is saved . A message-driven bean combines features of a session bean and a Java Message Service (JMS) message listener, allowing a business component to receive JMS messages asynchronously.

Note: Java Beans are not considered J2EE components by the J2EE specification as JavaBeans are different from Enterprise Beans. JavaBeans component architecture can be used in both server and client tiers to manage the communication between an application client or applet and components running on the J2EE server or between server components and a database, whereas Enterprise JavaBeans components are only used in the business tier as a part of the server tier. JavaBeans have instance variables and has an accessor and mutator methods to access properties of bean or say, accessing the data in the instance variables which simplifies the design and implementation of JavaBeans components.

Enterprise Information System Tier:

The enterprise information system tier handles enterprise information system software and includes enterprise infrastructure systems such as enterprise resource planning (ERP), the mainframe transaction processing, database systems, and other legacy information systems. J2EE application components might need access to enterprise information systems for database connectivity .

J2EE Containers:

J2EE containers provide access to the underlying services of the J2EE Server environment via containers for different types of components. Traditionally, application developers have to write code for handling transaction, state management, multithreading, resource pooling etc. Now the J2EE container provides these services allowing you to concentrate on solving business problems.

Containers are the interface between a component and the low-level platform-specific functionality that supports the component. For example, before a Web, enterprise bean, or application client component can be executed, it must be assembled into a J2EE application and deployed into its container.

The assembly process involves specifying container settings for each component in the J2EE application and for the J2EE application itself. Container settings customize the underlying support provided by the J2EE server, which includes services such as Java Naming and Directory Interface, security, transaction management etc.

The J2EE server provides Enterprise JavaBeans (EJB) and Web containers. EJB container manages the execution of enterprise beans for J2EE applications, whereas Web container manages the execution of JSP page and servlet components for J2EE applications. Other than these two containers there are an Application client container and Applet container, which are not part of J2EE server as these reside on the client's machine as shown below.

An Application client container manages the execution of application client components whereas an Applet container manages the execution of applets. These are typically the JRE (Java Runtime Environment) and a Java-enabled Web browser respectively.

Packaging:

In order to deploy a J2EE application, after developing different components, it is packaged into special archive files that contain the relevant class files and XML deployment descriptors. These XML deployment descriptors contain information specific to each bundled component and are a mechanism for configuring application behavior at assembly or deployment time. These are bundled into different archive types for different component types.

Web components are archived in Web Archive (. War) file which contains servlets, JSP and static components such as HTML and image files. The. War file contains classes and files used in web tier along with a Web component deployment descriptor.

Business components are archived in Java Archive (. Jar) file which contains an EJB deployment descriptor, remote, and object interface files along with helper files required by EJB component.

Client side class files and deployment descriptors are archived in Java Archive (. Jar) file which make up the client application.

J2EE application is bundled in an Enterprise Archive (. Ear) file which contains the whole application along with deployment descriptor that provides information about the application and its assembled components.

J2EE Platform Roles:

Building the different components of a J2EE application involves various roles in the development, deployment and management of an enterprise application.

The application component provider develops the reusable components of J2EE application, which can be Web components, enterprise beans, applets, or application clients for use in J2EE applications.

The application assembler takes all building blocks from the application component provider and combines them into J2EE applications.

The deployer is responsible for the installation / deployment of components in a J2EE environment or J2EE server.

The system administrator is responsible for configuration and administration of computing systems in an enterprise.

The tool provider is a vendor used to develop, package and deploy J2EE applications.

Note: All these above mentioned roles can be assigned to a person or an organization.

Distributed Architecture in J2EE:

All the J2EE applications implement a distributed architecture. In this an object is associated with a name, where names are provided by naming service, by advertising to various components and resolving client references to these service components as shown in figure below.

As a result of that, and object references are obtained, by looking up for an object by its advertised name, once found, reference is obtained, and then carry out the necessary operations on that object using the host's services. A remote object advertises its availability with the name service using a logical name and the name service translates the name to the physical location of the object in the J2EE environment. Once the client request obtains a reference to a remote component, it can send requests to the remote component. The runtime system system handles the distributed communication between the remote objects, which includes serialization and deserialization of parameters.

Note: Various naming services used in distributed systems are RMI (for Java-only implementations), CORBA naming services, LDAP, DNS, NIS. The JBOSS application server uses RMI as its naming service.

Serialization and Deserialization are the same as marshalling and unmarshalling for those familiar with RPC terminology.

Java Naming Directory Interface (JNDI) Architecture:

J2EE uses the JNDI API to generically access naming and directory services using Java technology. The JNDI API resides between application and a naming service and makes the underlying naming service implementation transparent to application components.

A client can look up references to EJB components and other resources in a naming service as mentioned above. The client code remains unchanged, regardless of what naming service is used or what technology it is based on, as this doesn't make any difference to clients locating remote objects via the JNDI API.

â†‘ Back

Poor structures j2ee development platform _ eclipse3.01 and Jboss3.25 a good event, with its first profit

Abstract: poor structures j2ee development platform _ eclipse3.01 and Jboss3.25 a good event, with its first profit

When the Internet portal read many of the j2ee development platform structures of the article, it is not to do their own problems and that is the problem. Impossible, the official handbook watching others do!
First, good to the event, its first profit for the tools needed to:
The sun jdk (http://java.sun.com)
Eclipse (http://www.eclipse.org)
Lomboz3.01 (http://download.us.forge.objectweb.org/lomboz/lomboz.301.zip)
Jboss3.2.5 (http://unc.dl.sourceforge.net/sourceforge/jboss/jboss-3.2.5.zip)
You can go to its home page (http://www.jboss.org), (preferably with 3.1 x or previous versions, because no high lomboz3.01 server version of the document, configuration relatively trouble, I here to find a jboss325.server).
Second, a thousand miles begins with a single step and proceeded to install the above download these tools:
1, the installation jdk (Personal recommend installation of the path not have space to avoid future use of other tools such as weblogic when there are problems) I was installed in the d: / java/jdk1.5.0
2, the installation eclipse directly extract, you need all the components to extract the corresponding directory (3.01 packets have been Chinese for that e Douzhao trouble, a friend read the help file).
3, decompression lomboz3.01 to eclipse / plugins
4, disc decompression jboss3.25 to d, d: / jboss-3.2.5 (which was itself) to / bin under click run.bat start, opening http://localhost:8080 test.
5, activated eclipse, if it is found that after entering the icon lomboz, ok. Has found himself once again into lomboz (will not repeat them here).
In the window - to customize - shortcuts - submenus - new, you can choose to lomboz j2ee wizards selected works as well as facilitate the creation of some modules:

6, open windows - for the first option - selected lomboz, the jdk tools jar path set absolute path (I was here) D: \ Java \ jdk1.5.0 \ lib \ tools.jar Figure:

Here, we set up the way the path to new projects, the above figure click to expand java - Construction of the project, to the right of the source input file folders and input into "folders" model, this created a new project we can be / bin and / src respectively at the two folders of documents and compiled source code. Figure:

7, launched lomboz - server definitions, select server typys for jboss3.2.5 (Before this should jboss325.server copied to eclipse \ plugins \ com.objectlearn.jdt.j2ee_3.0.1 \ servers under)
Jboss325.server
<table Height=100 cellSpacing=0 cellPadding=0 width=100 border=1> <tr> <td>
Name = "JBOSS 3.2.5"
EjbModules = "true"
WebModules = "true"
EarModules = "true">

Label = "Application Server Directory:"
Type = "directory"
Default = "D: / jboss-3.2.5" />

Label = "Address:"
Type = "string"
Default = "127.0.0.1" />

Label = "Port:"
Type = "string"
Default = "8080" />

Label = "Server Configuration (minimal / default / all):"
Type = "string"
Default = "default" />

Label = "Classpath Variable Name:"
Type = "string"
Default = "JBOSS325" />

Label = "Classpath Variable:"
Type = "directory"
Default = "D: / jboss-3.2.5" />
$ () ServerRootDirectory
ServerRootDirectory $ () / server / $ (serverConfig) / deploy
ServerRootDirectory $ () / server / $ (serverConfig) / deploy
ServerRootDirectory $ () / server / $ (serverConfig) / deploy
Org.jnp.interfaces.NamingContextFactory
Jnp ://${ serverAddress): 1099
Org.jboss.Main
ServerRootDirectory $ () / bin

- C) $ (serverConfig
Org.jboss.Shutdown
ServerRootDirectory $ () / bin

- S

JDK_TOOLS
ClassPathVariableName $ () / bin / run.jar
ClassPathVariableName $ () / bin / shutdown.jar
ClassPathVariableName $ () / client/jboss-j2ee.jar
ClassPathVariableName $ () / lib / concurrent.jar
ClassPathVariableName $ () / lib / jboss-system.jar
ClassPathVariableName $ () / lib/dom4j.jar
ClassPathVariableName $ () / lib / xercesImpl.jar
ClassPathVariableName $ () / lib / xml-apis.jar
ClassPathVariableName $ () / lib / gnu-regexp.jar
ClassPathVariableName $ () / lib / getopt.jar
ClassPathVariableName $ () / server / $ (serverConfig) / deploy/jbossweb-tomcat50.sar/servlet-api.jar
ClassPathVariableName $ () / server / $ () serverConfig / lib / bcel.jar
ClassPathVariableName $ () / server / $ () serverConfig / lib / jboss.jar
ClassPathVariableName $ () / server / $ () serverConfig / lib / jboss-transaction.jar
ClassPathVariableName $ () / server / $ () serverConfig / lib / jnpserver.jar
ClassPathVariableName $ () / server / $ () serverConfig / lib / jpl-pattern.jar
ClassPathVariableName $ () / server / $ () serverConfig / lib / jpl-util.jar

ClassPathVariableName $ () / client/jboss-j2ee.jar
ClassPathVariableName $ () / client / jboss-client.jar
ClassPathVariableName $ () / client / jboss-common-client.jar
ClassPathVariableName $ () / client / jboss-jaas.jar
ClassPathVariableName $ () / client / jbosssx-client.jar
ClassPathVariableName $ () / client / jnet.jar
ClassPathVariableName $ () / client / jnp-client.jar
ClassPathVariableName $ () / client/log4j.jar
ClassPathVariableName $ () / server / default / lib / jnpserver.jar

JDK_TOOLS
ClassPathVariableName $ () / bin / run.jar
ClassPathVariableName $ () / bin / shutdown.jar
ClassPathVariableName $ () / client/jboss-j2ee.jar
ClassPathVariableName $ () / lib / concurrent.jar
ClassPathVariableName $ () / lib / jboss-system.jar
ClassPathVariableName $ () / server / $ (serverConfig) / deploy/jbossweb-tomcat50.sar/servlet-api.jar
ClassPathVariableName $ () / server / $ () serverConfig / lib / bcel.jar
ClassPathVariableName $ () / server / $ () serverConfig / lib / jboss.jar
ClassPathVariableName $ () / server / $ () serverConfig / lib / jboss-transaction.jar
ClassPathVariableName $ () / server / $ () serverConfig / lib / jnpserver.jar
ClassPathVariableName $ () / server / $ () serverConfig / lib / jpl-pattern.jar
ClassPathVariableName $ () / server / $ () serverConfig / lib / jpl-util.jar

</ Td> </ tr> </ table>
Figure jboss settings,

8, click on "Application." Identified.
Ok, in theory, we now have a platform to build j2ee well. Below we will carry out "hello world" test.

â†‘ Back

keep looking »

Great articles for Java and JEE

Main Menu

Categories

Recently Written

Search

Archives

Blogroll

Meta

Chapter 6.

Creating a CMP Entity Bean

Tasks:

Create Items CMP Entity Bean:

Implement ejbCreate Method:

Add Finder Method:

Add Business Methods:

Add Callback Method

Deploy Item Bean:

Add a Business Method to StoreAccess:

Create your Test Client:

Test your Client:

Exercise:

Chapter 7.

Creating a Message Driven Bean

Tasks:

Create RequestItems MDB Bean:

Create Immutable Value Object RequestItem:

Implement onMessage Method:

Deploy RequestItems Bean:

Create Test Client:

Test your Client:

Exercise:

Chapter 4.

Creating a Stateful Session Bean

Tasks:

Create Stateless Bean:

Create DAO Interface:

Add Business Method:

Add Callback Methods:

Implement DAO Interface:

Deploy Bean:

Create your Test Client:

Test your Client:

Chapter 5.

Creating a BMP Entity Bean

Tasks:

Create the Customer BMP Entity Bean:

Create Customer's DAO Interface:

Add Finder Methods:

Add Business Methods:

Implement Customer's DAO Interface:

Deploy Customer Bean:

Add Create Method in StoreAccess:

Add Business Method in StoreAccess:

Create your Test Client:

Test your Client:

Exercise:

Chapter 2.

Overview Of J2EE Technology and Concepts

J2EE Components:

J2EE Clients:

Web Components:

Business Components:

J2EE Containers:

Packaging:

J2EE Platform Roles:

Distributed Architecture in J2EE:

Java Naming Directory Interface (JNDI) Architecture: