Java Architecture Rambings

Grails Portal Part II

2010-07-12T21:43:00.000-07:00

This article is the second in a series of three that describes a simple way to build a working framework for a user portal. This framework is built upon some very popular features in Grails and provides many examples of Grails plug-in integration and use of some of the more complex features of Grails such as Grails Webflow. This post describes concepts that a novice Grails developer may find challenging.

In this second post, a step-by-step approach will show how to construct a simple Grails-based workflow and integrate it with the Grails portal code created in the previous post. There are two parts to this post: the first one outlines the creation of the workflow; and the second shows how to use the results of the workflows in a business case.

By the end of this post the reader will be familiar with the issues around creating Grails Webflows and should be able to implement the workflow features of a Grails portal application. I have not included all of the classes referenced in the code examples in the text of this post, but they are located at the Google Code project for the Grails Portal : http://code.google.com/p/grailsportal/

Why use a workflow engine such as Grails Webflow?

Most web applications collect information in a stepwise fashion and then make business rule decisions based upon the data collected to accomplish some business functionality. This is a common requirement in any application, from a simple contact page to a commercial order management system. These types of requirements have been fulfilled in the past in many different ways.

When these applications were written in a green-screen (mainframe) environment, it was easy to handle the interactions between the user and the application. In those days, the user could not switch or close the application window (if there was a window) without indicating what to do with the data that was recorded. The modern web user interface makes managing these kinds of applications much more challenging because of these complexities:

· Workflow termination/re-entry:

This is the process by which the user determines the state that they would like to terminate the workflow. At any time a user can do any number of things to exit the workflow including but not limited to:

o Closing the Browser window
o Selecting the “Cancel” button
o Hitting the “Back” browser navigation button.
o Hitting the “Refresh” browser button
o Selecting the “Finish” button on the final state of the workflow.
o Using re-entrant workflow processing

· Workflow state:
This issues centers around the persistence of the state of the workflow throughout the “life” of the workflow. As the user progresses through the workflow there should never be a perception that the data associated with the workflow will not be saved. If the user purposefully exits the workflow, the user should also be allowed the option to save the data.

· Workflow implementation complexity:
Typically, using workflow frameworks are tedious and counterintuitive. Implementing flows with other frameworks included a combination of XML configuration files, visual representations, and tools that center around code generation.

Grails Webflow is a workflow based feature that gives the developer the tools to mitigate these issues:

· It uses the well known Spring Web-Flow framework to manage the workflow.
This framework handles the persistence of the workflow state and manages the issues when the refresh and back buttons are hit by the user during a workflow “session.” Combined with the Grails portal, it can also deliver targeted work flows based upon the user’s session state by recognizing specific values stored in the user’s web session.

· Its convention-based paradigm of Groovy simplifies the development process to implement the flows in a concise, understandable manner.

Flows are created in a manner consistent with other Grails development. No special tags are needed in the GSPs. Convention based development is used to connect the navigation on the workflow page to the workflow controller.

· Its native Grails domain classes make it simple to save the result of the workflow.
As in all other Grails development that accomplishes persistence of data, creating the code that saves and validates data is a chore but not as complex as in other Java-based frameworks.

What does the workflow do for the Grails portal?

Workflow for the Grails portal is one the fundamental user-based set of features that are used to write interactive web applications (apps that require users to log in and then provide individualized functionality). Workflow in a Grails portal is part of the launching pad for implementing functionality in a Grails portal. In Part I of this article, the setup of the project, domain objects, and security classes were created. In this article, the example will be further explained by demonstrating how to use Grails to manage appointments and create wizard pages to schedule appointments for the fictional wellness company “Wellness Unlimited.”

Grails Webflow definition

There are many types of workflow processes that exist, but it should be known that not all business flows lend themselves to being defined using Grails Webflow. There are three basic types of workflow:

1. Human-based workflow
This type of workflow is based upon the recording of activities strictly done by a human being where the intervals between recordings are extended and are not immediately ongoing. This can be, for example, the recording of a task such as a set of tests. Grails Webflow does not by default implement this type of workflow very well because it does not have the ability to re-constitute a workflow once the workflow session has been interrupted due to inactivity. It might be possible to implement this, but this is for future releases.

2. Computer-based workflow
This instance is where Grails Webflow shines. As in most web applications implemented using Grails Webflow, the intention is to collect data and guide the user between screens in one “flow session.” Typically, this works well for web applications where the workflow is completely computer based with no requirements to handle human based workflow.

3. Mixed workflow (computer and human)
A combination of the first two types, this hybrid workflow concept is a common reality when designing web applications. Grails Webflow can also implement this situation with a combination of traditional Grails web development and “linked” flows. In this case, the steps in the computer-based workflow steps are grouped together, and the human-based workflow is recorded separately from it.

The Grails portal example outlined in this article is an example of mixed workflow.
Planning is essential for success when defining a flow within a Grails application and all business processes can be distilled down to a basic set of steps. Whether you use a napkin or a formal diagram to document them, it is essential that you understand the required steps needed to implement the business process in your Grails application.

In Grails Webflow, you take each of the steps and create a Groovy closure to capture the functionality. If you follow the normal process of GSP and Spring MVC web application development, you will find there are some slight adjustments required to enable webflows to work. Also, you will see that in this example I have not enabled any dynamic run-time functionality; perhaps in a future article I will show how to accomplish this. In the example of the registration controller, each of the steps for the business process of registration is implemented by using standard procedures described in the Grails documentation for this product.

These procedures can be thought of as a roadmap for success. To start with here is a shortcut to understanding Grails Webflow development:

1. The name of the flow is described by adding the “Flow” word to the end of a closure in your controller.

2. When you create the views, you must use the same name as the webflow as a directory that contains the views for the webflow.

3. The views are contained in the named directory from the previous item.

4. Navigating between the webflows is pretty simple:

a. The “name” property of the submit button for the pages in the flow indicates which closure to execute when the page is submitted.
b. If the user navigates away from the flow, it is possible to re-establish the flow.
c. Once the user ends the flow by hitting cancel, you have the ability to manage the data within the flow.

5. Use the “flow” variable to store information for the span of a flow. This is a very important detail: without the flow variable you don’t have the ability to define the activity within a flow. I would recommend that you always use the flow variable when moving state within the flow.

6. The default context in a view used for a webflow uses the “flow” variable. Unless you have worked extensively with Grails you might not understand the concept of a set of domain objects that are put into the context, but the flow variable is a default variable put into the session context.

7. In your controller you should always have explicit entry points and exit points from the webflow. This can be implemented by creating a default closure that will be used by the webflow.
8. When designing your flow, account for the ability to cancel the flow at any time. Placing a “cancel” button at each point in the process is a good idea.
Implementing the flow in the Grails controller

Saving the results of the flow at each step is important, at least in my example. The domain object validation utility methods and GORM methods within Grails are used to save the data for each step in the flow. When writing the code in the main controller for the flow, these are the steps that are always followed:

1. Always use a service class when handling GORM objects. Either create a Grails service class or identify one that you will use to handle the saving of the data from the flow. For the example there are two service classes ContactUtilService and RegistrationService that are used explicitly for this purpose.

