Cars, Software and Competitiveness

It is often said that software development should be like building cars.

But cars are very different from modern software systems.
Since its invention more that 100 years ago a car is a very stable concept.
This works because the purpose for which it is build (driving on a more or less solid ground) is stable as well.

Software on the other hand needs to be much more flexible because the context changes frequently.
Some examples are markets, organizations, products and the internet.
The concept of software is much more abstract than the concept of a car.

More and more people realize that agility paired with quality is a key success factor.
That’s why a short concept to market cycle is needed.

Automotive is in fact a bad role model. You can see that every day.
The market is demanding for efficient cars with a low carbon footprint.
But the vendors fail to deliver. Why? Because they are too inflexible.

Let us not make the same fault.
In fact the methods and tools are available to establish a fast concept to market cycle.
Some examples are Scrum, Silverlight SketchFlow and Business driven SOA

If the companies have the heart to try those new approaches, they might be with rewarded with competitive advantage and flexibility.

Does Spring dm server help to gain OSGi independence?

Recently when I talked to people or read articles about Spring DM Server it was frequently explained that one reason for using it in favour of plain OSGi is to gain independence from OSGi.
Although Spring DM Server comes with a simple to use POJO-based approach to implement OSGi services, the same can be achieved with OSGi declarative services which is part of the OSGi standard services.
With just one configuration file one can turn a POJO into an OSGi service without any OSGi plumbing. This seems to be often overlooked.

There are other reasons why one would want to use Spring DM server instead of plain OSGi, but achieving independence is clearly not.
Rather the opposite is true. Instead if relying on the widely accepted OSGi industry standard another dependency namely Spring DM server is added.
That is ok if it helps to create a better technical solution, but there is a price to pay.

Biztalk Technology Specialist

I passed the Microsoft Biztalk Server certification (MCTS) with flying colors (985).

An MCTS is:

“A Microsoft Certified Technology Specialist in Microsoft BizTalk Server 2006 (MCTS: BizTalk Server) has a deep and broad understanding of the design and development of distributed applications that use BizTalk Server 2006. The credential holder has also demonstrated expertise in deploying and managing a BizTalk Server 2006 solution and can create a BizTalk orchestration, integrate business rules and human workflow services, manage business processes, troubleshoot BizTalk solutions, and consume and publish Web services.”

I knew that before, but now it is official. 😉

Now I an entitled to deliver the official Biztalk MOC courses (2033 and 2934) in addition to the regular development courses.

How to enable request logging for pax-web-service OSGi bundle

Due to lack of documentation enabling request logging for the pax-web-service OSGi bundle can be time consuming task.
This is how it can be achieved:

1. Create a OSGi fragment bundle using Maven 2 like this: pom.xml
2. Add jetty.xml to src/main/resources directory of your project. Example: jetty.xml
3. Install the bundle into your OSGI environment.

This approach works with pax-web-service-0.6.0.jar and Eclipse Equinox 3.4.0.

Rules, Processes or Services?

Together Services, Business Processes (BPM) and Business Rules (BRM) can be a powerful combination to keep the SOA promise of creating agile business applications.
I often hear questions about how those three can be combined in a reasonable way.
In their article Implementation of business rules and business processes in SOA Boris Lublinsky and Didier Le Tien give some practical advice.