CORM alpha 02 release!

Mea Culpa time.

It's been a long time coming. There's no denying that the CORM project has not been healthy or active in the last year. But two weeks ago a couple of important things changed. First, I finished setting up my development server with SVN running on it, so I can do software development for Open Source or proprietary code with the same setup. This has been a great development, and it literally triggered an explosion of activity on the CORM project. I've been able to add Catharine to the project as a fully-fledged commiter, and with her help I cranked out a MAJOR upgrade to the old CORM codebase.

After two days of solid development, I'm happy to have released the corm-product and corm-money packages, and de-facto support for corm-quantity by way of the JScience.org 4.3.1 distribution.

JAR files, Source code, and full distributions including API documentation can be found at the CORM Downloads page.

Major Developments

New Developers

CORM welcomes the addition of Catharine Tierney, our newest developer (and first developer who isn't me!).

Interface Free

After some consideration, we decided to return to a non-interface-centric implementation of the data objects. The CORM project strives to create a purely passive data storage model for commercial applications, so why use interfaces? They needlessly complicate the O/R mappings later on, and don't abstract any logical implementation. So we got rid of them. Thanks to Roger Mori and Dain Sundstrom for their feedback on this front.

Quantity Archetype Pattern

With the adoption of JScience.org, we now have a full de-facto implementation of the Quantity Archetype Pattern that is not only more well developed than the rest of our archetype patterns, its the JSR-275 reference implementation for measurement standards in Java! This discovery kicked off a whirlwind of development over the weekend, and led to the quick development of the Money and Product archetype patterns.

Product Archetype Pattern

The alpha-02 release includes our first stab at the Product Archetype Pattern, though there are very important changes from the Arlow-Neustadt architecture. Most importantly, we integrated with the JScience.org 4.3.1 libraries, and made ProductType a type of Quantity, and ProductInstance a type of Unit. This allows us to write code like the following:

   ProductType goldType = new ProductType();
   goldType.setName("gold");
   ProductInstance gold = new ProductInstance(goldType);
   Amount goldAmount = Amount.valueOf(100, gold);

We'll return to this later in the Money Archetype Pattern, as it really simplifies payments and gives us powerful means to treat products in a very similar manner to money. This in turn opens up the basis for highly complex barter and trade systems!

We also separated references to Price from the ProductInstance objects, in order to allow inversion of control. Prices should be governed by rules and complex interaction with the environment. Especially in this age of high inflation, there's no reason for a product instance to have a concept of its own price. So, we inverted control and separated those concerns. Our new price model is very robust and also integrates with the JScience.org economics model.

Money Archetype Pattern

In line with our new addition of the Product Archetype Pattern, we are also very proud to provide a full implementation of the Money Archetype Pattern. Our money pattern breaks with Arlow-Neustadt in that we have abandoned the portions of the pattern which should be implemented in a rule engine, and in that we take full advantage of the JScience.org economics API. This, along with the use of Java generics and careful integration with our Product Archetype Pattern, lets us specify Payments of different types. You can get a Payment or a Payment, and be discriminating about what methods of payment you accept.

100% Unit Test Coverage

With the exception of one method in ProductInstance, we have (as always) 100% unit test coverage. These tests serve both as documentation and as example code for how our trickier parts of the model work. A great example is with PaymentMethod--we added the ability to distinguish between payment in money and payment in goods or other measurable quantities. Examples of how to use this are all in the unit tests.

Looking Ahead

Immediate future plans involve making every archetype implement serializable, and I will also be looking into publishing JPA bindings for all three archetype patterns, as well as bindings for JScience.org. There is also presently no support for conversion of product instances, but this has been a pretty good release cycle.