[Arch] Mock Objects

I stumbled over this article yesterday: A neat and short description of Mock objects and a motivation how Mock objects in general and Mocking frameworks can support (unit) testing particularly with classes that have dependencies. I like this very short introduction because the concept of Mock-objects is actually not so difficult to understand but the need for Mock-frameworks is not so easy to grasp.

If the basic idea is understood the documentation of frameworks like JMock can kick in and do the rest ;-)

Addition: Thanks to the comment of reader Touku who recommended the article from Martin Fowler: Mocks Aren't Stubs.

[Misc] Puppet and Puppetmaster

I am back from Indonesia, and what could be a more worthy topic to write as first blog after the travel? Exactly: Puppet. In Indonesia I listened to the IT Conversations talk with Luke Kanies about his project. Puppet is an open source system-administration framework for Unix-based operating systems. I believe, that puppet shows quite some innovations not easily to be found in other tools and has the potential to be the next step in system administration.

First: the target audience of puppet are system administrators and/or developers that have to roll out and administrate a potential large number of server and client (!) systems. Everyone who has to administrate more than two machines know that doing that manually is for sure not an entertaining business. Now what I believe is puppets strongest idea is, to define an abstraction layer over system administration:

Puppet allowes to define the behaviour of machines in an abstract way by using a language to describe classes of configurations; as in object-oriented languages inheritence is possible. The usual tasks of a sysadmin can be written in the puppet language. More important, puppet tries to abstract from OS details, so it does not matter for ordinary activities like configuring an Apache webserver whether the target OS is Linux, Solaris or BSD. To abstract from concrete resources puppet uses so called resources: a good example are users. As we know, they can be defined and managed in different ways on different platforms and contexts. Puppets resources hence deal with concepts like user, file, cron and so on on different operating systems in the same way.

Essentially puppet can be seen as the missing next step after virtualisation solutions: a virtualisation describes the hardware requirements of a machine, puppet describes the operating system and services requirements. So ideally you define the specifications of your machine (needs Apache Webserver, mysql... version...) and then execute that on the very machine using puppet. If you need a second machine with the same configuration, just reuse the configuration from the first (puppet calls that repeatable configurations).

Puppet is also a tool in the sense, that a so called "puppet-master" can communicate with puppet clients. These clients are under control of the puppet master.

Configurations are idempotent, this means, you do not need to assume a specific context or status on the machine to run a configuration "script". You can simply start a configuration on a specific machine and the configuration definition with puppet brings the machine into the desired state. Actually puppet executed these configurations on a regular interval to keep the machine in the desired state.

As far as I understand puppet so far, it is the next level of system administration (as mentioned above, particularly also in combination with virtualisation) allowing to manage also complex infrastructure. There are apparently already a number of companies and institutions using puppet on a larger scale. Luke Kanies mentiones in his talk that also Google is using puppet so administrate several thousand machines (apparently partly MacOS) but also many other international companies.

Puppet written in Ruby and is provided as Open Source framework, however, one thing that worries me a little bit at the moment is the fact, that there is currently no big community behind puppet. Puppet is the "baby" from Reductive Labs and there essentially from Luke Kanies and I believe few further developers. What I have heard from this project so far is really impressive, and I hope that the project attracts more developers soon and Reductive Labs is open minded enough to open the development to outsiders.

[Pub] JBPM meets ESB

The combination of a process engine and an Enterprise Service Bus (ESB) is one interesting aspect of modern service oriented architectures (SOA). Both, an ESB and process engines provide similar concepts and software architects often have problems to find the right solution. Therefor I and Bernd Rücker wrote an article in the German Java Magazin about it. To have a practical showcase the integration is shown with a small example using JBoss jBPM and two Open Source ESBs: JBoss ESB and Mule.

The easy showcase implements the following example: Some event is generated and saved as a file (This may be an order, some incident, an alert, whatever). This file is picked up by the ESB and a new jbpm process is started. The process contains a human task, where somebody has to review the data of the event and decides, if that event can be ignored (e.g. a false alert) or if it has to be handled. In the latter case, the event is sent to an existing case management system via Web Service (could be Lotus Notes or something like that). The case management systems sends a JMS message as soon as the case is closed. This message is again picked up by the ESB and the right process instance is triggered (called "signaled" in jBPM).

The article covers the following topics:

• The basic combination of a process engine and an ESB
• When makes it sense to combine a process engine with an ESB
• How does JBoss ESB integrate jbpm and which Event Handler the proces designer can use to call ESB services
• How does Mule integrate jbpm and which Event Handlers does Mule provide for the process designer
• Lessons Learned :)
  

