Merry Overactive Christmas!

From this little corner of the world the Overactive Logistics project wishes you a Merry Christmas!
And by the way!!... even though the posts during this month decreased the hard work to make Overactive Logistics a reality is alive and well.

Most of my time has been spent working on the migration to EJB3.0 and doing research on on how to improve the current architecture during this important milestone.

More concrete, the session beans have been ported to the new specification and are now homeless, the entity beans have represented a very nice and smooth challenge. I plan to have the application fully ported and back on track before mid Jan.

Major Overactive Logistics refactoring II (EJB 3.0)

One of the core ideas behind the Overactive Logistics architecture is to stay wide open to innovation and new Java/J2EE technologies, because of this taking the decision to migrate the object model to Hybernate and making the Session Beans regular Facade objects felt a little bit like taking an step backwards.

Since its inception the project was planned on top of EJB technology due to the immediate benefits and services that this platform offers to the developer.

After analyzing more the EJB 3.0 public draft specification and doing some prototyping with JBoss EJB3 implementation I have decided that migrating to EJB 3.0 is the right way to go.

It is my second day porting Overactive Logistics from EJB 2.1 to EJB 3.0 and I must say that I'm completely astonished!.

The EJB 3.0 simplifications are totally awesome, I'm reducing all the code written in a 40% due to the elimination of EJB Home interfaces, deployment descriptors, EJB exceptions and EJB create/remove method calls.

The use of annotations is not a natural act for a developer however it is easy to get used to them once you pass that first shock and start typing them, it feels specially great when you get rid of the deployment descriptors.

JBoss has done a terrific job, it took me less than a few hours to configure my development enviroment for EJB 3.0 and their documentation even though is incomplete is a great help.

Major Overactive Logistics Refactoring.

During the analysis for the shipments module I found that the domain model requires changes that can't be implemented in a clean way without the extensive use of object inheritance and object reusability based on interface implementation. The EJB 2.1 specification states that inheritance is not supported in entity beans. Due the complexity of the current requirements plus the need for greater flexibility during object modeling I have decided to port the domain model to POJOs using Hibernate and port the Session Beans to normal Facade classes.

This will extend my current scope for the release of the first beta version of Overactive Logistics, however it will reduce dramatically the complexity of the system architecture resulting in shorter development cycles as a reward.

Demo released on Source Forge

Today I released the first demo of Overactive Logistics on Source Forge!
This is just a little demo so the users can grab an snapshoot of the work been done so far, there is still a long way to go, however this little sample aims to give a hands on experience with the application. This demo has the following maintenance modules:

-SCAC maintenance
-IATA maintenance
-FMC maintenance
-Carrier maintenace (Air, Land, Ocean)
-Forwarding Agent maintenance
-Ports maintenance
-Schedule D maintenance
-Schedule K maintenance
-Customer maintenance
-Security roles maintenance
-Users maintenance
-Company maintenance

Shipments analysis.

I started doing the analysis and design for the way Overactive Logistics is going to handle shipments. During this phase I found that rates and charges required some little fixes in the carrier, agent and customer modules and worked on them.

I'm hoping to start coding the shipments module this week.

Ready to work on shipments

I finally finished with all my pending tasks. I also updated my development enviroment to the latest versions of MySQL, JDK, Eclipse and JBoss and I'm ready to start working on the shipments module.

Updates.

Well!, I've been going slowly through most of my TODO pending tasks and been able to make a significant progress. Overactive Logistics now has maintenance modules for SCAC, IATA and FMC. Now each one of this codes can be selected from each one of its respective screens.

Finally, I created a little utility that allows me to break the ejb-jar.xml and jbosscmp-jdbc.xml schemas in individual mappings and merge them during deployment time. The advantage of this is that now each schema specification for an Entity Bean is defined in its own file making them easier to maintain.

US Customs and FMC

I finished the US Customs and FMC maintenance modules. Tomorrow I'll move on the FMC dropdown in Ocean Carrier, Company and Forwarding Agent.

Very soon I'll be able to finish Air Carrier.

SCAC and IATA

I'm done with the SCAC and IATA items in my TODO list. Tomorrow I'll move on US Customs and FMC.

TODO List

I'm done with the Overactive Renderer refactoring. Now I was able to put down the TODO list of things that I have to get done before moving to Shipments.

SCAC
-Do a maintenance module for Scac
-Reuse Scac dropdown in Company

IATA
-Do a maintenance module for Iata
-Import Iata codes
-Reuse Iata dropdown in Forwarding Agent
-Reuse Iata dropdown in Company

US Customs
-Reuse US Customs dropdown in Company

FMC
-Do a maintenance module for Fmc
-Import Fmc codes
-Reuse FMC dropdown in Ocean Carrier
-Reuse FMC dropdown in Company
-Reuse FMC dropdown in Forwarding Agent

AIR CARRIER
-Do Airline details

DEV ENVIROMENT
-Migrate to latest JBoss Version
-Migrate to latest Eclipse Version
-Migrate to latest JDK Version
-Migrate to latest MySQL Version
-Integrate xsd into Overactive Renderer Jar file
-Create Entity Beans deployment descriptor merging utility.

Still on refactoring.

