NBDTRCPAndJEEBestPractices

NetBeans RCP and JEE Best Practices

Fabrizio Giudici and Wade Chandler

Work in progress

A project to define a set of best practices for using NetBeans RCP and JEE and related technologies. Issue 148573

Contents


Introduction

Many times one needs to prototype the NB RCP to see if it would be a good choice for their project, or someone from the community who is already using RCP would like to use it with another technology from the JEE stack within their application. There are different issues with different approaches, and when it takes too long to make some initial determinations this can have a negative impact on the developers experience, or worse cause them to not use the RCP for their project.

The goal of this project is to help with this in different capacities and scenarios. At a minimum this should attempt to address JEE 5, JPA, Spring, and JEE 1.3 and 1.4 as they are still in heavy use. Other things may be considered, but these makes for a good start.

The project could have chosen to work solely on JEE 5 and Spring technologies, but this would miss the fact that many projects already have existing code, and it would be extremely hard to make the case to add an RCP management interface to a system which already has a management interface designed for the web which already has server side logic and EJBs if all the underlying business logic and EJBs must be replaced. Too, there are different servers which support certain aspects of JEE 5, but only support different subsets of the specifications and not all of them. This means JEE 1.3 or 1.4 must be used.

Simple Yet Modular Example - Notes Manager

This example should deal with a modular design. Most if not all the examples currently in the wiki only show a single EJB module not linked to others and nothing which could lead to possible class loader issues when different EJB interfaces or classes reside in different NB modules. Hopefully, if any exist, they will be flushed out in this project.

The application is very simple. It manages notes which a company may need to keep related to customers or just notes in general. This is generally a common piece within most enterprise applications. Here it is a little simplified just for the purpose of getting it done for use as an example of using enterprise technologies with the NetBeans RCP.

From a birds eye view, or the high level design, the following sub-systems should exist in every system (obviously using different mechanisms at lower levels less RCP modules in general).

  • Log in/Authentication - Depends on the employee module as this is where the user information is actually maintained. A little backwards as normally user records could be maintained separately, though in the end they must be linked to something anyways, so not such a stretch. This could technically go into the Employee module, but just to keep things separated as much as possible we'll make this a separate module; thus it becomes pluggable.
  • Core - Contains notes, people, and application information or settings. Technically notes can exist without being linked to anyone.
  • Employee - contains screens and entities dealing with those things employees will need to do and their information
  • Customer - contains screens and entities dealing with those things dealing with customers

Entities

  1. ApplicationInformation
  • Fields
    1. companyName:string
    2. phone:string
    3. emailAddress:string
    4. address1:string
    5. address2:string
    6. city:string
    7. st:string
    8. zip:string
  1. Note
  • Fields
    1. id:long
    2. creationDate:dateTime
    3. updateDate:dateTime
    4. title:string
    5. note:string
  1. Person
  • Fields
    1. id:long
    2. firstName:string
    3. lastName:string
    4. phone:string
    5. emailAddress:string
    6. address1:string
    7. address2:string
    8. city:string
    9. st:string
    10. zip:string
  1. Employee
  • Fields
    1. id:long
    2. ismanager:boolean
    3. userID:string
    4. password:string
  1. EmployeeNoteLink
  • Fields
    1. id:long
    2. noteID:long
    3. personID:long
  1. Customer
  • Fields
    1. id:long
    2. isperson:boolean
    3. person:Person
    4. phone:string
    5. emailAddress:string
    6. address1:string
    7. address2:string
    8. city:string
    9. st:string
    10. zip:string
    11. contacts:Collection<Person>
  1. CustomerNoteLink
  • Fields
    1. id:long
    2. noteID:long
    3. customerID:long

Here, Note, Person, and ApplicationInfo are to be common classes. These could be placed in a core module or they could be within their own module. We'll just chuck them into a core module. ApplicationInformation just has information for the company managing the application, and as it is a single record entity there is no need for an id necessarily unless required by the underlying technology.

Next, we'll put Employee and EmployeeNoteLink into their own module. An EmployeeNoteLink links an employee to a note. Only Employees will log in.