To compare the ESB implementatations the show case was implemented with JBoss ESB available here and Mule, available here. Following the links, you will find a detailed description about the two implementation scenarios.

[Misc] (Open Source) Developers and Marketing

In the recent IT-Conversations Steve Yegge from Google talks about developers and their attitude towards marketing. I would say, that many stories he tells are more or less well known, however, I think he raises an issue: the relation between development and marketing (in the "business world") or even more problematic: in Open Source projects.

This starts with project-naming and includes license issues (which customer or manager understands 60 different OSI licenses...) and selling of the product. And in one thing he is definitly right: even when we are working in an Open Source environment and we are (mostly) technicians, we want our project to be used (why else would we put it out there), plus a healthy project needs a proper community. Maybe we should once in a while put code, tests, architecture-discussions and the like aside and try to put on the shoes of our (potential) users. And I am afraid in many Open Source projects we will realise, that these shoes are not fitting all too good ;-)

This brings me btw. to another thought: maybe the way the OS process is structured and organised leads in many cases to excellent code, but not necessary to excellent products (in the sense, that the user understands what the software could do for him and how he could use it efficiently). I think OS projects and their tools actually encourage mostly coders to participate in a project. I think, there are hardly OS projects where some contributors are focusing only on interaction design, documentation, marketing...

Might be worth a second thought?!

[Arch] Pattern Based Development with Mule

I've found an interesting article about Pattern Based Development with Mule. This article illustrates how you can implement the Enteprise Integration Patterns using Mule elements. All code examplex are based on Mule 2.

[Pub] Open Source ESBs for System Integration

For our German speaking audience: in the current iX magazin Markus and I discuss the expectations on an ESB and the current status quo in the Open Source arena particularly focussing on Mule and the trinity Apache ActiveMQ, Camel and ServiceMix. As an example we show a support-process and analyse how the process-execution can be supported by integration middleware.

Then we go into some details of what you could expect from an ESB (MOM, routing, filtering, message transformation, various endpoints, ...). I outline the Java Business Integration (JBI) standard which is in my opinion an important attempt in trying to define integration concepts and enterprise service components that can be exchanged between ESBs of different vendors.

In brief we also outline concepts of clustering and failover, mostly on the example of ActiveMQ using Broker Networks, failover protocols and the like. Finally we go into more details into the current status of ServiceMix and Camel and Mule. (But our avid blog-readers will know most of that already from various blog postings anyway).

[Pub] The tenth book is out!

Well again something to celebrate:
My tenth book is out!
(is it time to stop now?)

If was again a ot of work but the result looks good and contains quality. The Proceedings of the First International Conference on Object Databases ICOODB 2008 (ICOODB.org) have been printed and are now being send around the world.

Please drop me a line if you wish to order a copy!

Any hints for the next ten books are welcome :-)
Best
Stefan

[Tech] Update on "Maven: The Definitive Guide"

I am happy that the guys from Sonatype are continuously improving their free book on the "de facto standard" Apache Maven build-automation framework: "Maven: The Definitive Guide". The book covers most topics typical Maven users will encounter, including generation of documentation (site) and writing Maven plugins (mojos).

I think this book is very useful for the newbie as well as for more experienced Java developers. The book is frequently updated and available for online reading and as PDF download; in the recent update they put their book under a Creative Commons license.

[Event] Software and Systems Essentials Conference 2008

From April 28-30 the 2nd Software and Systems Essentials Conference 2008 took place in Bern, Switzerland.

An important goal of the conference is bringing together people from business, industry, and academia who are working in software engineering and information technology with its various aspects. Discussions and exchange of experiences between users in public and industrial contexts and vendors of software solutions (regarding software development frameworks) were in the main focus of the event. 

Main topics of the conference were software processes and the exchange of experience on the individual application in various contexts (e.g., in the public application domain), project management regarding systematic systems development processes, and software quality. Among several topics in these areas, I recognized a focus on traceability, i.e., requirements tracing from requirements analysis over design to software code (vertical traceability) and vice versa and linking requirements and specifications to software code and test cases on various levels of abstraction (horizontal traceability). 

We gave a presentation in the track "Testing and Quality Assurance" titled with "QATAM: ein Szenariobasierter Ansatz zur Evaluierung von Qualitätssicherungsstrategien" (D. Winkler, C. Denger, F. Elberzhager, and S. Biffl). This presentation is a result of an ongoing project of TU Vienna and Fraunhofer IESE  in Kaiserslautern, Germany (Institute for Experimental Software Engineering).

