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: 

  1.   Create a CMP bean named Items under package au.com.tusc.cmp. 

  2.   Implement the ejbCreate method, with the values of all attributes being passed as arguments and then assigned to the attributes using mutator (setter) methods. 

  3.   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)" 

  4.   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 ()" 

  5.   Add a business method to get item details with the signature: 

      Public ItemData getItemData () 

  6.   Add another business method to register delivery of items with the signature: 

      Public void fillStock (java.lang.Integer quantity) 

  7.   Add callback methods, required for getting / setting bean context for bean with signatures: 

      Public void setEntityContext (EntityContext ctx) 

      Public void unsetEntityContext () 

  8.   Deploy the Item Bean. 

  9.   Add a field to the StoreAccess bean to store the Item reference (obtained from JNDI lookup): 

      Private ItemLocalHome itemLocalHome 

  10.   In the ejbCreate method of the StoreAccess bean store this reference in the itemLocalHome variable by invoking the getLocalHome static method in ItemUtil. 

  11.   Add a business method to StoreAccess Bean with the signature: 

      Public ItemData getItemData (String itemID) 

  12.   Add another business method to StoreAccess Bean with the signature: 

      Public java.util.ArrayList getOutOfStockItems () 

  13.   Add another business method to StoreAccess Bean with the signature: 

      Public java.util.ArrayList getItemBySupplier (String supplierID) 

  14.   Create a test client named SessionCMPClient under package au.com.tusc.client. 

  15.   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. 

  1.   @ Ejb.bean tag provides information about the EJB. It is the one compulsory tag for all EJBs. 

  2.   @ 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. 

  3.   @ 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. 

  4.   @ Ejb.persistence-field method level tag is being deprecated in favour of@ejb.persistence tag, it provided information about persistent fields. 

  5.   @ 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: 

  1.   Create a CMP Bean named Supplier under package au.com.tusc.cmp. 

  2.   Implement the ejbCreate method, with all attributes passed as arguments and then assigned to attributes using mutator methods. 

  3.   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. 

  4.   Add a business method to get supplier details with signature: 

      Public SupplierData getSupplierData () 

  5.   Add a business method to get request items from various suppliers with signature: 

      Public void requestItem (String itemID, Integer quantity) 

  6.   Add callback methods, required for setting / unsetting bean context with signatures: 

      Public void setEntityContext (EntityContext ctx) 

      Public void unsetEntityContext () 

  7.   Deploy the Supplier Bean. 

  8.   Add a field to StoreAcess Bean to store its reference: 

      Private SupplierLocalHome supplierLocalHome 

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

  1.   Add a business method to StoreAccess Bean with signature: 

      Public ItemData getItemData (String itemID) 

  2.   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" 

  1.   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: 

  1.   Create a MD bean named RequestItems under package au.com.tusc.mdb. 

  2.   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 

  3.   Implement the onMessage method. 

  4.   Deploy the RequestItems Bean. 

  5.   Create your test client named RequestMDBClient under package au.com.tusc.mdb. 

  6.   Add a method named testMDBBean with the following signature and implement it. 

      Public void testMDBBean 

  7.   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: 

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

  2.   Create the Initial context reference. 

  3.   Create the Connection factory reference. 

  4.   Use this context to perform the lookup, where the lookup string is "queue / MdbQueue." 

  5.   Create the QueueConnection. 

  6.   Create the QueueSender. 

  7.   Create the QueueSession for the bean. 

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

  9.   Send the message. 

  10.   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. 

  1.   Create an MD Bean named DeliverItems under the package au.com.tusc.mdb. 

  2.   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 

  3.   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 ());) 

  4.   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" 

  1.   Deploy your DeliverItems Bean. 

  2.   Create a test client named DeliverMDBClient under the package au.com.tusc.mdb. 

  3.   Add a method named testMDBBean with the following signature. 

      Public void testMDBBean 

  4.   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. 

  1.   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: 

  1.   Create a Stateful Session Bean named StoreAccessState. 

  2.   Add a business method in the bean named loginUser with the signature 

      Public String loginUser (String username, String password) 

  3.   Add a call back method ejbCreate with the signature 

      Public void ejbCreate (String userID) 

  4.   Generate the DAO interface. 

  5.   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) 

  6.   Deploy the StoreAccessState bean. 

  7.   Create your test client named SessionStateClient under package au.com.tusc.client. 

  8.   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. 



  <table CellSpacing=4 cellPadding=3 width="100%" border=0>    <thEAD> <tr VAlign=top> <td width="70%"> 

  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). 

  <table CellSpacing=0 cellPadding=4 width="100%" border=0>    <thEAD> <tr VAlign=top> <td width="52%"> 

  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: 

  1.   Create a BMP bean named Customer under package au.com.tusc.bmp. 

  2.   Create a DAO class named CustomerDAOImpl under package au.com.tusc.dao. 

  3.   Add all attributes / properties to the CustomerBean, with getter and setter methods for each of the attributes. 

  4.   Add a finder method named ejbFindByPrimaryKey with the signature 

      Public CustomerPK ejbFindByPrimaryKey (CustomerPK pk) throws FinderException 

  5.   Add a finder method named ejbFindByUserID with the signature 

      Public CustomerPK ejbFindByUserID (String userID) throws FinderException 

  6.   Add a business method named getCustomerData with the signature 

      Public CustomerData getCustomerData () 

  7.   Implement required methods in the CustomerDAOImpl class. 

  8.   Deploy the Customer Bean. 

  9.   Add a create method to the StoreAccess Bean. 

      Public void ejbCreate () throws javax.ejb.CreateException 

  10.   Add a business method to the StoreAccess Bean. 

      Public CustomerData getCustomerData (String userID) 

  11.   Create a test client named SessionBMPClient under package au.com.tusc.client. 

  12.   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.