2. Create a method to move the data from the posted web parameters to the domain objects. This process can vary widely in complexity. One of the easiest ways to do this is to have the names of the items on the view the same as the ones in your domain class. If you do this you can just instantiate the class using the parms variable–it can be that simple!

3. Create a custom Java Exception class similar to ValidationException. Make sure that you have a try, catch block around the call to catch a validation error.

4. Write a method in service class to validate the domain object. If there is an error, throw a custom validation error that will show to the user the field that needs to be changed.

5. Handle the exception. If there is an exception, make sure the appropriate values are set in the view, and return the model.

6. If there is no exception, create the model objects needed and move the flow to the next page.
An Example of a flow in the Grails portal
In the example for this article, we save the result of each stage of the webflow via calls to service classes. The objective is to employ as much of the default functionality provided by Grails as possible. In the example below from the RegistrationController, the flow definition for collecting the data for the Wellness Unlimited registration is shown.

class RegistrationController{
…
…
registrationFlow{
def registrationService
…
…
enterRegistrantInfo{
on(GOTOPARENTINFO){
try{
flow.regEvent = this.registrationService.doRegistrationEvent(flow.regEvent,params)
if (flow.regEvent.parent1==null){
flow.regEvent.parent1=new RegistrationParent()
}
return success()
}catch(ValidationException e){
flash.message = "Please re-enter your information"
flow.registerInstance = e.getExceptionVal()
return error()
}
}.to ENTERPARENTINFO
on(GOTOCANCEL){
session.regEventId=null;
flash.message="Cancelled"
}.to CANCEL
}
…
}
Listing 1: The enterRegistrantInfo flow step

In this code snippet from the RegistrationController you see the call to the method registrationService.doRegistrationEvent() . There are some subtle but highly significant implementation details in this snippet of Groovy code:

a. Note that the reference to the service always uses a “this” reference. The instance variables at the class level must be referenced this way since the flow is part of a closure.

b. The custom exception ValidationException implements validation using the same patterns established by generated Grails scaffolding controllers and gsp files:

i. Setting the flash.message which shows this message at the top of the page.

ii. Setting the flash.registerInstance variable from exception, which is then used to generically
show the specific fields that need to be changed by marking them red.
Of course the visual representations of the error handling and validation can be replaced as they are accomplished using style sheets and images.

c. Both successful and unsuccessful calls to doRegistrationEvent enable a model necessary to render a view.

i. Make sure that when you return a view that you have the submitted values present in your flash scoped variable. This is important because there is nothing more unsettling for a user than an error where the page is returned–minus some of the originally submitted values.

ii. The approach that I recommend is to have the same flow variable used in each of the flow steps. This will lower the complexity, and allow you to carry the data from previous steps forward without having to re-query that database at each step.

Validation and persistence using Grails service classes

As you see in Listing 2, which is a code snippet from the RegistrationService class, throwing and catching exceptions as part of a flow is one of the many ways to use the default functionality of Grails and Java. When the exception is thrown, it’s most likely because of a validation error on the data that is entered. As you can see in the code below, the validate()method is executed which tests against the constraints specified in the domain class. For example, if a field does not have a value when it should (null) it will put the value into an errors() method on the domain object (RegistrationEvent) which is processed by the default functionality present in a GSP page that has been generated.

Grails service classes are somewhat unique in that they are the defined place within Grails development where database transactions through GORM are handled without much special work. Other methods in controller classes can do the same work, but in these classes much of the configuration for persistence is already done for you. In the doRegistrationEvent method you see an implementation of the instructions earlier in this article by:

1. Using GORM Validation for the domain objects
2. Keeping one single domain object (RegistrationEvent) that is used to return to the controller.

Class RegistrationService{
….
…
def RegistrationEvent doRegistrationEvent(RegistrationEvent regEvent,
params)throws ValidationException{
if (regEvent==null){
regEvent=new RegistrationEvent()
}
try{
regEvent.registrationAge=new Integer(params.registrantAge)
}catch(Exception e){
regEvent.registrationAge = 0
}
regEvent.registrationGrade=params.registrationGrade
regEvent.registrationDate=new Date()
def pt=PartyType.findByCd(CHILD)
regEvent.registrationFor=doParty(pt,"",regEvent.registrationFor,params)
SimpleDateFormat format=new SimpleDateFormat(DATEFORMAT)
regEvent.registrationFor.birthDate = format.parse(params.birthDate_year+
"-"+params.birthDate_month+
"-"+params.birthDate_day)
if (!regEvent.registrationFor.validate()){
throw new ValidationException(regEvent.registrationFor)
}
regEvent.registrationFor.save()
regEvent.registrationUser=this.securityService.getRegisteredUser()
if(!regEvent.validate()){
throw new ValidationException(regEvent)
}
regEvent.save()
return regEvent
}
…
…
}
Listing 2: doRegistrationEvent method in the registration service

Grails portal and web browser navigation

Another detail in this code snippet worth discussing is how the services class is controlling null objects which are a result of Web browser navigation. This is apparent consistently in the example above and all other service methods. Using a domain object to pass between the view, controller, and service layers creates situations where the flow will move back a step. If this happens, the user should see the data that they entered previously and when they submit an update, the service classes should seamlessly handle new objects as well as updates.

The Grails service part of the solution is partially apparent in Listing 2, which employs a simple solution to the problem. In the Grails portal example, the domain object regEvent of type RegistrationEvent is the object stored in the flow scope for the life of the flow. To process a change in this domain object, the regEvent object is passed in, regardless of whether the object has been instantiated or not. If it is null then it comes from a situation where the user has not yet created a registration in that flow. If the object is not null then it implies that the object already exists and we use the existing object. This is crucial because in each of these cases the returned object is the one that is used in the controller and then passed back to the view as the model.

Use of domain class configuration

In the example of Listing 3–which shows the RegistrationEvent domain class–configuration heavily influences the behavior of the Grails Portal. This is because the way that the domain objects are configured implies that it’s also the way that the objects are validated. Since this is how all objects in the Grails portal are validated from each step in the flow, it is essential to understand the issues around Grails domain model constraints, relationships, and mappings.
For conciseness, and the fact that all of the explanations for these options are available on the Grails wiki, only the significant behaviors that affect the Grails portal and may be useful for anyone modifying the code are included for this article.

· Grails constraints

o nullable: A simple concept that can really be an issue if set incorrectly. This indicates to the validation routine and the database creation scripts that this column should have a value (false), or it is OK for it to be false (true). Validation will fail if the constraint is set to “false” and the instance variable of the domain object does not have a value.

o inList: A restriction constraint that will check for these values when validation is run against this domain object.

· Grails mappings

o lazy: This is set to false for this domain class since this is the root object for the Wellness Unlimited registrations, and when a RegistrationEvent is retrieved from the database, it should return all referenced objects. By default, Grails sets this value to “true” for all GORM relationships.

import java.sql.Timestamp
class RegistrationEvent implements Serializable{
Party registrationFor
Date registrationDate
String registrationGrade
Integer registrationAge
EmergencyContact emergencyContact1
EmergencyContact emergencyContact2
EmergencyContact emergencyContact3
RegistrationParent parent1
RegistrationParent parent2
PickupContact pickupContact1
PickupContact pickupContact2
PickupContact pickupContact3
OrderRecord orderRecord
JsecUser registrationUser
RegistrationDoctor registrationDoctor
static constraints = {
registrationFor(nullable:false)
registrationUser(nullable:false)
registrationDate(nullable:true)
registrationGrade(inList:["Kindergarten",
"First",
"Second","Third",
"Fourth",
"Fifth","Sixth",
"Seventh",
"Eighth","Freshman",
"Sophomore",
"Junior","Senior"])
registrationAge(range:5..19)
emergencyContact1(nullable:true)
emergencyContact2(nullable:true)
emergencyContact3(nullable:true)
parent1(nullable:true)
parent2(nullable:true)
pickupContact1(nullable:true)
pickupContact2(nullable:true)
pickupContact3(nullable:true)
orderRecord(nullable:true)
registrationDoctor(nullable:true)
}
static mapping={
parent1 lazy:false
parent2 lazy:false
emergencyContact1 lazy:false
emergencyContect2 lazy:false
emergencyContact3 lazy:false
pickupContact1 lazy:false
pickupContact2 lazy:false
pickupContact3 lazy:false
orderRecord lazy:false
}
String toString() {
return registrationFor.firstName+" "+registrationFor.lastName
}
}
Listing 3: The RegistrationEvent domain class

Use of views in the Grails portal

Views have four main facets that, when combined, create what the user sees on the page represented by the GSP.

1. HTML notation
2. Grails tags
3. References to data available in different contexts
4. The GSP page template (not shown in this example)

The Grails portal employs a domain-based framework that takes advantage of the default scaffolding behavior of Grails. In Listing 4 the and tags are used to handle the situation when the regEvent object does not have a value. This happens the first time that the form is rendered for that webflow. Also, this set of code will show the errors at the top and outline the field with red when the first name field is not filled in.

In this post, each of the application layers of the Grails portal in respect to flow development has been detailed. From the view, controller, service layer and the domain, each contain a part of the puzzle to create an effective flow for a Grails portal. You should note that the files contain a full working and coded example of this functionality with these concepts fully employed.
The next and last installation of the Grails portal series will take the working application and apply management and user interface features such as Ajax to the foundation that has already been built. In addition, the process of deploying the Grails portal application into an existing Tomcat server environment will be covered.

Grails Portal Part I

2010-03-08T09:34:00.000-08:00

This article is the first in a series of three that describes a simple way to build a working framework for a user portal. This framework is built upon some very popular features in Grails and provides many examples of how to integrate popular plug-ins such as JSecurity. This article describes concepts that a novice Grails developer may find challenging.

In the first article, a step-by-step approach will show how to construct the architecture and creating a skeleton set of pages that will be used in articles two and three. By the end of this article the reader will be familiar with using basic Grails concepts to form the basis of a Grails-based portal application. Not all of the classes referenced in the code examples in the text of this article have been included.
Why a Grails Portal?

I have spent many years creating web applications that allow users to authenticate, and then be permitted access to specific features. This does not imply that I have not used formal “portal” technologies, but most small web applications don’t merit being created within a jsr-168/286 portal environment. Typically, most developers need a quick way to allow users to self-register and authenticate, and then manage the authorization of the user to specific functionality.

Grails poses a very interesting choice for these kinds of applications, first because of its convention- based development model and second, its ability to incorporate new functionality quickly. Basic features of Grails such as GSP templates, Grails Object Relational Mapping (GORM), and Web-Flow enable portal functionality to be quickly implemented.
What can a Grails Portal do?

A Grails portal is the fundamental user-based set of features that are used to write interactive web applications (apps that require users to log in and then provide individualized functionality.) A Grails portal can be a launching pad for implementing a web framework that creates and implementation that differs based on role and user. In this article, I will demonstrate how to use Grails to create a simple portal for the fictional wellness company “Wellness Unlimited.” The portal will execute wizards to help users schedule appointments, report health issues, permit self-registration, receive specialized content through email, and allow them to sign up for web-based services.

To accomplish this, our web application combines the user security features of JSecurity with a custom database schema that extends the simple database model provided by JSecurity. Our application also extends functionality to manage users. These customizations are combined with default scaffolding enabled through Grails Web Flow and GORM.
What you will need to do the examples for this article

1. A downloaded and working Grails environment

2. A database source such as MySQL
Grails Portal Project definition

The classes that are used to describe the Wellness Unlimited functionality are an example of a generic web application. The abstractions used are applicable for most web applications that involve common business processes such as recording transactions, scheduling and purchasing. They can also be used in other non-economic functions such as list and catalog management. In these business domains, the organization presents website data to the user and then allows user interaction and records the selections made by the user. Once the user has entered the information, an administrator or business user should be presented with the data for further processing. In order to do this in Grails, domain classes, a framework like GORM, and a view technology like GSP are necessary.

I have written many web applications that use the Spring and Hibernate frameworks and GORM is definitely superior from a usability perspective in getting database-backed web applications to work quickly and properly. The only problem is that if these tools are not configured correctly, they will create bloated applications with inefficient database queries generated by the web application. To prevent this from happening, I have adopted a few practices that facilitate the database and domain-class approach taken in this project.

1. Keep it simple

2. Don’t be afraid to “flatten” the database if it makes it easier; i.e. a generic database is not always best.

3. Use the options in GORM if possible before writing code.

The primary domain objects used to define the application domain for the Wellness Unlimited portal are Party, Order, Product, and RegistrationEvent. A brief description of each follows.
Party

A Party signifies a specific individual that takes part in the system, but a party is not necessarily only a person. It could be a system, individual user, or anything that can be identified by the fields First Name and Last Name. These fields are the mandatory fields on the equivalent domain class. The Party class holds all of the information that composes an individual that participates in the functionality of the portal.
Order

The Order encapsulates the concept of orders and fulfillment. This abstraction is important to the implementation of any selection for action from the website. Orders are executed to establish that something needs to happen. Order line items are created to track the specific products that are selected by the user.
Product

Products exemplify the concept of any item that can be selected by a user from Wellness Unlimited. An example of a product would be something generic like a massage; a product could also be an online user request for a specific type of acupuncture treatment. Products have line items that enable bundling of products into a larger product. An example of a bundled product would be to combine a facial with a pedicure into one item that a user schedules on the Wellness Unlimited website.
Event

Events describe the concept of an occurrence of a business “event.” The recording of different types of business events enable business processes to be recorded along with all of the information associated with the process. The implementation of this portal uses Grails WebFlow to initiate business events and track the progress of these events. Typical events could be:

1. Scheduling of a service such as a massage

2. Purchasing a product

3. Requesting a call back/email for help with a wellness issue
How to create a Grails Portal

The steps are as follow:

1. Create the Grails project

2. Install and configure the JSecurity Plugin

3. Configure the domain classes and GORM

4. Configure the User Management Views
Create the Grails project

The first step in setting up this project is to create a Grails project using grails create-project grailsPortal. This command creates the typical directory structure associated with all Grails projects.
Install and configure the JSecurity Plugin

The second step is to install the JSecurity plugin. The command is: “grails install-plugin jsecurity.” In addition, JSecurity installs the quick-start script to generate the basic user screen, controllers, and domain classes for JSecurity. The next step installs the basic setup for JSecurity. The command “grails quick-start” creates an authController, a view called login.gsp, and six domain classes:

· JsecPermission: holds the permissions and the descriptions of the possible actions that can be applied to the permission

· JsecRole: holds the name of the Role

· JsecRolePermissionRel: holds the relationship between the Role and Permission

· JsecUser: holds the user information (in the beginning only username and password)

· JsecUserPermissionRel: the relationship between the user and permission

· JsecUserRoleRel: the relationship between the JsecUser and the Role

JSecurity is an excellent Grails plugin. It is a generic framework for web application security that is easily extended. At this point the application will work if you use “grails run-app.” It gives you a great starting point but does not finish the work for a user-authenticated application such as a portal.

JSecurity accomplishes user authentication by looking up the user in the JsecUser table and the relationships that the user has in JsecUserRolRel. For this project we will create two role records: one that describes an administration role, and another that describes a user role. In addition we will create two user records: one that describes an administration user (admin); and another that describes a user for the application (guest).

The two user records are associated with the roles by using the JsecUserRoleRel table. As shown in Figure 1, the relationship enables roles to be applied to users.

Figure 1: Party and JSecurity tables ERD

In Part I of this article we will detail how to augment the authorization controller (authController.groovy) to use the “Admin” and “User” role. In the “Creating Default Data” section of this article (part II), I will show how automatically create default roles and users as well as the relationship table when the application is started.

This project augments the default domain classes provided by JSecurity. The default classes are not enough because there needs to be a relationship between these classes and the classes that describe the rest of the application. We accomplish this by adding a reference to the classes that describe the user from a “Wellness Unlimited” point of view. This can be seen in Figure 1 in the JSEC_USER table.
Configure the domain classes and GORM

The Party class is contained in Listing 1. The Party domain class references other domain classes by default such as ContactPhone, ContactEmail, ContactAddress and PartyType. These references establish direct relationships in the database and make it much easier to use the classes at run time. Also, you should notice that there is a one-to-many relationship with the OrderRecord domain class.

class Party implements Serializable{

static mapping = {

orderRecordList column:'partys_id',joinTable:'party_order_record'

partyType column:'party_type_id'

}

String firstName

String middleName

String lastName

String prefix

String suffix

Date birthDate

ContactAddress homeAddress

ContactAddress workAddress

ContactPhone homePhone

ContactPhone workPhone

ContactPhone cellPhone

ContactEmail workEmail

ContactEmail homeEmail

PartyType partyType

static hasMany = [ orderRecordList : OrderRecord ]

static constraints = {

prefix(size:1..20, blank:true,nullable:true)

firstName(size: 1..100, blank: false,nullable:false)

middleName(size:1..50, blank:true,nullable:true)

lastName(size: 1..100, blank: false,nullable:false)

suffix(size:1..20, blank:true,nullable:true)

birthDate(nullable:true)

partyType(nullable:true)

homeAddress(nullable:true)

workAddress(nullable:true)

homePhone(nullable:true)

workPhone(nullable:true)

cellPhone(nullable:true)

workEmail(nullable:true)

homeEmail(nullable:true)

orderRecordList(nullable:true)

}

String toString() {

return firstName+" "+lastName

}

}

Listing 1: Party Domain class

Listing 1 shows that a Party can have many orders. The syntax indicates to Grails GORM that an intermediate table will need to be created that will contain a reference to both the OrderRecord (Listing 2) class and to the Party class. Grails has really improved support recently for many-to-many relationships and one-to-many relationships when generating scaffolding. Our example application does not use many cases of many-to-many relationships, but as support improves it will make it even easier to create more generic systems.

Figure 2: OrderRecord and Inventory Entity Relationship Diagram

The OrderRecord class is contained in Listing 2. This class is the main reference point for when an order is created; the OrderRecordLineItem class (which is in the zip file; see the “Learn more” section) has a reference to an OrderRecord (Listing 2). The Entity Relationship Diagram that represents this data is shown in Figure 2.

class OrderRecord implements Serializable{

static mapping = {

table 'order_record'

grossAmount column:'gross_amount'

orderComment column:'order_comment'

orderDate column:'order_date'

taxAmount column:'tax_amount'

totalAmount column:'total_amount'

orderStatus column:'order_status'

orderRecordType column:'order_record_type_id'

}

String orderNumber

Double grossAmount

String orderComment

Date orderDate

Double taxAmount

Double totalAmount

String orderStatus

OrderRecordType orderRecordType

Party party

static constraints = {

orderNumber(nullable: false)

grossAmount(nullable: false)

orderRecordType(nullable:false)

party(nullable:false)

orderComment(size: 1..1000, blank: false, nullable:true)

orderDate(nullable: false)

taxAmount(nullable: false)

totalAmount(nullable: false)

orderStatus(size: 0..100)

}

String toString() {

return orderNumber

}

}

Listing 2: OrderRecord class

The OrderRecordLineItem has a reference to the Product which is referenced in Listing 3. This configuration is purposely done so Products can be bundled into an order. (The database design to accomplish this is shown in Figure 2.)

class Product implements Serializable{

static mapping = {

table 'product'

cd column:'cd',index: "product_cd_idx", unique: true

dsc column:'dsc'

ecommerceCode column:'ecommerce_code'

name column:'name'

netCostAmount column:'net_cost_amount'

netSalesAmount column:'net_sales_amount'

productImageuripath column:'product_imageuripath'

salesChannel column:'sales_channel_id'

productType column:'product_type_id'

}

String cd

String dsc

String ecommerceCode

String name

Double netCostAmount

Double netSalesAmount

String productImageuripath

SalesChannel salesChannel

ProductType productType

static constraints = {

cd (size: 1..20, blank: false,nullable:false)

dsc (size: 1..200, blank: true,nullable:true)

ecommerceCode (size: 1..100, blank: false,nullable:false)

name (size: 1..100, blank: false)

netCostAmount (nullable: false)

netSalesAmount (nullable: false)

productImageuripath(size: 1..255, blank: true,nullable:true)

salesChannel (nullable:false)

productType (nullable:false)

}

String toString() {

return name

}

}

Listing 3: Product class

The RegistrationEvent is a class (see Listing 4) where registration transactions happen in the portal. One of the requirements is to be able to register patients for weekly Wellness Unlimited classes; this class enables that functionality.

Another interesting point of the domain classes in this application is the toString() method that is implemented. When classes are generated by Grails scaffolding, by default the classes use this method as a representation of the value of the row in the database.

Constraints that are used in the domain classes will have a direct impact on how default scaffolding generates controllers and views. In this application the blank:true and size:x…x+n are commonly used to control how the fields are generated when they are generated through scaffolding.

Constraints also play a large role in the generation of the database classes. The nullable constraint relates directly back to how the domain class is generated into a table in that it makes the column mandatory (not null). The size constraint gives the indication of how large the field will be in the database. The database design for this are of the database is shown in Figure 3.

Figure 3: Registration Event ERD

Another item to note about all of the domain classes is that they all implement the Serializable interface. This is quite important. One of the main features used in the Wellness Essentials portal are wizards that enable the users to schedule appointments, order products, and go through a web-based workflow; to enable this, Grails WebFlow is used. It assumes that all domain classes have this interface implemented because it will attempt to store the state of the flow independent of the database. If you are not familiar with Serializable, you should reference the Sun Java documentation around java.io.Serializable (see the “Learn More” section for details).

import java.sql.Timestamp

class RegistrationEvent implements Serializable{

Party registrationFor

Date registrationDate

EmergencyContact emergencyContact1

EmergencyContact emergencyContact2

EmergencyContact emergencyContact3

OrderRecord orderRecord

JsecUser registrationUser

RegistrationDoctor registrationDoctor

static constraints = {

registrationFor(nullable:false)

registrationUser(nullable:false)

registrationDate(nullable:true)

emergencyContact1(nullable:true)

emergencyContact2(nullable:true)

emergencyContact3(nullable:true)

orderRecord(nullable:true)

registrationDoctor(nullable:true)

}

static mapping={

emergencyContact1 lazy:false

emergencyContect2 lazy:false

emergencyContact3 lazy:false

orderRecord lazy:false

}

String toString() {

return registrationFor.firstName+" "+registrationFor.lastName

}

}

Listing 4: RegistrationEvent class
Configure the User Management Views

After the domain classes are created you can run the Grails application, but it won’t actually do much. In this step we will configure the views and controllers for managing the user login into the Grails Portal. To implement user management features, we must have the ability to separate users into roles. Luckily, JSecurity enables this functionality. In this application I assume that there are two roles, Admin and User (these roles are created by default in the bootstrap.groovy that is available in the zip file; see the “Learn More” section).

A default authController.groovy is created by the initial installation of the JSecurity plug-in. You will need to replace the controller with the contents of Listing 5. The main difference between the original controller and this one is that the original controller only has the code for logging in and logging out and does not provide any code for inserting a user into the database and assigning a role to them.

The additional closures that I have created are register and registerUser. They handle the registration of new users as well as modifying existing user profile information. Another feature of this controller is that most database handling is done using Grails services (wellUnlSecurityService, contactUtilService) which enable the abstraction of database access and manipulation to these classes.

The corresponding views for this controller handle the modification of the user and registration. These are contained on the zip file. In the next installation of this series I will go over how these were created as well as formulating the User Interface (UI).

import org.jsecurity.authc.AuthenticationException

import org.jsecurity.authc.UsernamePasswordToken

import org.jsecurity.SecurityUtils

import com.wellUnl.exception.ValidationException

class AuthController {

def jsecSecurityManager

def wellUnlSecurityService

def contactUtilService

def index = { redirect(action: 'login', params: params) }

def login = {

return [ username: params.username, rememberMe: (params.rememberMe != null), targetUri: params.targetUri ]

}

def register={

JsecUser ju=new JsecUser()

ju.party=new Party()

String theAction="registerUser"

try{

ju=wellUnlSecurityService.getRegisteredUser()

if (ju!=null){

theAction="updateUser"

}

}catch(Exception e){}

return [authInstance:ju,userAction:theAction]

}

def edit={

def ju=wellUnlSecurityService.getRegisteredUser()

render (model:[authInstance:ju],view:'register')

}

def registerUser={

JsecUser.withSession { session ->

log.info("In registerUser")

Party userParty

JsecUser user

JsecUser ju

boolean isValidationError=false

def userName=params.userName

try{

ju=wellUnlSecurityService.getRegisteredUser()

}catch (Exception e){

log.info("Registering a New User")

ju=null;

}

log.info("checking for mandatory fields")

if (userName==null || userName=="" || params.firstName==null || params.firstName=="" || params.lastName==null || params.lastName=="" ||

params.password==null || params.password=="" || params.passwordVerify==null || params.passwordVerify==""){

log.info("no username, first name, last name, password, or password verify entered")

flash.message="We are sorry, you have to enter a user name, First name, Last Name, Password and Verify Password"

render(model:[authInstance:user],view:'register')

isValidationError=true

}

log.info("checking for existing user")

def foundUser=null

if (ju==null){

foundUser=JsecUser.findByUsername(userName)

if (foundUser!=null){

log.info("Trying to register duplicate user -"+userName)

flash.message="We are sorry this user name is already taken, please pick another"

render(model:[authInstance:user],view:'register')

isValidationError=true

session.clear()

}

}

log.info("checking for password verification")

if (params.password!=params.passwordVerify){

log.info("Trying to register passwords do not match -"+userName)

flash.message="We are sorry your passwords do not match, please try again"

render(model:[authInstance:user],view:'register')

isValidationError=true

}

user=contactUtilService.doUser(ju,params)

log.info("user="+user)

log.info("validating data")

try{

user.party=this.contactUtilService.doParty(user.party,params)

}catch(ValidationException ex){

flash.message = "ERROR-09:There was a problem validating the information, please try again"

log.error(ex.exceptionVal.errors)

render(model:[authInstance:user,authErrorInstance:ex.exceptionVal],view:'register')

session.clear()

return

}

if (!isValidationError){

log.info("about to save the user")

def userRole=JsecRole.findByName("User")

try{

user.party.save()

user.save()

new JsecUserRoleRel(user: user, role: userRole).save()

user.save(flush:true)

log.info("successfully saved the user")

}catch(Exception e){

session.clear()

flash.message="ERROR-11: There was a problem saving the User, please try again"

render(model:[authInstance:user],view:'register')

return

}

if (ju==null){

flash.message="User Created You can log in now"

}else{

flash.message="User Profile Updated"

}

if (user.party.id==null){

log.error("registerUser:can not create the user")

flash.message = "ERROR-10:There was a problem saving the User, please try again"

render(model:[authInstance:user],view:'register')

session.clear()

return

}

}else{

log.info("ValidationError-RegisterUser")

session.clear()

render(model:[authInstance:user],view:'register')

}

}

}

def signIn = {

def authToken = new UsernamePasswordToken(params.username, params.password)

// Support for "remember me"

if (params.rememberMe) {

authToken.rememberMe = true

}

try{

// Perform the actual login. An AuthenticationException

// will be thrown if the username is unrecognised or the

// password is incorrect.

this.jsecSecurityManager.login(authToken)

// If a controller redirected to this page, redirect back

// to it. Otherwise redirect to the root URI.

def targetUri = params.targetUri ?: "/"

log.info "Redirecting to '${targetUri}'."

redirect(uri: targetUri)

}

catch (AuthenticationException ex){

// Authentication failed, so display the appropriate message

// on the login page.

log.info "Authentication failure for user '${params.username}'."

flash.message = message(code: "login.failed")

// Keep the username and "remember me" setting so that the

// user doesn't have to enter them again.

def m = [ username: params.username ]

if (params.rememberMe) {

m['rememberMe'] = true

}

// Remember the target URI too.

if (params.targetUri) {

m['targetUri'] = params.targetUri

}

// Now redirect back to the login page.

redirect(action: 'login', params: m)

}

}

def signOut = {

// Log the user out of the application.

SecurityUtils.subject?.logout()

// For now, redirect back to the home page.

redirect(uri: '/')

}

def unauthorized = {

render 'You do not have permission to access this page.'

}

}

Listing 5: authController.groovy

The next installation of the Grails Portal series will show how to build Grails Service classes with GORM and implement the portal user interface. It will also start to explain how to use the Grails WebFlow feature to orchestrate web-based wizards.
Learn More

The files for this article are contained on my website at http://www.webtech20.com/articlel.zip.

JSecurity plugin - http://grails.org/JSecurity+Plugin

Grails Framework Reference Guide - http://grails.org/doc/1.1.x/

Java Serialization - http://java.sun.com/developer/technicalArticles/Programming/serialization/

JSecurity web site - http://cwiki.apache.org/confluence/display/SHIRO/IndexThe Definitive Guide to Grails (second edition) by Graeme Rocher and Jeff Brown ISBN:9781590599952

Enterprise Patterns and MDA: Building Better Software with Achetype Patterns and UML by Jim Arlow, Ila Neustadt Addison Wesley Press ISBN-13: 978-0321112309

Grails and Groovy Blog

2009-08-19T14:55:00.000-07:00

I have found a great Groovy/Grails Blog here since I am meddling in using Grails on the Google App Engine. It seems very interesting.

Grails Portal

2009-08-04T21:31:00.000-07:00

I have been working on a project that will enable Grails to function as a Portal environment. The article for this is on GroovyMag which is a magazine for Groovy/Grails developers. Here is an excerpt from the Abstract:

This article is the first in a series of three that describes a simple way to build a working framework for a user portal. This framework is built upon some very popular features in Grails and provides many examples of how to integrate popular plug-ins such as JSecurity. This article describes concepts that a novice Grails developer may find challenging.

In the first article, a step-by-step approach will show how to construct the architecture and creating a skeleton set of pages that will be used in articles two and three. By the end of this article the reader will be familiar with using basic Grails concepts to form the basis of a Grails-based portal application.

Case Study: Using Grails as a Platform

2009-05-13T07:37:00.000-07:00

A few months ago I started on a new project for a not-for-profit that asked me to create a Portal and registration site for their business. I knew that it was going to be a challenge because Grails is a new web development environment for me, and it is only in it's first release. To my pleasant surprise Grails is now my web development environment of choice.

To implement the portal, I created a set of basic requirements that would follow me through the development process:

Enable users to register for the site
Collect Information from the user
Manage the information and continue a business process as the result

Maven and IVY Dependency Management IV

2008-12-21T09:28:00.000-08:00

What is Maven

In this post I am not explaining how Maven is used, or the artifacts within Maven. These are very well explained in the existing documentation. In this post I will be sharing the experience of using Maven heavily over the past 2 years and comparing it to other tools that are out in the marketplace. This post is valuable to Software developers and Techical Management. It is assumed that the individual reading this post has used Maven previously and knows terminology such as "POM File" and "build."

Maven can be considered to fulfill any or all of these types of products:

Project Management Tool
Maven integrates with a few good project management tools, but one of it's first uses was the ability to generate a set of web pages defining the project. This was very useful when it was used by individuals on Open Source projects because at the time there was no open-source project management tools around that would build these pages by default.
Personally when I first reviewed the first release of Maven I found that it made the use of Maven a tad complex and decided not to use this feature. As it turns out this feature was eclipsed by many of the products that people use today like Blogs and Wikis. The really nice thing about Maven in this area is that it does automatically produce a very nice product page without work beyond putting in the name and purpose of the project.
Project management is key when developing large projects that have many components and many individuals working on it. There are a few project management tools that are available for no cost. Usually you can find these products inside of others such as Trac or Alfresco (which has a content type for programmers), Google Code, and Windows live services. These are all, in my opinion among others a better and more complete alternative to using Maven 2 alone for project management. I have not attempted this but I have heard of teams using configuration management tools to generate the POM files
Build tool for software development.
This is where Maven really shines, and also has some room for improvement.
Maven Shines...
- Maven provides "structure" for Java programmers.
  It gives developers and development groups a standard directory structure that every POM file will understand. This is very powerful because when you go from one Java project to another it can have a completely different set of directory structures and can add a layer of complexity. If you violate these rules, the build system will not work effectively by default from Maven and the programmers will have to understand the details of the build, which should not be a part of their world.
- Maven has been designed to use the "Convention over Configuration" principle.
  This implies that by convention Maven assumes that your projects are setup a certain way and that as software developers add different "Conventions" they will not violate previous ones that have been used. This creates a standard build system that out of the box will build a project from scratch and place it into the Maven repository to be used by other projects.
- Maven is built around the concept of component development and usage.
  Most build systems that are built in Ant rarely allow for the complexity of building 20-30 projects with hundreds of dependencies. Maven allows for this and definitely has the capability to resolve these issues. If you haven't spent many hours trying to figure out why your web application says "cant find method xxxx" then count yourself lucky. This is typically caused when you have two different versions of the same jar file in your Java classpath. This can get ugly when you have 20-30 jar files that you have added to your Java classpath for a project. These issues are not completely resolved by using Maven, but generally they are reduced by the way that Maven tells you that there is a conflict and then gives you the tools to solve the conflict.
- Maven has the ability to look inside of a products' dependencies and if they conflict with another jar file that is already loaded.
  It shows up as conflict within Maven (when you run mvn-install, build, or package). This is important because this solves one of the major "time eaters" in a Java developers work day. These issues are pertinent to many Java architects and senior developers where their main goal is to enable other individuals to work without having to understand or have to think about the details of how the larger project is built.
Maven, of course is not the holy grail when it comes to build systems and has it's problems. These problems are not issues with the design or architecture of Maven, but with the ecosystem that developed around this project:
- Repository issues
  There are too many Maven repositories with the same products, i.e. there are too many places that have differing versions of the same products. It doesn't happen very often but I have found different public repositories that have different versions of the same open source projects. It can be very confusing to find the "latest" out on the public repositories if you don't know the project well.
  Maven repositories are everywhere, and there is one for every product. It seems to me over the past year that the number of repositories with projects have been exploding. In some ways that is a good thing, but when you are trying to find a product that you expect to be out on a common repository, and it isn't there it can be very frustrating. As the Internet is not run by one person or one organization these decisions can't be made anywhere but the community of users. There must be a process by which current versions of projects and new projects are placed onto a common repository. As this is not my area of expertise I will say that it's confusing for the experienced user of Maven and I know people who have stopped using Maven for precisely this reason.
- Confusing documentation
  Although the documentation is great for Maven in comparison to other open source projects, it still doesn't really make it easy to use Maven. The documentation for the most part is written from a completely Java technical perspective, which is fine but now that Maven is maturing and is more heavily used in corporate development better documentation will ease it's integration. Although it is a better product than most of the build managers out there commercial or not, it loses some of it's punch when higher level individuals attempt to read the documentation from the website.

Next Time....

Configuration Management Tool
Interoperability tool for software development

Maven and IVY Dependency Management III

2008-12-19T04:52:00.000-08:00

What is IVY?

Quick Introduction

Ivy is a dependency management system that works within Ant. It uses the same principles as Maven, but it's purposes are much more specialized. It can be used to handle the downloading of resources for development, production, etc. from different repositories that are setup. I have used it previously because I was not familiar with Maven and Ant was an easier option at the time

Why was it created?

As far as I can tell a few years ago there was an awareness that the issues around dependency management and build management in the open source eco-system became known. Many developers who used open-source frameworks were going through a very painful problem when adding a new product to their internal projects. This created a barrier to use open source.

IVY is one of the open-source projects that have the concept of dependency management at it's core. As far as I know, IVY is the only one that worked pretty well with Ant and had examples that were easy to understand. As IVY evolved, it became closer tied to Ant and now it is part of the Apache Ant project.

How is it relevant today?

IVY is very relevant today. Many open source projects don't use Maven and probably won't. Ivy can be bootstrapped into any build system that is using Ant, and developers can reap the benefits of dependency management without having to change their build environment to use Maven. Also, some environments have custom build/configuration management tools that may not be compatible with they way that Maven runs commands, IVY can solve that as well.

Would I recommend IVY

Here are the situations that IVY seems to be better suited for than Maven:

Using a commercial build system that is not compatible with Maven
Only want to use dependency management, and not complexity of Maven
A decision is made that changing all of the configuration management to use Maven would be too costly but still need dependency management.

Build Vs. Buy III - Steps to Analysis

2008-12-18T05:21:00.001-08:00

One of the main reasons why you are doing this analysis is to map the business and/or technical requirements against the product(s) that you are trying to evaluate. The evaluation should be objective, but that is not always possible in every organization. As I have stated previously a good way of handling this is to use 3rd party analysis and compare the products based upon the functionality needed.

Here are the steps that are typically taken during the process of doing a Build Versus Buy analysis:

Do a detailed functional requirements analysis of the needs associated with the product. These are the business drivers for using this product. Make sure that these requirements can be related back directly to a group/individual that is responsible for the outlay of budget for the outcome of the decision.
Do a detailed non-functional requirements analysis of the needs associated with the product. These are sometimes called system requirements or technical requirements. These will need to incorporate issues such as technical infrastructure, support, and personnel.
Create a set of criteria in a spreadsheet that specifies the criteria for each of the vendors that you will be evaluating.
Create a set of weights that will be used for each criteria.
Have the weights and criteria approved by management and if possible publish internally within the organization so that everyone involved will feel empowered by understanding the criteria by which the evaluation will be performed.
Work with each Vendor to get the questions answered.
If questions can't be answered directly by Vendors, you may need to evaluate the product directly to get the questions answered.
As the person administering the build vs. buy exercise you should rate the product(s) and compute a score.
Deliver the answered questions (without your rating) to any other individuals who will have to rate the product.
Collate the ratings and deliver:

A spreadsheet with all of the questions, weights, and ratings.
A powerpoint presentation with explanation of the process and ratings.

Next time: Examples of a build vs. buy

Build Vs. Buy II

2008-12-16T20:59:00.001-08:00

One of the first things that I have always had trouble with during the analysis of any of the build versus buy scenarios is finding free research that can be used, that is not bias to a specific vendor. It is easier now with the Blogs that are out there on the Internet, but you have to be careful anyway. Just because some guy with a professional looking blog has said that this or that application "kicks xxx" it doesn't mean that they aren't being paid by this vendor to do this, or have some other kind of bias that permeates through the IT industry.

To avoid that, sometimes it is best to actually get research directly from the Vendor, and compare what they say. I know that sounds kind of funny but if you look closely to some of these reports you find out what they think their product competes against. Then, typically I will investigate those products to see if they match what I am looking for.

The concept of it is that by looking at what their competitors are you can get a feel for what areas the product is really good in and what it is not good in. An example is Biztalk which I am very familiar with. In the research for Biztalk 6 (in 2006) Microsoft positioned this product as a tool for Mapping and handling XML. When it came to SOA it was not a big player (although it could have been). In all of the research that I did at the time it put itself in competition with other tools that mapped using XSLT instead of a full fledged SOA. The point is that by looking at their research I knew ahead of time not to expect great scores in SOA Governance, rules engine and other SOA based requirements.

There are a few sites that you can goto for pretty good objective reporting on different products. My favorites are listed below:

InfoQ

Java Lobby

The Server Side

Next Time, Purchased Research....

Build Vs. Buy I

2008-12-16T20:58:00.000-08:00

del.icio.us Tags: Java,Build Vs. Buy,Work Experience

What is "Build Vs. Buy"? This is the process that we go through as software architects, developers, technical managers to decide whether it makes sense to build the software in-house or purchase the software off the shelf and integrate it. Here are a few examples of some experiences I have had in this area:

Central Florida Investments, Orlando FL (1992 to 1998)

Over the past 13 years build vs.buy recommendations have been one of the main activities that I have been involved with. The experience that I have originates with my experiences as a lead engineer and Oracle Database Administrator at Central Florida Investments in Orlando, FL. The environment was an Oracle Forms V3 data entry system to maintain customers and enter financial transactions. We evaluated many products to handle pieces of the business, but in the end because of our proprietary systems it was difficult to implement any "out of the box" solutions. These products included many report writing solutions, phone solutions and accounting packages.

The logical solution in today's world would have been an ERP system. At the time they were evaluated and found to not be flexible enough to handle the unique business situations. They were also too expensive for the size of the company. Later on, they did implement Oracle Financials successfully and it made a big impact on their business. They were able to move from 2 resorts to 20 resorts. I have seen this kind of investment pay off big time in many companies over the years.
Sunterra Resorts 1998-2000

The next major build/buy decision I was involved with was when I worked for Sunterra Resorts in Orlando, FL. The package we evaluated at this time was a comprehensive Resort Management System from RCI. This system was evaluated before I came on board, and we started to use it as a basis for a large development project called "Sword." My involvement was analyzing the Technical architecture and guessing how many hours it would take to customize the software for use by Sunterra Resorts.

Many build versus buy decisions were made as part of this situation because of the availability of modules from RCI as well as the availability at the time of off the shelf software that could solve pieces of the business problem. At the time I also headed a small group of software developers responsible for augmenting the system to make it scale.

In this case my evaluation was extensive as we realized that it would take quite a bit work to scale the system because of it's architecture. Many skilled Oracle developers were on our team including many who had worked for Oracle for a period of time. The package was purchased, but as far as I know was never actually deployed to the extent necessary to recoup the cost of development.
Walt Disney Internet Group (2000-2005)

At Walt Disney Internet Group (2000-2004) I was involved with a very large project called "Destination Disney." It was an 8 year project to implement CRM philosophies across Walt Disney World. The World Wide Web really took off in importance for the latter part of this project and because there were no easy ways to get marketing information from disneyworld.com to the back-end systems of Walt Disney World a solution needed to be created that would map from the "Web" world to WDW's back end systems.

We evaluated a few different ETL solutions at the time using Gartner research as a guide. We also looked at the time it would take to write it ourselves. We did an extensive evaluation and eventually selected Informatica. In this process I participated in creating the RFI and RFP as well as attending all evaluations. One other task was creating a scorecard. This scorecard was used to objectively evaluate all of the vendors as they created proof of concepts.

In the next phase of the same project as above we needed to select a J2EE application server. As the architect for this project I created the RFP and RFI as well as creating the scorecards. The evaluation was done on a purely technical basis. This was a difficult selection because the budget was very limited and our requirements very high.
Gentiva Health Services (2005-2007)

At Gentiva Health Services (2006) as the Application Architect for the Application Development Group developing a 35 million dollar project I was responsible for designing all of the Enterprise Services. The build/buy recommendation was for a product that could handle the HIPAA X11 messages over EDI that were coming from our business partners. This product would also need to be part of a general SOA approach. Gartner and Forrester research was used to select the Vendors and establish a basic set of functionality needed in the evaluation. After meeting with the business to match the basic features from the research, I then created the RFP and RFI. I then evaluated all of the responses according to a scorecard that was approved by upper management.

After the results of the scorecard were published I created a presentation to the Director and Vice President who were in charge of Software Development and Infrastructure. This was an invaluable experience because presenting to the Director of Software development and V.P. gave me experience in using the scorecard and instead of being an argument based upon opinion, the scorecard represents an objective view of the product selection.

Next Time ... What are the steps you should take ...

Spring - JBoss Application Properties Integration - 1

2008-12-16T20:50:00.000-08:00

del.icio.us Tags: Spring Framework,JBoss,Java,Properties Integration

Even though there have been so many things written about Spring and JBoss it seems that there really isn't a good discussion around properties. I have been doing web development with JBoss since 2003 and have found that the properties service is invaluable to work with since it really makes it easy to deal with Server based properties that are bound to the system that it is running on.

<attribute name="Properties">
project.filepath=../soap/project.xml
project.service=service
project.portNumber=8888
</attribute>

</mbean>

</server>

If you are curious about the Properties service, there is a properties-service.xml in each deploy directory of your JBoss implementation. This file, if not changed by the user does not contain any properties. When there are properties added to the file they become "Java System properties." The properties are then available to Springs' PropertyPlaceholderConfigurer.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="systemPropertiesMode" value="2"></property>
<property name="location" value="WEB-INF/test.properties"/>
</bean>
<bean id="soapUi" class="com.test.utility.SpringMockServiceRunner" lazy-init="false">
<constructor-arg index="0" value="${project.filepath}" />
<constructor-arg index="2" value="${project.portNumber}"/>
<constructor-arg index="1" value="${project.service}"/>
</bean>
</beans>

More on different options available next time..

Maven and IVY Dependency Management II

2008-10-21T19:50:00.000-07:00

Maven Dependency Management

There have been many blogs written about Maven, and how it can be used. What I really haven't seen is an explanation for how it should be used. I have done quite a bit of reading through many blogs, and found answers to some of my questions.

Most of those questions were answered by reading the documentation provided by Apache. The problem really is knowing how to read the Apache documentation so that it makes sense.

Enables me to find compatibilities/incompatibilities in libraries without having to sweat the details.

Integrates ok with Eclipse Ganymede

Creates an out of the box build system that can compete with anything I can write

Integrates via plugin with any open source build tool imaginable

Maven, IVY and Dependency Management Part 1

2008-10-05T10:19:00.000-07:00

del.icio.us Tags: Maven,Java,Ivy,Dependency Management,Open Source

Introduction

After working with many open source technologies, dependency management has been a tough issue. There are so many frameworks these days that have overlapping functionality so it is very common that the dependencies for these projects are actually very similar, but they do not always work together very well. This problem is especially evident when you are taking two different frameworks that do any sort of Java Byte manipulation (cglib for example).

To solve this very complex problem, among others two Apache projects have been maturing over the past two years that have different approaches but from a dependency management standpoint, similar outcomes. In addition, the maturity of these projects have risen to a point where there is adequate IDE integration.

Apache Maven 2 project
Apache Ant IVY

What is Dependency Management

Dependency Management creates rules by which different frameworks and different projects can be integrated with as little impact as possible. There are many situations where you would like to use a specific feature of a new version of an open source project. You can't just use the project without having to figure out which other open source packages it uses, and what versions. This has been solved by most open source projects by including a "pom" file. This pom file is a set of dependencies that are specified in the file and then relate to other files that are needed. These files have their dependencies, and so on.

Why use Dependency Management?

There are many reasons to use dependency management, as I see it there a few factors:

Large teams have trouble integrating components that are developed separately.
There are many open-source frameworks that when used together have conflicting Java libraries.
It is slowly becoming a standard on open source projects to have a dependency manager download the correct libraries at build time either through IVY or Maven 2.
Dependency management instills a software engineering discipline missing in many projects in the past by specifying what other projects the piece of software is dependent upon.

In this new age of having very short time-lines we as developers try to create software designs that are based upon components that we can bring from either a commercial vendor or an open source project. We then plan on combining those libraries and frameworks with code that we quickly develop in-house to solve the business problem. Part of the issue as a result of this is that we need to know that each off the shelf framework/component that we use will be compatible with other components that are developed in-house.

In the past, small teams were able to create the whole project from the bare-bones including the application server components such as servlet engines. In the past few years each of the pieces that we are responsible to actually write code for as been reduced. For instance just a few years ago I was asked to develop a whole architecture for persisting data to a database so that it would be easy for programmers to request the data from the database. This was before Hibernate and Toplink during the formative years of EJB 1.x and 2.x.

Now, as Java developers we don't have the responsiblity of building these layers as they are provided either by the software Vendor we are using, or using an open source framework such as Hibernate, IBatis, etc. The casualty of building some of these layers yourself is that you have to adapt to the fact that these frameworks have their own dependencies that may conflict with either your own frameworks, the JDK you are using, or even the application server you are deploying to.

Useful Maven Update Sites for common Apps

2008-10-05T10:08:00.000-07:00

After working with Maven for my second project I have definitely found it to be a real asset to a Java project. Combined with the M2 eclipse plugin you really have an environment that can make it easy to develop software. Here are some of the essential plug-ins that I recommend for Eclipse and Maven:

I would recommend the JBOSS IDE but I have not found it to be very stable lately and I'm patiently waiting for the 3.0 release.

Common Maven Commands

2008-10-05T10:02:00.000-07:00

Here are some important Maven commands that I always seem to forget but are needed on many projects that I work on.

I am using this command to create an Eclipse project from a Maven project

mvn eclipse:eclipse

This will download all of the libraries required in your pom.xml and create a default repository for you.

mvn install

This will clean the "target" directory of all files, note that this does not compile your code.

mvn clean