Summary of the presentation

 

Efficient development of complex high-quality software system requires systematic planning activities. The selection of an appropriate software process, e.g., the V-Model XT, is a success-critical activity in software development. Software processes define the sequence of steps within a software development project (e.g., what products are required at which milestone). Additionally, constructive and analytical methods support developers in building a product (constructive methods) and verifying/validating  software solutions (analytical methods). 

Nevertheless, resources typically are critical issues in software engineering practice. Thus, an optimal resource planning is required with respect to quality assurance (QA) planning for small- and medium enterprises as well as for large companies. The "Quality Assurance Tradeoff Analysis Method" (QATAM) focuses on the definition and evaluation of quality assurance strategies to enable optimal application of a balanced set of agreed methods along the project life-cycle. The given presentation includes the basic concept of QATAM and illustrates its application with respect to better planning method selection and application regarding a more efficient project execution. 

The slides of our presentation (in german language) are available for download.

The slides of all presentations will be available to the conference participants via the conference website.

Keynotes

Beside presentations and discussions of academic and industry papers, "state of the art" presentations focus on relevant topics for industry and best software engineering practice:

1. E-Government Programm Schweiz – Ein komplexes Programm in einem komplexen System (Peter Fischer, EFD) 
2. From informal process sketches to enactable process: How to represent your development process with SPEM 2.0, Rational Method Composer, and Team Concert  (Peter Haumer, IBM) 
3. Agiles Projektmanagement für große Projekte (Bernd Österreich, OOSE)

Keynote presentations are available on the conference website.

Dietmar Winkler (published and edited by Alexander Schatten)

[Arch] Apache CXF and "Code First" Webservices

Dana Gardner has an interesting interview in his Briefings Direct podcast (transcript) talking about the Apache CXF project. Apache CXF is one of the leading "Open Source Service Framework", supporting a series of service protocols like SOAP, XML/HTTP, RESTful HTTP, or CORBA. Additionally CXF plays in the concert with Apache Camel, ServiceMix and ActiveMQ.

I believe, that CXF is a great project and as I said a leading webservice framework. I also perfectly agree on their statement, that Open Source frameworks in the middleware/SOA field will more or less take over the market (I would probably not buy shares from Oracle/Bea *g*). But I feel a quite a bit uncomfortable about two fundamental concepts that were stressed several times in the interview:

1. Code First approach and slightly connected:
   
2. Abstracting too much from Webservice protocols like WSDL: "So, a lot of these more junior level developers can pick up and start working with Web services very quickly and very easily, without having to learn a lot of these more technical details.", Kulp
   

I personally believe that this is not the right way to go. I think we have to take the criticism of the REST folks (among others) seriously here, and the question we have to ask ourselves is: why in the first place do we want to use SOAP webservicess?

Because it is an easy remoting approach that a junior level engineer can click together with a wizard due to excellent frameworks and UI components? Sure not! First: a remote methode call is something fundamental different compared to a local method call; it probably should be treated as such. But even more important: Services on the basis of SOAP have some underlying assumptions:

• platform independence is needed
• Services on a rather coarse granularity are exposed
• interoperability over system/company borders are imperative, i.e., the service interface is in the center and should be considered properly and not change any minute
• remote service calls are rather the exception (coarse granularity, aggregated functionality),
• strong formalisation is needed (XML schema, service description, security...)
  
• i.e. performance losses due to XML (un-) marshalling are acceptable considering the advantages gained by this "neutral" approach
  

and probably some more. The point however is, that SOAP services are not just an ordinary remoting approach they are to expose Services under specific conditions. (For other remoting problems probably other technologies like RMI or REST are better suited.) In the cases where SOAP is a good architectural choice I would suggest that the platform neutral service description i.e. WSDL should stand in the center of attention. The idea is, that different parties can express a neutral and platform independent service description plus data-description in W3C schema as a foundation for cooperation.

The next step, not the first step is to implement the service. So my feeling about code-first approaches are that they can lead developers and architects into a dangerously wrong direction (just two annotations and the webservice is done, so we are made to believe). What we would really need are not code-first webservice frameworks, but easy to use WSDL editors/modeling tools.

Additionally a Webservice infrastructure is by definition a complex beast. Trying to abstract all underlying protocols from the developers easily gives them a wrong idea about the actual complexity of their undertaking. When (e.g. interoperability, security) problems occur, they probably have no idea about the reason and the means to fix them. So give us good Service modeling tools, but no code-first approaches. This leads us into the wrong direction.

Just my two cents.