Then, we'll put Customer and CustomerNoteLink into their own module. CustomerNoteLink links a given note to a customer. These notes are not actually linked directly to a contact however. Contacts are used to keep track of different peoples information so they may be called back. Customers don't actually log in, but are information (contact management).

These will represent the Entity modules which will be used by the backend and front end in different situations. Now, it would go to reason we'll need to extend this example later to use transfer or value objects. The idea with TO or VO objects is they allow faster and smaller data access at a given moment. That will actually provide a better design, but as it is assume different people with different ideas will be using this documentation we should cover different cases, and the Entity level design will allow us to create a standalone application using JPA, Hibernate, and local Spring.

JEE 5

3 client server models should be addressed here. Technically all data objects should remain the same with the calling mechanisms and exposures differing. All will technically use pieces of the JPA project as well.

  • EJB Session Beans remote
  • EJB Message Beans/JMS
  • EJB Session Beans exposed as web services
  • Log in/Authentication - Depends on the employee module as this is where the user information is actually maintained.
  • Core - Contains notes, people, and application information or settings. Technically notes can exist without being linked to anyone.
  • Employee - contains screens and entities dealing with those things employees will need to do and their information
  • Customer - contains screens and entities dealing with those things dealing with customers

Spring

There are multiple ways in which Spring may be used. We'll focus on the following two approaches.

  • Embedded directly within an RCP application. This wouldn't really use a server side or a server side may just be a networked database (see JPA)
  • Client Server Model using Spring remoting. This should demonstrate using the HTTP invokers using Hessian or Burlap and also using JMS; from there it should not be so difficult for someone to convert that into a web services based demonstration.
  • Log in/Authentication - Depends on the employee module as this is where the user information is actually maintained.
  • Core - Contains notes, people, and application information or settings. Technically notes can exist without being linked to anyone.
  • Employee - contains screens and entities dealing with those things employees will need to do and their information
  • Customer - contains screens and entities dealing with those things dealing with customers

JPA

This is essentially a standalone application which could also be distributed using a networked database. Entities using only the JPA will be directly used.

  • Log in/Authentication - Depends on the employee module as this is where the user information is actually maintained.
  • Core - Contains notes, people, and application information or settings. Technically notes can exist without being linked to anyone.
  • Employee - contains screens and entities dealing with those things employees will need to do and their information
  • Customer - contains screens and entities dealing with those things dealing with customers

Hibernate

This is essentially the same thing as the JPA project except for it just uses straight hibernate without necessarily relying on the JPA interface.

  • Log in/Authentication - Depends on the employee module as this is where the user information is actually maintained.
  • Core - Contains notes, people, and application information or settings. Technically notes can exist without being linked to anyone.
  • Employee - contains screens and entities dealing with those things employees will need to do and their information
  • Customer - contains screens and entities dealing with those things dealing with customers

JEE 1.3 and JEE 1.4

As JAX-RPC has been deprecated we'll focus on the ability to use JMS or pure EJB calls and will not attempt to focus on web services as a model of access from these specifications. One good thing about doing this is it should make these essentially the same and possibly a single project with descriptors technically being the only differences. Other differences, if any, will be flushed out as the design evolves. These specifications will be covered last.

  • Log in/Authentication - Depends on the employee module as this is where the user information is actually maintained.
  • Core - Contains notes, people, and application information or settings. Technically notes can exist without being linked to anyone.
  • Employee - contains screens and entities dealing with those things employees will need to do and their information
  • Customer - contains screens and entities dealing with those things dealing with customers

JINI

In the future, a project using JINI services to do more may be created, but the main idea for integrating JINI in this context is for service discovery. The idea is that the server based technologies could run an embedded JINI server which contains services which allow the client side application the ability to detect different servers which users can log in.

Going a step further, possibly, it may be possible to create JINI services which allow the calling mechanism, whether it be EJB session, messaging, web services, Spring remoting, etc, to be completely pluggable as JINI services which allow different classes and code to be downloaded.

Either way, the integration of JINI can allow for really dynamic client server models in enterprise networks. These being models which allow clients to be separate installs or web start launched applications which can discover different servers which they may log in on the network. Obviously this is not a mechanism for general internet deployment and discovery, but none the less very powerful. For internet wide deployments, web start or direct manual configuration per an active role of the user will be best.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo