Mike`s Blog

Yippey! Today is the time for celebration: we officially got Instant Messaging at work. Forgotten are the days of using Outlook or network shares to send logfiles, screenshots and snippets back and forth. Also it's really nice to be able to react to messages while hanging on the phone.

We're using Jabber (OpenFire server) and i'd like to integrate the build server.
Thanks, IT Infrastructure team! I owe you

• Comment (1)
• Trackbacks (0)

I'm currently trying to implement JSR-94. I downloaded the TCK (Technology Compatibility Kit) and let it run. For each failing test case, I implemented a bit more of my JSR94 implementation until all the test cases passed. So, right now, all the tests pass but it's still missing a lot. On the road, I found the some things about JSR-94 which could have been done much better by the initial group designing the API.

• Comments (2)
• Trackbacks (0)
• Continue reading "Why is JSR-94 (Java Rule Engine API) ill-designed?"

Meant as a reply to a rather old blog post of Charles Miller about why the Maven 2 concept is broken by design.

Reliability

Consider two pieces of software. One uses maven (and 1–n artifact repositories) to manage its dependencies, the other keeps all its dependencies in source-control. How many potential points of failure are involved in checking out and building each product?

Touché. A project which has all its dependencies stored locally (e.g. in version control) is of course more reliable in regard to the build. However, imagine your project has a "foobar.jar" in the lib/ folder and you have no idea which version that is and whether it's an official version or not. No way to find out. Maven helps here, as it guides people to use official versions or at least do a proper release of a patched library. That's documentation and a good thing.

Repeatability

Maven seems to try as hard as it can to prevent this. Files go missing from public Maven repositories and suddenly a whole swathe of historical versions of open source projects can't be built without hacking. ibiblio reorganises its directory layout and chaos ensues. Imagine what happens in ten years time when maven has been superceded by some new tool, public maven repository maintenance is an afterthought, and you desperately need to patch some legacy Java app?

If we go a few years into the future, this might become a problem though, and I can see that coming. Maven repositories vanishing or being cleaned up, domains out of order, URLs broken etc. I think that, as long as a project is active, this is not a concern. For enterprise projects, this disadvantage can be seen as an advantage though. We're using our own enterprise Maven repository internally. Everything, including external artifacts, is stored there. Building in offline-mode is necessary for repeated builds even after years. So, you're forced to keep all what you need locally, but you can still benefit from the Maven features like dependency management and release process. Certainly there will be efforts to make Maven more .. "aware" of such environments - like storing Maven plugins locally, too, and becoming more stable in regard to release of new Maven plugins (i've seen so many "1.0-ALPHA3" releases of maven artefacts and plugins - that should not happen at all). Eat your own dog food, Maven guys! Make proper releases.

Responsiveness

Tracking down dependencies and sorting out their transitive relationships is a tricky task, but it's a tricky task you only ever have to do when you modify your dependencies. Maven, on the other hand, wants to do this job every time you build, which adds a huge responsiveness overhead, as the "pom" definition files of each dependency must be retrieved and analysed alongside their jars.

I can see the point here. It's just an implementational bug in my eyes. Maven could indeed store the calculated dependencies, e.g. in a separate dependencies.xml. However, I see Maven as it is - a build system. Not a realtime-compile-package-deploy-tool. Building a project should be done solely in the IDE while in development. There should not be any need for tools like m2eclipse in a project anyway. At least, not integrated into the normal "compile my classes" process. Maven is a build system and should be seen as this. Run Maven on your CI server and once in a while (daily) on your developers machine. But don't run it every 5 minutes. If you do, your development environment setup is ill-designed.


There are a lot of repositories out there, and Maven is only one of it and it does the job. Not a perfect one, but sufficiently. All those repositories suffer from the same problems: dependencies, versioning hell, missing tool-support, no plans for the future (after-life) etc.

Take Gentoo for example - they're relying on their package repository and all their clients do so. They don't seem to care about stuff like "Omg, when the Gentoo repository won't be there any more in 5 years, i won't be able to update my production Gentoo Server with all that critical business applications running on it.". They rely on the fact that it will manage itself somehow. If the repository goes out of order, there will be something new and hopefully better so I can still update my machines. Same thing with Maven-based Java Projects or IDE Plugins (Eclipse Plugin HellTM) and any other software system which makes heavy use of the Always-Online-itis.

We should stop using/relying on the internet for software development.

• Comments (0)
• Trackbacks (0)

We're going to bring one of our frameworks - The Dynamic Business Application Framework - to the Java Business Integration (JBI, JSR-208) world.

Today, The Platform provides components, services and core functionality vital to any business application. Based on top of that, The Platform shall become more open for reusability, flexibility and modularity. One of the many topics is to hop onto the Web 2.0 and SOA wagon. Our developers/users will be able to quickly get their dynamic applications created by The Platform connected to any services-oriented architecture and integrate it with existing corporate IT landscapes.

So, while peeking a quick look on the whole JBI topic in general, i found some worrying statements by James Lorenzen:

"I believe the biggest failure of JBI has been communicating clearly what JBI is and how to use it. It took me many months until I felt like I actually "understood" JBI."

"many months" is not exactly what I've planned to invest, just to find out what JBI is and how it works. Actually understanding a technology must occur very quickly. Else, the time lost with investigation may harm the whole project. Being able to quickly adapt and understand new technology is vital to technology-oriented projects/frameworks/people. A business-oriented project may chose whatever technology is already settled. That's plannable and fine for the project. A technology-oriented project needs to be much quicker, as there's no "meat" in the project itself. It only consists of infrastructure.

"With XML being so verbose I believe SM or OESB would probably dislike a 3 MB XML file getting pumped through it."

Someone who "actually understands" JBI and used it for months (and probably years by now) thinks that a 3MB XML will be too large for ServiceMix or OpenESB? I wonder what the implementors of those JBI containers were thinking of what we (the users) are going to put through JBI. I mean, come on, i'm going to send data and lot's of it. I'm sure that "Hello World" works well, but did you guys ever thought about that HelloWorld is only the start and if they wanted us to really do business with it that we would stick with small data sets? Business is about data. Payload - and really lot's of it.

"I remember the first video I watched when the light bulb finally went off. It was a video on how to use the Sun SMTP BC and creating a Service Assembly with Netbeans. After I watched that video everything just came together for me and my co-workers."

That sounds like a good hint. I'll try to find that video about Sun Simple Mail Transfer Protocol Binding Component (i expanded the abbreviations on purpose).

• Comments (0)
• Trackbacks (0)

At the very same time as the financial crisis 2008 is happening, I've been working on software development projects in the credit risk rating area. As one of the developers of the Credit Risk Rating Platform, my goal is to give our customers (the banks) the ability to manage credit risks and the ability to quickly adapt to changes in the rating calculation. Our customers want to be able to change the logic how ratings are calculated. And they want to be able to do that on their own and very quickly.

Formerly they all used a bunch of proprietary pieces, put together into ugly Excel sheets and Visual Basic spaghetti code. This looks fine in the books and every business guy can do it or at least change some formulas in there. However, lots of different Excel documents with lots of sheets and lots of colors and lots of different mathematical and statistical functions and lots of macro code and lots of cycling dependencies between cells ... well, you get the point. It just becomes plain unmanageable and chaotic. ("Which LGD excel sheet was used for customer X? I cannot find the latest version on the network drive...")

"The Platform" let's customers change the way the software behaves after it has been rolled out. "The Platform" is the core of our Credit Risk Rating Platform. With The Dynamic Business Application Platform, any new logic can be brought into the application by the customer without the need for a software developer to change a single line of code. (Of course, this only applies to the core application. The systems usually are solutions with additional features which are not based on the DBAF.)

Experts like financial analysts can now model how the program should calculate. They do it visually, transparently and well-documented with tool support. What has once been deeply hidden somewhere in a formula cell near the end of some Excel sheet is now visually describable, versioned, documented and tested. And it looks much better. Compare for yourself, how the two concepts look like:

Before: (with Excel)



After: (with Visual Rules)



The graphics do not show the exact same, i just wanted show how they're conceptually different. For example the Excel formula G10:=NORMSINV(B10); will probably be very similar in Visual Rules, something along the lines of DefaultThresold[10] := normsInverse(ProbabilityOfDefault[10]);.

One of the advantages is that the formula can now be expressed with more meaningful names, it can be described (the name of the blue assignment note is "Calculate PD" instead of "C10" in Excel) and documented. And you can see loops and decisions directly in the visual model. This is really good and helps to navigate quickly in complex rating models, even after months and years. Just think of the times where you have looked at some Excel formulas after years and wondered: "Did I write this garbage?! I don't remember what $G$I is and how the heck this all works. It'll take weeks to understand it again."

• Comments (0)
• Trackbacks (0)