Saturday, December 20, 2008

[Pub] Mule IDE

I published an article about the new Mule IDE in the current issue of the Eclipse Magazin. In the article I give an overview about Mule and how the IDE supports developers to model their Mule applications. The IDE provides the following features:
  • Mule project wizard
  • Mule runtime configuration (you can define different Mule runtimes)
  • Graphical Mule Configuration Editor
  • Start your Mule Server from your IDE
More information about the Mule IDE you can find on the Mule IDE homepage.

Friday, December 19, 2008

[Arch] Application Architecture Guide

The architecture and design of software applications should be technical neutral. The Application Architecture Guide from Microsoft guides developers through the design of applicataions based on the .NET platform. In my opinion, this architecture guide not only focus on the .NET platform and is a really good cookbook for Software Architects. As we present in our Best Practice Project, design patterns, are technical neutral and can be used in any language. The design principles of a Data Access Object or a Proxy are the same in Java as in .NET.

The guide can be used as a reference and provides the following five parts: Fundamentals, Design, Layers, Quality Attributes and Archetypes - Desgin and Patterns.

Fundamentals

The first part focus on fundamental architecture concepts, including application Archetypes, Layers and Tiers and Architectural Styles. On chapter focus on the .NET platform.

Design

The second part is very interesting for software analysts by providing some guidelines to design your application. Here you will find best practice approaches to make decisions about the distribution, select the right application type, choose the right architectural style (component based, message-bus,...). The chapter Architecture and Design is on of the most interesting one, because it provides guidelines to design considerations, architecture frame, persistence, security and some other topics. The last chapter Communication guidelines provides best practice approches to use the right communication between your software components and describes the design impact of choosing a communication technology.

Layers

The layers part focus on the layered architecture and describes each layer in detail, including Presentation, Business, Data Access and Service Layer. The layered architecture is on of the common used architecture styles in software projects.

Quality Attributes
In this part non functional requirements in software projects are described and how these requrements can be achieved by doing the right design. What must be account for to be secure and performant.

Archetypes - Design and Patterns

Don't compare this chapter with Maven Archetypes. The last part of the architecture guide describes different types of applictions, like Mobile Application, RIA or Web Application. This is very interesting because you will find which typical design principles and design patterns are used in such an archetype. For example one of the key patterns in Web Applications are Composite View, Front Controller, the classical MVC, Page Cahge or the page controller.

This architecture acts as Bibel for developers and you fill find less .NET code. In my opinion this guide is realy good and should be checked by every software architect and analyst.

Thursday, December 18, 2008

[Misc] Virtualisation for Software-Engineering

The easy accissible virtualisation tools like Virtual Box enable new applications in software engineering. An obvious usage pattern would be, to provide prepared systems for customers to evaluate that would require rather complex installations and setups.

Not so apparent is the usage in automated testing. Tests of higher granularity like integration tests are sometimes difficult to automate as they often require (again), complex installations of several components (database, middleware, legacy components...), setup of these components plus a consistent state of all these components. Virtualisation can facilitate that process significantly. The developers can create a consistent image of the system where all dependent systems are properly installed, configured and fed with data.

This image is used as reference. In the build and test automation one has to get the clean image, start it, install the more "dynamic" modules, i.e. the system under development and test, and execute the (integration) tests in the virtualisation, then collect the test results and shutdown the virtual system again. That procedure allows deterministic test-scenarios on different machines, also (or particularly) on a continuous integration server.

Sounds good, however in practice I am still missing some tools that support that. Linux in the box is of course a good start as everything is easily scriptable. However, if you want to include the virtualisation into the build-automation (e.g. in Maven) and into the continuous integration server, plugins to Maven/Ant... would be useful that allow to control the virtualisation environment, trigger activities there and retrieve data (e.g. the test-results).

In an initial research I did not find much tools in that area, any ideas?

Tuesday, December 09, 2008

[Misc] Glassfish

I recently informed myself about the (Sun) Glassfish J2EE server. I never took it as a serious competitor in the field, as I had the impression it is just a reference implementation that is from Sun... However, I had to change my opinion. In the recent years it seems, that the Glassfish community worked hard on their baby and currently it seems to be a solid competitor in the field.

The Glassfish univers "not only" contains a J2EE server, but actually a set of Enterprise-tools like as message broker, clustering framework, enterprise service bus (JBI compatible), a library to implement SIP applications and the like. Additionally it is well supported by the Netbeans IDE. The recent (preview) version contains a J2EE runtime that additionally supports scripting languages like Ruby and Groovy and is based on the OSGi framework.

What I do like additionally is the fact, that Glassfish comes with a decent installation tool, provides a solid web-based administration interface and seems to be reasonably well documented. And, of course, the whole stuff is Open Source.

I must say, I am quite impressed so far. Any comments on that one?

Friday, December 05, 2008

[Misc] Mule Developer Blog

There is now a new blog which takes his focus only on Mule, by providing technical tips, comments and breaking news around the Mule product line (ESB, Mule Galaxy,..). Blogger from this blog are only developers from Mule Source and members of the Mule Service Team, which means that you get the information from first hand. There are already posts, e.g. how to write custom transformers in Mule or an introduction to Expression transformers. Another interesting post focus on performance tuning in Mule.

The backround idea behind this blog is to give the Mule community as much information as possible. This is the right way, because there are some issues (e.g. performance issues) where you always end up in the mailing list and search some hours for the right answer. Some posts are emerge from discussion threads in the user mailing list.

Monday, December 01, 2008

[Arch] Archi-Zack!-ture

A few months ago I read a very good article series by Pavlo Baron about Software Architecture in the Java Magazin. Software architecture is an important component in software projects and you will find a lot of resources (books, web sites, blogs) which focus on this topic. He titled the series with Archi-Zack!-ture.

What does a Software Architect do? The role of a software architect in a software product becomes more important the more complex the system is. Software architecture is still a rather young discipline and the value of a software architect in software development is often underrated. As Pavlo describes in the first part, it's hard to seperate the role of a software architect with the role of a software developer. The architect enables developers to develop the software system by providing the necessary environment. The developer on the other side focuses on the fulfillment of the requirements. The motives are the same, but the emphasis differs.

The major part of the series are (Anti-) patterns about the software architecture. I picked up the most important one from my point of view. First I will enumerate the patterns which should be followed:
  • Architect also implements
    Each architect should also implement. This is very important, because as a architect you make decisions about performance, scalability and similar stuff. Without any technical backround these issues are very hard to design/answer.
  • Senior Developer = Software Architect
    It is important the a software architect has experience in software development.
  • Manages makes the final decision
    One man of the management must make the final decision. The software architect prepares the material which are used for the decision
Now some antipatterns
  • Ivory-Twoer Architect:
    The purchase to the reality lost
  • One Man Show:
    The software architect makes everything alone
  • Single point of decision:
    The software architect must decide everything, e.g. implementation details.
  • Design by Committee:
    On the other side, it makes no sense to make all decisions in the team which ends in a never ending discussion. A good mixture is the answer.
  • Architecture by implication:
    Architecture is not documented.
  • Architecture without review:
  • Meta architecture:
    Software architect remains too abstract
  • Customers are idiots:
    The Software architect is not a God!!
  • No Refactoring:
    The management does not give time for refactoring
Some people believe that software architects are the "kings", and without them software projects don't work. The above mentioned anti patterns are found rather often in projects and architects should keep that in mind. It is not important which title is written on your business card, the content, the attitude to the project and how the project team works toghether, are the keys to the success of the project.