The last few days have been very interesting. I found that in order to improve functionality I was in a huge need to get a JInternalFrame compoment with modal capabilities. I found some very nice tips on how to solve this issue at:

http://java.sun.com/developer/JDCTechTips/2001/tt1220.html

I spent most of the Saturday adapting this tip to the current JInternalFrame renderer, once I got it working I started cleaning up all the code that was not required anymore in Overactive Logistics due to this change and was almost done last night.

Since I'm currently focused on the refactoring of the Overactive Renderer I thought it was a good moment to work on porting the current DTD to XSD, before start typing I was lucky enough to find a very nice tool called Oxygen I downloaded it and gave it a try and a few minutes after there it was! The whole DTD ported into an XSD! This really saved me a lot of time and I'll be able to start focusing on the last part of the refactoring which is making the Overactive Renderer elements namespace qualified.

Refactoring progress

The refactoring is moving on. The changes allow to reuse screens in a clean and easy way. The carrier modules share much of the same components and with the new changes I'm able to run both at the same time.

I started planning how the toolbars will be composed, for the moment I added some as a place holders.

Overactive Renderer refactoring.

While working on Agent I realized that some reafactoring is really needed in order to make component reusability cleaner. I was able to promote limited reusability by restricting access to modules that shared the same components as the active one, however components like an scac list could be used in more than four modules at the same time causing this a huge problem.

I did some analisys and came up with some enchancements to the Overactive Renderer. The basic idea is to add a form key that will be passed as an attribute of an xml element (button, panel, etc). This plus the name will give each component in the form a unique key that will allow reusability.

Agent progress.

I was able to persist the first Agent into the db. Tomorrow I'm moving on the rest of the crud stuff.

Agent module.

Moving to agent maintenance module, currently I have created the entity and session beans plus database definitions. Customer and carrier maintenance have been completed in a 90% .

Customer module progress.

The development of the customer maintenance module has been very smooth mainly because the reuse of the address, rates, custom charges and pmt term components as depicted above, I only had to do small refactoring changes to the rates since there was a dependency with carrier. The create, update, and view functions have been completed and tomorrow I'll continue with the delete function.

Customer maintenance on the works.

After a well deserved vacation I'm back on track again. I'm focusing all my efforts on getting the customer maintenance module done. I started creating the required entity beans plus database tables yesterday.

The customer module is very similar to carrier and it makes reuse of the rates and custom charges components previously created so its development should go very fast.

Vacation time!

Ok... this is it!, I'm going on vacation for two weeks starting tomorrow......

Carrier maintenance module progress.

Still working on the carrier maintenance module. Tonight I was able to retreive a carrier from the database and display all its data but its custom charges. Retrieving its rates required a little muscle and a lot of typing however the design patterns used are in place and the code is clean and easy to read. 2 more days left to go on vacation.

Carrier on the works.

Another busy weekend, I'm currently working on finishing the carrier maintenance module. Today I finally got to persist a carrier in the database including its address, billing address, rates and custom charges. My goal is to finish this asap before going on vacations next Saturday, since I'll be offline for 2 weeks.

Busy weekend.

Wow!!... it has been a very very busy but productive weekend. Finally I was able to do a big data retrieval using entity beans and got caught into some problems that my core framework had. It results that my remote session bean controller was retrieving always DOM objects, remote session beans use RMI which in turs uses serialization.... bad mistake! with small retrievals this was always working ok, however now I retrieved a huge DOM made of 2812 database rows and oh! oh!... bugs! It took me a good effort to understand what the problem was and how to come up with the best fix, now the DOM gets serialized into an XML string representation and sent over RMI without problems.

In other news, I made the import of real world scac into the system and now I got to play with real data.

I decided to make some screenshoots of my development enviroment showing the application running in debug mode. This screenshoot shows the application running in web based mode.

This screenshoot shows the application running in standalone mode.

Custom charges done.

The custom charges component is completed. It will be used in carriers, forwarding agents and customers, same as the rates component.

I'm now moving to finish the carrier maintenance module.

Source Forge.

A few months ago I got approval from Source Forge to host my project, however I've been kind of reluctant to publish anything yet since there is still too much work left to do before I can achieve something worth of getting people's attention. In the meantime I'm working on a custom charges component which is quite similar to rates.

Got rates component!

The rates component is now ready to be used and reused!. Before moving to carrier I found a better way to post hidden data within a SwingML form which is using the data-store element.

Before I used to set the desired data in a textfield an hide it, just like it is normally done in HTML. The problem with this is that sometimes the rendering was taking a little bit more time and you could see the the hidden textfield before the rest of the elements were positioned above it.

Using the data-store is cleaner since its value is added to the post transaction and it is not a visual component.

Now I just have to implement this change in the 94 stylesheets that I have written so far :P

Doing some refactoring....

This is how my development enviroment looks like.



















I'm currently working on refactoring a component written for rates in order to make it easy to reuse. This component is currently used in carrier maintenance and will be in customer and agent maintenance too. This effort is a little bit of a challenge since the name of every component in the gui should be unique across the whole application, however the trick can be easly implemented using XSLT.

Overactive Logistics

This is an early screenshoot of Overactive Logistics. Currently I'm coding only the necesary maintenance modules to move later on the development of incoming and outgoing shipments.