Posted by Vincent Partington at around evening time: August 5th, 2009
Four weeks ago my colleague Robert van Loghem wrote about what the full scope of a deployment in an enterprise Java environment. The scenario that Robert presented included the configuration of databases, web servers, firewalls and Java EE resources. All are just as important to get your application up and running as the deployment of an EAR file.
But even though Robert’s procedure was more complicated than the simple installation of an EAR file, it did not cover an even more common scenario; upgrading an application to a new version. While the initial deployment of an application is important, I think that upgrades are even more interesting for a number of reasons:
- The most obvious reason is that upgrades simply happen more often than initial deployments.
- Upgrades (in production) happen when users are already using the application, so the application should remain accessible during the deployment.
- If the upgrade fails, the old version of the application should still be there.
- And finally, but this is a more people oriented aspect of it, upgrades can be tricky because the focus on the application may have disippated over time. When the application is deployed for the first time, everybody is paying attention: the developers, the middleware administrators, the architects, the project managers, the end users, etc. So when a problem arrises, it is usually addressed quite quickly. But when version 2.1.54 comes around and an administrator is asked to install it on a Friday afternoon, that is when things can go horribly wrong and ruin the poor admin’s weekend. Paying attention to the complexity of application upgrades, can mitigate this.
Because the upgrade scenario is the most important deployment scenario, it is something that comes up often when talking to clients about Deployit, our deployment automation product.
(more…)
Posted by Michaël van Leeuwen around lunchtime: August 3rd, 2009
Rik de Groot wrote a blog entry about a year ago about versioning services as part of the Top 10 SOA Pitfalls. He touched the subject on different versions in deployment and basically offered us the option of rerouting services using an ESB.
It is a common knowledge that consumers will keep on using a service hoping to only upgrade if *they* need additional or changed functionality. Services however are not meant for a single consumer but for a lot of consumers. Even if they want to upgrade they won’t do it simultaneously. So you will have multiple versions of services running.
I see several options to address versions of services:
1. Minimize by using rerouting within the ESB.
2. Keep all versions running while in use.
3. Have a contractual agreement with expiry date.
4. Use content based routing.
5. Construct adapters for conversion
First I would like to look at which versions might appear. A major version increment of a service means we are no longer backward compatible. A consumer wanting to use the next major release therefore needs to start coding to make use of this service. When a minor increment occurs there is backward compatibility and additional functionality offered. This means a consumer can make use of it without much effort (changing the binding would suffice). A patch increment of a service indicates a change without breaking specifications. A new patch release can – and should – therefore replace the older version.
Clearly in all options we should limit the number of versions of a service created. This means services should not be created within projects but (re-)created in a separate track in order to have generic services and optimal reuse. This track should collect all requirements of (potential) customers, take the common denominator and bring a new version into existence. More than often a new version is created because a single customer wants certain functionality not yet offered and without looking around the new version is tailor-made.
(more…)
Posted by Iwein Fuld in the early morning: August 3rd, 2009
Last week I’ve added a new test bundle to Spring Integration. This bundle contains matchers to help writing tests for Spring Integration configurations. It builds on JUnit 4, Hamcrest and Mockito. Even if you’re not a user of Spring Integration, I will make sure that this post gives you a few ideas for using matchers to write more readable tests.
First a few pointers to Spring Integration to give you some background.
Spring Integration is a framework that aims to implement Enterprise Integration Patterns as described in the book by Hohpe and Woolf. The book is nice, but using those patterns will require some boilerplate and plumbing that is a good match for a framework, hence Spring Integration. JUnit 4 you should know about already, but a feature that was added recently deserves another mention. In the latest versions of JUnit you can use the assertThat(T actual, Matcher<T> matcher), which builds on Hamcrest matchers. This already makes your assertions much more readable, but combined with Mockito, test cases become poetry. I will assume for now that I don’t need to tell you about all this, but if you have no clue what I’m talking about you should really enlighten yourself.
EIP frequently involves asynchronous handoff, also it involves wrapping object payloads in messages. Both of these can be in the way when writing tests. Luckily we can easily abstract this boilerplate away. Today I’ve committed the solution for the unwrapping problem, I’ll talk about a solution to the second problem another time.
Unwrapping messages requires some boilerplate that makes the test harder to read. The following snippet from the Spring Integration’s AggregatorEndpointTests clearly shows both problems.
@Test
public void testCompleteGroupWithinTimeoutWithSameId() throws Exception {
//...
Message<?> reply = replyChannel.receive(500);
assertNotNull(reply);
assertEquals("123456789", reply.getPayload());
}
In a few seconds it’s clear what we’re trying to do here, but it doesn’t look very elegant to me. With the new test project we aim to make this type of code more readable. To do this we’ve created some utility classes. (more…)