- Mule project wizard
- Mule runtime configuration (you can define different Mule runtimes)
- Graphical Mule Configuration Editor
- Start your Mule Server from your IDE
Saturday, December 20, 2008
Friday, December 19, 2008
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
Thursday, December 18, 2008
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.
In an initial research I did not find much tools in that area, any ideas?
Tuesday, December 09, 2008
I must say, I am quite impressed so far. Any comments on that one?
Friday, December 05, 2008
Monday, December 01, 2008
- 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
- 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
Wednesday, November 12, 2008
- Resources such as a person, an order, or a collection of the ten most recent stock quotes are identified by a (not necessary unique) URL.
- Requests for a resource return a representation of the resource (eg. an html page describing the person) rather than an Object that IS the resource. A resource representation represents the current state of the resource and as such is immutable.
- Representations contain typically links to other resources, so that the application can be discovered interactively.
- There is typically a fixed and rather limited set of actions that can be called upon resources to retrieve or manipulate them. HTTP is the best known example of a RESTful system and defines eg. GET, PUT, POST and DELETE actions.
- http://www.1060.org – the homepage of net kernel.
- A recent article on TheServerSide.com about resource oriented computing with NetKernel that provide a more thorough introduction.
Sunday, November 02, 2008
- Develop services in Mule
- Dealing with web services in Mule
- Exception strategies
- Transaction Management
- Projects around Mule: Mule HQ and Mule IDE
Tuesday, October 28, 2008
- 16th Annual Meeting of International Software Engineering Research Network ISERN, Oct 6th-7th
- 6th International Advanced School of Empirical Software Engineering. IASESE, Oct 8th
- 3rd International Doctoral Symposium on Empirical Software Engineering IDoESE, Oct 8th
- 2nd International Symposium on Empirical Software Engineering and Measurement. ESEM, Oct 9th-Oct 10th
- aggregation opportunities from experimental results,
- application of Empirical Software Engineering to Software Architecture
- discussion of an Empirical Research roadmap and associated key task within a time range up to 2010
- application opportunities of empirical investigations using simulation.
Abstract: Studying the effectiveness of scenario development meetings in the software architecture process is important to improve meeting effectiveness. This paper reports initial findings from analyzing the data collected in a controlled experiment aimed at studying the effectiveness of meetings in terms of gained and lost scenarios of individuals, real and nominal (non-communicating) teams. Our findings question the effectiveness of holding meetings since more important scenarios were lost than gained in these meetings. In the study nominal teams performed better than individuals and real teams.
The slides of our presentation are available for download.
Key Note Talks
- Using empirical methods to improve industrial technology transfer. (Harald Hoenninger, Vice President Corporate Research, Robert Bosch GmbH, Germany).
- Empirical Challenges in Ultra Large Scale Systems (Mary Shaw, Institute for Software Research, Carnegie Mellon University (USA)
Abstracts of the key notes are available for download.
Dietmar Winkler (edited by Alexander Schatten)
Sunday, October 26, 2008
From my point of view the example is very interesting based on the following key points:
- Asynchronous communication in a servlet container
- The most interesting thing is how to correlate the request with the response through different layers
- How Mule fits in such a architecture
- Practical example of JMS
- Using Routers in Mule and route the message to the right Queue
- Using Apache CXF in Mule
Friday, October 24, 2008
Recently two fresh books fell into my hands:
- The Productive Programmer, Neal Ford, 978-0596519780
- Clean Code, Robert C. Martin, 978-0132350884
- Meaningful Names (! which is a horror in big companies with developers from different cultural and technical backgrounds to my opinion...)
- Comments (you think you can not learn here?)
- Formatting (sounds boring but is not) and
- Error Handling, Boundaries, Unit Tests, Classes, Systems, Emergence, Concurrency, Successive Refinement, JUnit Internals, and more...
So God bless all (most of?) the software developers!
(who read these books ;-)
Monday, October 20, 2008
The paper is available for download.
Saturday, October 11, 2008
REST ist an architectural style on how to let distributed applications communicate. It is considered as an alternative approach to XML:RPC or SOAP webservices. I generally like that Google Talks introduction to REST:
I would also recommend additional resources to get a more complete picture on REST, check out this link.
Monday, October 06, 2008
The book is divided into three parts. The first part concentrates on reader which are not familiar with an ESB:
- Overview about ESB functionality and what Open Source ESBs are available in the Open Source market
- Taking a deep look into the Mule and ServiceMix architecture
- Installation of Mule and ServiceMix and how to run them
You can download chapter 1 and chapter 4 for the book homepage.
Tuesday, September 30, 2008
Dowload the thesis here.
Thursday, September 18, 2008
Wednesday, September 17, 2008
I find this really interesting: In talking with many people who actually do make Software in the last years (not only talk about it *g*) I think I detected that many have a growing problem with the term "requirement". Martin Fowler sums it up greatly in his recent blog post. He makes a strong point in saying that the understanding that many people have about "requirements" is actually still very much driven by a waterfall-like understanding of the software engineering process.
Observation comes in...
- Seed: bring in a new feature, idea; probably only to a subset of customers, probably in variations for different customers
- Select: select the successful variations
- Amplify: eventually amplify the successful ideas and bring more of that sort
... and back to the Waterfall
Wednesday, September 03, 2008
Tuesday, August 19, 2008
- Performance: in some cases, complex queries are not required (or can be replaced by simple ones): databases that perform very fast with pure primary key retrieval
- Complex datastructures are not needed
- ACID is not needed, i.e. mostly simpel writes are performed but fast reads necessary
- Agile development seems to favor rather ad-hoc data-structures vs. carefully planned ones (if this is a good trend is written on a different page)
- Distribution is important and distributed relational databases are a hard thing to do
- Access to rather document-oriented datastructures is required
Btw.: does anyone know other projects in that domain that I have not seen yet?
Monday, August 18, 2008
If the basic idea is understood the documentation of frameworks like JMock can kick in and do the rest ;-)
Thursday, August 07, 2008
Tuesday, August 05, 2008
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 :)
Wednesday, July 09, 2008
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?!
Friday, June 27, 2008
Thursday, June 26, 2008
Friday, June 13, 2008
Please drop me a line if you wish to order a copy!
Any hints for the next ten books are welcome :-)
Thursday, June 12, 2008
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.
Wednesday, June 11, 2008
- E-Government Programm Schweiz – Ein komplexes Programm in einem komplexen System (Peter Fischer, EFD)
- 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)
- Agiles Projektmanagement für große Projekte (Bernd Österreich, OOSE)
Saturday, June 07, 2008
- Code First approach and slightly connected:
- 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
- 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
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.
Thursday, May 29, 2008
- The new schema based configuration approach
- API changes
- New concepts such as Mule Context and Registry
- The role of Spring in Mule 2
- The changes of Transports and Transformers
- Migration from Mule 1.x to Mule 2
Thursday, May 15, 2008
- Method Chaining
- Pushing Parameters into objects or nesting
- Literal collections (like being used in Ruby or Rails)
- Closures (please let them arrive in Java...)
- parsing XML or other notations
Tuesday, May 13, 2008
- An optional factory interface replaces the abstract factory class
- Every factory method is responsible for creating an object and injecting its dependencies
- Lazy-instantiation of service components
- Non-Singleton scope (if always a new instance of a object must be created)
- Wiring up objects dynamically
- Creation of local stateful objects with dynamic paramters for singletons
- Using factories, developers have to write more code to get started
- Factory implementation code changes significantly if code changes between lazy-initialization and eager-initialization or from singletons to non-singletons
- Abstract Factory design pattern include creating local stateful objects from dynamic parameters, handling checked exceptions thrown during object creation, and wiring up objects dynamically
- Better performance because it uses straightforward Java code and hardwiring
Wednesday, May 07, 2008
I believe, that iBator makes the already very easy and straightforward iBatis project even more accessible in providing good boilerplate code to start from, yet I would be curious about actual "roundtrip experiences"...
Tuesday, May 06, 2008
"[...] Mule was designed around the philosophy of 'Adaptive Integration'. What this means for Mule users is that they can build best-of-bread integration solutions because they can choose which technologies to plug together with Mule. [...]"
About JBI he points the following assumptions and there consequences:
- XMLmessages will be used for moving data around
- Data Transformation is always XML-based
- Service contract will be WSDL
- No need for message streaming
- You need to implement a pretty heavy API to implement a service
- It’s not actually that clear what a service engine is in JBI
"[...] JBI seems to be a 'standard' written by middleware vendors for middleware vendors. This 'vendor view' of the world is one of the main reasons Open Source has done so well. Traditionally, Open Source has been written by developers much closer to the problem being tackled. These developers can deliver a better way of solving the problem using their domain knowledge, experience and the need for something better. This was the ultimate goal Mule and given the success of the project I believe that goal has been realized with the caveat that things can always be improved (which we continue to do). [...]"
Monday, May 05, 2008
Friday, May 02, 2008
Wednesday, April 30, 2008
Tuesday, April 29, 2008
He defines a set of scenarios using specific patterns (the figure above shows one of the scenarios) and are implemented with various (combinations) of technologies to evaluate and demonstrate the capabilities of the specific technology or mix of technologies. Finally he categorises the frameworks and gives hints on implementation best-practices.
I don't want to go into details here, but who is interested in Enterprise Integration Patterns and Open Source frameworks might want to download the full thesis here. The sources of his examples can be downloaded as well.
Wednesday, April 23, 2008
- A "formal" top-down approach using Standards like BPEL or SCA; this approach typically is process driven
- Event-driven architectures, which is a rather bottom-up approach (and a very agile and flexible one!)
- And finally a data-driven approach using "syndication" features and standards, typically following the REST principles (which reminds me, that I want to write something about REST since an eternity...)
Friday, April 18, 2008
- Major API changes and improvements
- Architecture improvements
- Transports, transformers, Connectors have consistent look and feel
- Schema-Based Spring XML configuration
- A REST pack was released with 2.0 hosted on MuleForge
- Future support for SCA
Wednesday, April 16, 2008
- Christof Wittig (CEO db4objects Inc.) with a cool Web 2.0 keynote
- Mice Card from the OMG about database standardization
- Prof. Subieta presenting his stack based approach to object databases
The second day (14th) was the application day with talks from:
- Robert Greene (Vice President Versant Inc.)
- Leon Gudzenda (CTO Objectivity)
- Ralf Westphal with two invited talks about Transacional Memory and AmazonDB
- Carl Rosenberger
- Chris Beams (Spring Source)
Furthermore we will put in some interesting slides on the webpages in a few weeks.
Wednesday, April 09, 2008
Today I came in contact with a post writing about the Google App Engine.
"[...]Google App Engine is designed for developers who want to run their entire application stack, soup to nuts, on Google resources.[...]"
- Write code once and deploy
Developers write the code, and Google App Engine takes care of the rest
- Absorb spikes in traffic
Automatic replication and load balancing with Google App Engine
- Easily integrate with other Google services
Using built-in components provided by Google
"The service is completely free during the beta period, but there are ceilings on usage. Applications cannot use more than 500 MB of total storage, 200 million megacycles/day CPU time, and 10 GB bandwidth (both ways) per day. We’re told this equates to about 5M pageviews/mo for the typical web app. After the beta period, those ceilings will be removed, but developers will need to pay for any overage. Google has not yet set pricing for the service."At present applications must be written in Python, because Googles infrastructure is based on it.
Monday, April 07, 2008
"Nachhaltigkeit und IT - Eine Neuorientierung"?
Folgende Programmpunkte sind geplant:
- Alexander Schatten: Einführung zur Veranstaltung, und Idee der Neuorientierung des Arbeitskreises
- DI Friedrich Schmoll (Umweltbundesamt): "Green IT---Nur ein Marketingschlagwort?"
- DI Georg Meixner (IBM): "IT-Nachaltigkeit und Kosten"
- Diskussion mit den Vortragenden
- Diskussion über zukünftige Aktivitäten und OCG Arbeitskreis-Ausrichtung
Thursday, April 03, 2008
- Mule Architecture and the programing model of Mule
- Service Components (alias Universal Message Objects)
- Endpoints, Routers, Filters
- Available Transports and how a transport is organised
- Spring AOP
- Springs transaction management
- Resource handling of Spring
- and many other features (DI, ...)