This post is also avaialble on GitHub together with all the source files!

When using Jenkinsfile and Dockerfile with Microservices you are typically repeating the same boilerplate code over and over again. Initially this is not a problem but as the number of Microservices - and Git branches - start to increase it can become quite painful.

In order to stay DRY you can leverage the ONBUILD Dockerfile keyword in a custom base image and a global var to define a reusable Jenkins pipeline.

With this solution each Microservice has a Jenkinsfile similar to

@Library("mylib@latest") _
mavenPipeline(java: '8')

... and a Dockerfile as simple as

FROM mybase:latest

See Dockerfile for an example on how the custom base image can look like and the project pom on how build both the base image and the Microservices using it!

Read the rest of the article if you are interested in the details or if the above does not make much sense.

• Context
• The Problem
• A Solution
• An Example
• Last Words

Context

Let's say you are using Microservices. Following best practices, each Microservice has its own source code repository. You start out with a few but this rapidly grows to a few dozen and with time you are managing a few hundred, perhaps more.

Each Microservice is built as a Docker image that defines a few labels, variables and some bootstrap code. A Dockerfile might look something like:

FROM openjdk:8-jdk-alpine

ENV SVC_HOME=/opt/microservice
ENV SVC_ETC=${SVC_HOME}/etc SVC_LIB=${SVC_HOME}/lib SVC_CACHE=/var/cache/microservice BOOTSTRAP=${SVC_HOME}/bootstrap.sh

RUN addgroup --system microservice \
    && adduser --system --ingroup microservice --home $SVC_HOME microservice

ADD src/files ${SVC_ETC}/
ADD bootstrap.sh ${BOOTSTRAP}

RUN mkdir -p $SVC_LOG $SVC_CACHE $SVC_ETC \
    && chown -R microservice:microservice $SVC_LOG $SVC_CACHE $SVC_HOME \
    && chmod +x ${BOOTSTRAP}

USER microservice

ARG JAR_FILE

ARG ARTIFACT_ID
ARG GROUP_ID
ARG VERSION

LABEL org.label-schema.vendor="My Company" \
    org.label-schema.name=$ARTIFACT_ID \
    org.label-schema.description="Yet another Microservice" \
    org.label-schema.usage="/README.md" \
    org.label-schema.version=$VERSION \
    org.label-schema.schema-version="1.0" \
    java.version=${JAVA_VERSION} \
    java.alpine.version=${JAVA_ALPINE_VERSION}

ENV \
    ARTIFACT_ID=${ARTIFACT_ID} \
    GROUP_ID=${GROUP_ID} \
    VERSION=${VERSION} \
    LOG_LEVEL=INFO \
    CACHE_DIR=${SVC_CACHE}/${ARTIFACT_ID} \
    ETC_DIR=${SVC_ETC}/${ARTIFACT_ID} \
    MICROSERVICE=${SVC_HOME}/${JAR_FILE}

ADD target/lib ${SVC_LIB}/
ADD target/${JAR_FILE} ${MICROSERVICE}

# HTTP
EXPOSE 9000
# JMX
EXPOSE 8181

ENTRYPOINT ["/opt/microservice/bootstrap.sh"]

Having fully bought into the whole DevOps and automation concept you have CI/CD pipelines to build and deploy your Microservices.

Jenkins you use out of habit, because this is what you know or because it seems to be a very popular choice. Who really knows why, but Jenkins is what you are currently stuck with.

Jenkins is configured to automatically detect new Git repositories and manage pipelines for each Git branch. A Jenkinsfile in your Git repository defines the steps for building a Microservice and pushing code automatically triggers the build.

pipeline {
    agent docker
    stage ('Build') {
        steps {
            ...
        }
    }
    stage ('Test') {
        steps {
            ...
        }
    }
    stage ('Verify') {
        steps {
            ...
        }
    }
    stage ('Publish') {
        steps {
            ...
        }
    }
}

Thus the Git repository root contains two boilerplate files, one for Docker and one for Jenkins:

Dockerfile
Jenkinsfile

In most cases these files are almost identical apart from label and environment values. In order to facilitate for developers these they are automatically generated using a template mechanism of some sorts. Perhaps the nifty Docker Enterprise Desktop shipping as a part of Docker EE 3.0

The Problem

Requirements change or perhaps there is a bug but for whatever reason either the standard Jenkins pipeline and or Dockerfile change over time.

With a large number of Microservices that each has its own version of the Jenkinsfile and Dockerfile, multiple branches for handling the master line, development, features and bugs the relevance of the DRY principle starts to sink in and you realize you have a WET solution...

For every change that comes along you now have to check out the code make the same edit for all branches.

Cheery-picking and merging helps but still there is a lot of typing, committing and pushing going on. This increases the risk of typos and other inconsistencies, in particular if done by multiple teams and developers.

Of course, nothing prevents you from automating changes like this, but it would throwing code at a symptom instead of resolving the root cause.

A Solution

A solution that addresses the WET root cause comes in two parts:

• Use a custom base image in your Dockerfiles
• Use pipeline DSL in your Jenkinsfiles

Using a Custom Base Image

A custom base image should contain all things common to your downstream Microservices, things like

• standard image labels
• log configuration files
• common bootstrap shell scripts
• runtime users
• ...

The custom base image in itself uses a more standard upstream image, such as the alpine version for your language.

Some things depend on the downstream Microservice, however. What if you have a label containing the name or version of the Microservice? These are only known at build time of the Microservice itself, not when we are building the base image.

The key here is Docker's ONBUILD keyword which allows you to customize your base image to your Microservice using build time arguments.

For example we can set a version container label on the downstream Microservice with

ONBUILD ARG VERSION
ONBUILD LABEL version=${VERSION}

Given that the base image is called mybase we then use a Dockerfile in Microservice repository with the following content:

FROM mybase:latest

That's it. That is the entire Dockefile.

To build it we have to supply a build argument to the docker command, something along the lines of

docker build --arg VERSION=1.3.9 .

The resulting image will then contain the container label version: 1.3.9 (surprise!).

If the we want to change something, perhaps adding another standard label, update the logic to the bootstrap script, change the log configuration or perhaps just update the to the latest alpine for Java, we only change it in one place, i.e. in the custom base image mybase.

Of course, we still need to trigger the rebuild and redeployment of all our Microservices but the DRY principle is respected.

The beauty of this approach is that we still have our Dockerfile in each Git repository which can be customized if there is a real need. Just because there is a default base image does not mean that we force everybody to use it all the time. All our CI/CD tools will still work exactly the same and the only drawback is that we now have one exception to manage separately from the rest.

If you find yourself making a lot of similar exceptions, refactoring of the base image might be in place. Or perhaps there is a need for two different types of base images? In any case, try to keep it as simple and stupid as possible (cf. KISS).

Please see Dockerfile for a more complete example of how a custom base image can look like!

Use pipeline DSL in your Jenkinsfiles

Jenkins has support for building custom pipeline DSL in Groovy.

This can be quite complicated given that Jenkins Groovy flavor is not 100% vanilla and it has a sour twist - not all Groovy features are available and you need follow certain conventions. If you stick to existing steps and very simple groovy code you should be good though.

Here we will not go into details on how to develop a Pipeline DSL but the basic idea is that you define a global variable for the entire pipeline and use it in your Jenkinsfiles.

Given a DSL library called mylib and a global var called mavenPipeline the Microservice Jenkinsfile could be as simple as this:

@Library("mylib@latest") _
mavenPipeline(java: '8')

Note the trailing underscore which is a package placeholder to which the annotation is attached!

Here we assume that mavenPipeline has parameter support for the java version to use. You can have others as well, if you like, but be careful not to repeat too many boilerplate settings!

Now, if there is a change to how the Microservice is built, how continuous delivery is done or perhaps if a new quality gate is added as a separate step, there is no need to change any of the Microservices. You just change the definition of the mavenPipeline.

Similar to how we handle the Dockerfile we can manage a custom Jenkinsfile if needed.

An Example

This Git repository contains a more complete example of a custom base image. It assumes Java based Microservices built by Maven but the concept should be easily adaptable to any language or platform.

• pom.xml for building the image
• bootstrap.sh docker entrypoint for launching the microservice
• jmxremote.access for configuring remote Java JMX access
• logback.xml for log configuration

To build the base image you can launch

mvn clean package

If you want to deploy the base image you need to

• Configure Maven distributionManagement settings; and
• Make sure to change the docker.namespace to you Docker Hub account.

If you are using a private registry you also need to update the docker.registry property and probably add credentials in Maven's settings.xml - YMMV!

Once Maven is properly configured you can then run...

mvn clean deploy

... and Maven will happily deploy the (empty) JAR to your Maven registry and Docker image to Docker Hub or whatever you have configured.

Your Microservices should use Dockerfile along the lines of Dockerfile.microservice in the root of each Microservice repository branch.

(!) Note that the example requires Java 8 and Maven 3.5 to run!

Jenkinsfile

The Jenkinsfile will not work without you writing a custom DSL and adding the mavenPipeline global variable to your Jenkins instance.

Using a Jenkinsfile works best with a plugin like Bitbucket Branch Source Plugin or similar so that all new repositories and branches are automagically discovered by Jenkins.

POM

The Maven POM builds the Docker image using Spotify's dockerfile-maven-plugin.

The POM is configured to

• Download all dependencies which are then added to the image
• Create an executable JAR file which is also added to the image
• Build the image if a Dockerfile is present using a Maven docker profile

The base image pom.xml has two dependencies: the logback-classic and logstash-logback-encoder libraries. These are shared by all our Microservices and are required for the logback.xml configuration file.

The configuration found in the POM can be used both for building the base image and for building the Microservices, indeed given the use of a Maven docker profile it can be used for any Maven project with or without Dockerfiles.

In order to stay DRY the plugin configuration in the POM should be put in a parent pom shared by all Microservice projects. Or you will again end up with a WET solution...

Entrypoint

The bootstrap.sh shell script that serves as the docker image entry point.

It sets a few variables used for configuring the Microsevice and launches the microservice itself with a number of standard JVM arguments, including configuration of logback and JMX.

A nifty feature is that it will pass along all docker command line arguments to the Java runtime.

Last Words

There are of course other solutions that still respect the DRY principle.

For example it might be preferable to get rid of the Dockerfile altogether. If you are building with Maven a good candidate is to use JIB.

You could also get rid of the Jenkinsfile and implement auto discovery for Jenkins pipelines yourself but this seems like a rather cumbersome approach though. I would opt for an out-of-the-box solution that provisions build pipelines automatically.

I am not aware of any alternatives that do not use a Jenkinsfile, so it may be a good reason to look beyond Jenkins. Using another tool also has the benefit of not having to deal with Jenkins flavor of Groovy...

Any pointers on good alternatives that stay DRY for managing a large number of Git repositories and Dockerfiles are welcome!

In the first part of this blog post I discussed how Java Enumerations can be conveniently used as

1. Fault codes in exceptions; and
2. Provide formatted and localized error messages

The major drawback with the approach is that the fault codes make exception handling more complicated for cases when the same logic should be applied to different enumeration types.

This part of the blog post discusses a possible extension of Java Syntax for better exception handling when using enumeration fault codes.

First we need a way to distinguish the exceptions that support fault code enumerations from those that do not. We also need to indicate what type of fault code is supported by the exception. We therefore introduce a a new Fault interface from which all fault code exceptions must inherit:

public interface Fault<C extends Enum<C>> {
    C code();
}

If we for a given application assume an ApplicationFault Exception class defined as

public class ApplicationFault
extends RuntimeException
implements Fault<ApplicationFault.Code> {

    public enum Code {
        A1, A2, A3, A4
    }

    private final Code code;

    public ApplicationFault(Code code) {
            this.code = code;
    }

    @Override
    public Code code() {
        return code;
    }
}

… we can then specify the fault code as constant values for the exception, i.e. something like

try {
    // do something
} catch(ApplicationFault{A1, A2} | IOException e) {
    // handle ApplicationFault A1, A2 faults and IO Exceptions
} catch(ApplicationFault{A3} | IOException e) {
    // handle A3 faults
}

This new syntax should be interpreted as

• Handle all ApplicationExceptions for fault codes Code.A1 and A2 and
  IOExceptions in the same way
• Handle ApplicationExceptions for Code.A3 faults separately
• Allow all ApplicationExceptions for Code.A4 faults to propagate up the
  call chain

(The Code enumeration type can be deduced from the ApplicationException.)

In addition, compile time errors would occur if

• Non-existing or the wrong enumeration fault codes for the class are referenced
• ApplicationFault does not implement Fault
• ApplicationFault is a checked exception and not all fault codes are caught

We could even take it one step further if Java would allow generic type parameters for Exception classes. (Exceptions in Java do not support generic type parameters as there is no evident use for them, but if we introduce fault codes they would start making sense.)

Let us assume that the JDK defines a generic RuntimeFault:

public class RuntimeFault<C extends Enum<C>>
extends RuntimeException
implements Fault<C> {

    public RuntimeFault(C code, Object... args)  {
        ...
    }

    @Override
    public Code code() {
        ...
    }
}

We would then only need to define our fault codes in an enumeration (Localized or not), throw them as follows:

throw new RuntimeFault<CodeA>(A1, arg0, arg1);

… and catch them like so

try {
    // do something
} catch(RuntimeFault<CodeA>{A1, A2} | RuntimeFault<CodeB> | IOException e) {
    // handle RuntimeFault for Code.A1 and A2 together with all CodeB faults and IO Exceptions
}

The main motivation for allowing generics in this way would be to have fewer exceptions. Instead of defining a new exception for each application or module with its own set of fault codes we would only define the fault codes and in most or all cases use the default RutimeFault exception class.

While this might be tempting we need to answer a number of questions introduced by the additional complication of allowing generics in exceptons:

• Would other exceptions besides RuntimeFault be allowed to be generic in the
  same way?
• Would the generic type parameters be limited to enums? If not, what would that
  mean?
• Should we perhaps allowing catching the interface Fault as well? What class
  object would be assumed in the catch clause?

There are probably limitations related to type erasure and how the catch clause is implemented in Java that would answer these and other questions. Unfortunately I lack the insight to provide a good answer on the feasibility of any of the extensions suggested above.

In a blog post from last year the author proposes changes to Java 9 that pretty much attempts to solve the same problems as discussed in this post, but instead of using enum codes the solution is based on Strings. He actually goes as far as making a forked JDK to test the the new feature!

To catch the codes the author introduces a new syntax:

} catch (CodedException | IOException ex, "code4", "code5") {
    ...
}

The CodedException class is required to be part of the catch clause for the codes to be caught.

To me the syntax is a bit clumsy as the CodedException is not kept together with the codes and using String constants is error prone. How do we known the fault code is ever thrown? With enumerations you get type safety and all codes has at least to be defined somewhere.

Last defining a single code is a bit more verbose, compare:

public static final String CODE_A = "error.code.a";
public static final FaultCode FAULT_CODE_A = new FaultCode(CODE_A, 1, "error message: {0}");

… as opposed to

CODE_A("error message: {0}")

Granted, there is a little bit of overhead not shown where we store the MessageFormat in the enumeration but this is quickly regained when there are more than a few codes.

When I first read about Swift I quite liked its error handling.

In Java checked exceptions have gotten quite a bad rep but instead of throwing out the baby with the bathwater and getting rid of checked exceptions altogether, the way they do it in Swift seems to strike a good balance.

The thing that caught my eye however, was the use of enumerations instead of exception classes.

Using an enumeration as an error means that

• Errors have a natural code (the enum value)
• Errors are grouped together in a single place (the enum type)
• There is no need to create contrieved exception hierarchies to differentiate between different types of errors

Fortunately Java has had enumerations since Java 5, an example exception using an enumeration fault code could look something like

public final class ExampleException1 extends RuntimeException {

    public enum Code {
        ERROR_1,
        ERROR_2,
        ERROR_3;
    }

    public ExampleException1(Code code) {
            super(code.name());
    }
}

The exception message above will just be the name of the enumeration value (ERROR_1 etc) which can work fine if the codes clearly indicate what the problem is. We can do better, however, by adding support for formatted messages and localization.

If we introduce an interface with default implementations for using MessageFormat and ResourceBundle we get more expressive messages without development overhead for creating new fault enumerations.

public interface LocalizedFaultCode {

    // implementation provided "for free" by all enums
    public String name();

    // default Java 8 implementations do the "heavy lifting"
    default String getMessageKey() { ... }
    default String getDefaultFormat() { ... }
    default String getResourceBundleBaseName() { ... }
    default ResourceBundle lookupResourceBundle(Locale locale) { ... }
    default String getMessage(Object... args) { ... }
    default String getMessage(Locale locale, Object... args) { ... }
}

To use the interface our Exception example now becomes

public final class ExampleException2 extends RuntimeException {

    public enum Code implements LocalizedFaultCode {
        ERROR_1,
        ERROR_2,
        ERROR_3;
    }

    public ExampleException2(Code code, Object... args) {
        super(code.getMessage(args));
    }

}

The default implementation would simply create error messages similar to ERROR_1 [arg0, arg1, ...]. In order to get formatted messages we would also need to create the corresponding ResourceBundle property files. The base name can be customized but defaults to the fully qualified class name of the enumeration code type.

ExampleException2$Code.properties:

ERROR_1     = Error with one argument: {0}
ERROR_2     = Error with two arguments: {0}, {1}
ERROR_3     = Error with thre arguments: {0}, {1}, {2}

If message formats sound tempting but we would rather not define the required ResourceBundle property files that go with, we can opt to implement the method default String getDefaultFormat() { ... }:

public enum Code implements LocalizedFaultCode {

    ERROR_1("Error with one argument: {0}"),
    ERROR_2("Error with two arguments: {0}, {1}"),
    ERROR_3("Error with three arguments: {0}, {1}, {2}");

    private String format;

    private Code(String format) {
        this.format = format;
    }

    @Override
    public String getDefaultFormat() {
        return format;
    }
}

We now have nicely formatted and potentially localized error messages all in one place.

Source code available in enum-exceptions on GitHub.

While this is nice, what about exception handling? If we retrieve the fault code from the exception when we catch it, we can of course implement branching logic based on the value, e.g. something like:

} catch(ExampleException1 e) {
    switch(e.code()) {
    case ERROR_1:
    case ERROR_2:
        // do something for error 2
        break;
    default:
        // else let it propagate up the call chain
        throw e;
    }
}

In some cases this will work just fine but if we want to handle different fault codes or ordinary exceptions the same way we are in a bit of a bind as the fault code approach effectively breaks the multicatch feature introduced in Java 7. The switch case above does for the fault code what the catch statement is already doing at the exception level.

Would it not be great if we could catch the code instead of the exception?

To do this we need to extend the Java syntax which is discussed in the next post.

As an assignment in the Strategy and Marketing course of my ongoing MBA studies we were required to give our personal view of what strategy is and I thought I should publish the result here. Part of the reading for the assignment included five articles from Harvard Business Review, three by Michel Porter and two by Kathleen Eisenhardt.

The three articles by Porter takes a high level perspective, defining strategy in terms of the nation state, the industry as a whole and strategy at the highest level of the enterprise. Essentially this is a top-down perspective, or perhaps one could call it outside-in. For Porter strategy is about making conscious trade-offs (what not to do), supported by a unique set of activities that reinforce each other and are difficult to reproduce, all in all creating a unique strategic position giving a sustainable competitive advantage (What is Strategy, p 70).

In the two articles by Eisenhardt et al strategy is something emergent, arising from the pattern of activities (patching and the application of simple rules). It is more about the internal strategy process than finding a strategic position. Essentially this is more of a bottoms-up perspective on strategy, or perhaps one could say inside-out.

Porter and Eisenhardt also differ in the time scale of strategy. Strategy in the eyes of Porter is long term; if a strategy does not lead to a sustainable advantage with a high performance outcome, it is not strategy or at least not successful strategy. As a counter point, the two articles by Eisenhardt et al discuss strategy with a shorter horizon (“internet time”).

The two following quotes make the differences particularly evident. In *Strategy as Simple Rules *(p 116), Eisenhardt says:

Like all effective strategies, strategy as simple rules is about being different. But that difference does not arise from tightly linked activity systems or leveraged core competencies, as in traditional strategies. It arises from focusing on key strategic processes and developing simple rules that shape those processes. When a pattern emerges from the processes-a pattern that creates network effects or economies of scale or scope – the result can be a long-term competitive advantage like the ones Intel and Microsoft achieved for over a decade. More often, the competitive advantage is short term.

This is the exact opposite of what Porter says in *What is Strategy *(p 75):

Strategy is creating fit among a company’s activities. The success of a strategy depends on doing many things well-not just a few- and integrating among them. If there is no fit among activities, there is no distinctive strategy and little sustainability.

Personally I tend to think about strategy in military terms: strategy is about winning the war; tactics however is about winning a battle. To me it seems like Eisenhardt’s patching and simple rules are more about tactics and less about strategies. They tell you how to maneuver in everyday business but they do not tell you much about how competitive advantage can be sustained. For Eisenhardt, sustainable competitive advantage is reached more by accident than deliberate choice. Another way to look at it is that she discusses two strategies in particular, strategies that both serve well in a volatile business environment. By continuously reconfiguring the business to fit the current business environment (patching) and by creating simple rules allows an organization to maneuver with agility in the short term. It does not say anything about what the right direction or what business the company should be in. It is in effect, giving up strategy and focusing only on tactics. In Eisenhardt’s view, this is the right choice since finding a sustainable strategic position is very difficult or even near impossible in todays accelerating business context.

An interesting, and I would say even somewhat damaging fact about Strategy as Simple Rules, is that several of the provided examples that in hindsight really should be considered strategic failures: Enron’s simple rules were certainly not right since it eventually led the company to bankruptcy in 2001; Yahoo though being one of the dot-com stars have not done so great after the dot-com bubble burst and Dell is struggling with the competition that has imitated its business model with an innovative supply and channel management. Dell really is a case in point of Porter’s argument on Operational Efficiency from What is Strategy. Although these examples do not invalidate her argument about the benefit of using simple rules, I believe it does illustrate rules more tactical than strategic nature.

The business impact of a more “Porteresque”, long term view of strategy is really that business should be clear on what business it is in. Trying to do things better or be more nimble is not a sustainable position; in the long term the pack will always catch up. Both Porter and Eisenhardt agree that strategy is about being different (What is Strategy, p 62 and the Eisenhardt quote above). This is something I believe to be almost trivially true: you will not be long term competitive by doing the same thing in the same way as everybody else. Thus a business has to think seriously on what it is doing, how it is doing it, who it is doing it for etc and make sure defends this position vigorously. To close with a another military analogy: a company has to choose its battles wisely.

Primary reference sources:

Porter, M. (1996). What is strategy? *Harvard Business Review. *(November-December) p. 61-78.

Eisenhardt, K & Sull, D. (2001). Strategy as simple rules. Harvard Business Review. (January) p. 106-116.

Secondary reference sources:

Porter, M. (2008). The Five Competitive Forces that Shape Strategy. Harvard Business Review. (January) p. 78-93.

Porter, M. (1990). The Competitive Advantage of Nations. Harvard Business Review. (March-April) p. 73-93.

Eisenhardt, K. & Brown, S. (1999). Patching. Restitch Business Portfolios in Dynamic Markets. Harvard Business Review. (May-June) p.72-82.

Recently a couple of New York college students made a stir when they announced that they would write an open source and distributed social network server as an alternative to Facebook. This is really in the true spirit of the internet, where everyone can set up his or her own server and have them commicate, compare e.g. how email works. Incidentally, this is the way Instant Messaging should work but only SIP and Jabber (used by e.g. Google Talk) actually implement. Evidently they have raised about $170 000 in three weeks using Kickstarter, their initial target was $10 000.

I sympathize 100% with their stated goals and will make sure I set up a Diaspora Seed once they make their first release.

More information on the Diaspora blog.

As you may know Agile software development is inspired by the principles of Lean Manufacturing which in turn is derived from the Toyota Production System (TPS). One Agile methodology, Lean Software Development even borrows the name Lean to make the connection explicit. Since the principles in Lean and TPS have much in common with how Japanese always have approached manufacturing and that TPS supposedly permeates the whole of Toyota, it comes as a real surprise that Toyota uses a waterfall process for software development!

At the thanksgiving dinner of a friend from work I tried to explain REST-ful applications – and I think I failed miserably. Even though there are plenty of good introductions out there I felt I needed to organize my thoughts a bit. Having some spare time on the train on the way home I made a second, more structured attempt in the form of this blog post.

Imagine you are a web developer and is asked by a friend with a travel agency to help out create a web site for his company. Among the services on the site is a small web application for searching for hotels recommended by the agency. These hotels have been carefully vetted for the agency’s customer segment and useful hotel information is stored in a database.

Let us assume the web application manages the namespace under the URL

http://qualitytravel.com/hotel

One way to construct the application is by storing e.g. navigation state in a server side session or as post parameters in the HTTP requests. Or maybe use an AJAX user interface where parts of the page is updated asynchronously in the background. These approaches are, however, incompatible with the basic requirement of you friend the the travel agent, who frequently copies the URL of a particular hotel and sends it per email to potential customers. He would also like his customers and all other users of the web site to be able to send URLs, create bookmarks etc. Only by creating stable, re-usable URL’s is this easily accomplished. Thus you decide on a basic categorization scheme where each hotel is listed under

http://qualitytravel.com/hotel///

Where is the two letter ISO code for the country, the city name in english using only ascii characters and is a unique name of the hotel (unique at least within the country). By typing in a URL like

http://qualitytravel.com/hotel/se/stockholm/grand-hotel

… in a web browser you would end up with the HTML page describing the Grand Hotel in Stockholm, Sweden.

Your friend is very ambitious but would like to start out small. Uptime is of course important but not critical and you offer to host the site on your server at your place for a minor fee per month. (This would help pay the electricity and internet connection bills.)

Now, your friend has a business partner who organizes conferences in different countries around the globe. The business partner would like to link to specific hotels on your site, hotels your friend has arranged special deals and have pre-booked a number of rooms for. Since you are using stable and predictable URLs this is no big deal, for any particular conference the business partner can easily add the reference on a web page, add them in emails sent out to the participants and even in printed hard copy.

As the partnership between your friend and his business partner deepens, the business partner would like tighter integration between the two web sites. In particular he would like to create a mashup application where each conference has a map with all the hotels printed at the correct geographic location. Since your friend has stored the exact geo location of each hotel in his database it should not be too difficult to achieve.

Being well versed in XML and enterprise standards you now ponder a bit on web services. You could of course create a web service with a method which would accept a list of hotel identifiers and return a list coordinates… After some deliberation you come to the conclusion it would be easiest to use the URLs as identifiers. They are unambiguous and you do not have to expose the primary keys of the database to the internet and there is no need to create new unique external identifiers. On top of that adding the identifiers to the mashup will be easy since the URLs are already used on the conference web page.

Thinking a bit further you realize that in the future there potentially is  more information which could be useful, not just the coordinates. Right now you do not know exactly what information that would be, but if you return a list of XML documents containing basic information on each hotel and with geo-coordinates, you can always expend the XML document format to include additional information at a later stage. At least as long you are careful to keep the format backwards compatible. This you do by not changing the meaning and syntax of the existing XML and make sure the XML elements have the same position relative to the root element (i.e. that the XPath for the elements is stable).

Finally, you realize that instead of taking the pain of having to create a web service with SOAP, WSDLs etc you decide that each hotel URL should return the corresponding XML if the client asks to get the hotel information in XML format instead of HTML. This can easily be accomplished by using the standard HTTP content negotiation, i.e. the client sends a list of desired formats and the server responds with a document in one of the formats if it can.

The changes to the existing application are relatively minor, you only need to implement the content negotiation feature and in addition to render HTML you will need a mechanism to render XML. (In Java, using servlets, servlet filters and a templateing mechanism sounds like a good approach.)

The result is a huge success. Business is booming for your friend and traffic to your server is increasing at an alarming rate. You are sure that any minute your ISP will knock on the door telling you you are violating the fair use clause of your contract. In addition, uptime is becoming more of a concern. If not for the load so at least for redundancy you need two servers. You decide to move the web site to a hosting facility. Since state is not kept in a server side session you realize that clustering will be trivial. Each request is independent of the previous meaning it can land on either server without complication. This also means adding more servers to handle a larger load will be a breeze.

Some time later your friend has found an additional business partner – this guy for some reason wants to create an AJAX client which uses the hotel information. The AJAX guys, programming in client side Java script, do not really like XML and prefer something called JSON. Would it be possible to add JSON support? In addition it would be nice if you could create a downloadable PDF for each hotel…

Having the infrastructure already set up, all is needed is to add two new rendering templates, one for JSON and one for PDF’s and add the two new formats to the lists served by the server.

–

*The above scenario describes using REST – REpresentational State Transfer – for building a web application. The text strives to illustrate the fundamental REST-ful principle of decoupling the reference of an object from its actual representation. It can also be said that in REST you take a resource or document oriented approach to software development, i.e. development is data-driven. This is opposed to service orientation with an RPC style of defining interfaces where focus is not on the data but rather on what you do with data; the focus is on the verbs instead of the nouns. In REST the actions are a well defined minimum like the four most well known HTTP verbs: GET, POST, PUT and DELETE. Above, only the implied use of GET is shown.
*

Using REST principles is not constrained to web applications. It has been suggested that REST should be used instead of SOAP based web services in a SOA architecture, thus imbuing some of the webs scalability and robustness in an Enterprise Integraion scenario. Gartner has termed it WOA for Web Oriented Architecture. WOA can be seen as a more constrained version of SOA.

It has even been suggested that REST is useful within applications. How this can be done is described in four articles on The Server Side. Beware though, although well written they end up being a plug for NetKernel, a REST-ful application server built on something they call ROC – Resource Oriented Computing. I would say the jury is still out on question whether using REST internally in an application is a good alternative or not.

References

Wikipedia has a well written article on REST:

http://en.wikipedia.org/wiki/REST

Web Oriented Architecture

*http://hinchcliffe.org/archive/2008/02/27/16617.aspx
*

*The Server Side, A Restful Core:
*

http://www.theserverside.com/tt/articles/article.tss?l=ARESTfulCorePart1

http://www.theserverside.com/tt/articles/article.tss?l=ARESTfulCorePart2

http://www.theserverside.com/tt/articles/article.tss?l=ARESTfulCorePart3
http://www.theserverside.com/tt/articles/article.tss?l=ARESTfulCorePart4

In a famous post from January this year (which I missed) Ann Thomas Manes declares SOA dead. She is a Reasearch Director within the Burton Group, has worked with SOA in the Burton Group and elsewhere, and is a co-author of the WS-* specifications.

The post has sparked fierce defense from vendors like Oracle. During the half day SOA Architect forum in Geneva this Tuesday, Oracle spent the first seminar repeating that “SOA is not dead” like a mantra, I guess in order to reinforce the message. It seemed to be one of the mayor points they wanted to get across.

Excerpt from Ann Thomas Manes post SOA is Dead; Long Live Services

Successful SOA (i.e., application re-architecture) requires disruption to the status quo. SOA is not simply a matter of deploying new technology and building service interfaces to existing applications; it requires redesign of the application portfolio. And it requires a massive shift in the way IT operates. The small select group of organizations that has seen spectacular gains from SOA did so by treating it as an agent of transformation. In each of these success stories, SOA was just one aspect of the transformation effort. And here’s the secret to success: SOA needs to be part of something bigger. If it isn’t, then you need to ask yourself why you’ve been doing it.

The latest shiny new technology will not make things better. Incremental integration projects will not lead to significantly reduced costs and increased agility. If you want spectacular gains, then you need to make a spectacular commitment to change. Like Bechtel. It’s interesting that the Bechtel story doesn’t even use the term “SOA”—it just talks about services.

And that’s where we need to concentrate from this point forward: Services.

This falls in line with my understanding that SOA without BPR/BPM/Transformation really does not amount to much. You need the entire organization to support a process and service view on business and IT in order to see real benefit.

In another post SOA is Dead? It’s About Time by Kurt Cagle acknowledges Ann Thomas Manes view but complements the picture with adding that

Perhaps my biggest reservation about SOA had to be the fact that, at the end of the day, it was still an RPC model that concentrated primarily on calling APIs that differed from one provider to the next. The result of this thinking is the sea of APIs, where there are now tens of thousands of APIs, each of which doing things a little (or in some cases, a lot) differently from one another, with very little cohesion, and with little thought to the semantic complexity that comes when you have that many microlanguages all competing for programmer attention.

Purists may argue that over time the SOA model (especially the SOAP/WSDL model) had been moving towards a more messaging-oriented architecture, but I’d counter that all that a messaging queue does is to decouple the receipt of the message from the response – if the message processor invokes a service, it is still an RPC, especially when transactions are involved.

This is one of the reasons that I think that resource oriented services – RESTful services – are beginning to gain real traction even as the big-box SOA projects are falling to the accountant’s axe. The publish/subscribe model in which what you’re publishing are not blogs but data documents (think XBRL or HL7) performs the same type of decoupling that message-oriented SOA did, but completely abstracts the intent from the process of communication.

This is consistent with my view that SOA, which if done correctly, should be document or data driven and should rely on messaging. As an alternative to an ESB used mainly for RPC over SOAP Web Services, I think that an REST-ful approach should be seriously considered when attempting SOA. Some thinkers at Gartner have started talking about a WOA – Web Oriented Architecture – as further constrained subset of the SOA approach based on REST principles.

I believe the change will be heavily resisted by companies like Oracle and IBM since there is less money to be made on the simpler and less tool/platform-intensive REST-ful approach to enterprise computing. Also they all have invested heavily in the WS-* and RPC-style SOA corner and thus are reluctant to change. But change will come sooner or later and the ongoing economical crisis will be a strong driver.

In the Java world there are several ways of handling dependencies between project components in a shared development environment. Maven is a generic build tool that creates a standardized way of creating, building and publishing component artifacts. Dependencies between the different components are declared in a Maven build file and Maven automatically downloads the dependencies and all transient dependencies recursively from local or public repositories. Repositories can be local to a particular developer, department or enterprise; or they can be public, available to the development community at large. Ivy is another utility which focus solely on dependency management. It is positioned as the lean and simple alternative to Maven which focus only on the dependency aspects and that integrates well with Ant (the generic java build tool).

For .NET based solutions there does not seem to be neither a Maven nor Ivy style dependency management system for development. This article outlines a solution to dependency management in the .NET world that has been inspired by the Maven and Ivy.

Outline

The Global Assembly Cache (GAC) is where .NET dependencies are handled. Assemblies installed in the GAC are made available for fulfilling the dependencies of DLL’s inside or outside of the GAC. The GAC does not, however, reach outside one machine (real or virtual). In order to handle dependencies in a team development environment, where dependencies are shared, a distributed version of the GAC is envisioned, the Universal Assembly Cache or UAC.

The UAC is a repository with layout identical to the GAC but where dependencies can be downloaded using HTTP or FTP protocols and published using FTP or Web DAV. Repositories can be chained and when retrieving dependencies, chained repositories are searched in sequence one after another.

Command line tools

As for the GAC the UAC should have command line tools to manage the UAC. The command line tools would be used to download a DLL and all its dependencies not fulfilled by what is already installed in the GAC and then install the downloaded libraries. Likewise a DLL found in the file system or in the GAC could be published to the UAC and thus made available to other parties.

In addition MS DOS and command line tools the same functionality should be available as .NET PowerShell cmdlets. For mono on Linux, commands in a suitable script langue should be considered.

Visual studio Add-On

To facilitate dependency management during development a Visual studio add-on is used to check the references of each project in the solution. At startup, on demand or optionally for each build, unresolved references are searched for in the UAC and if found, installed in the GAC or put in a common solution folder. Ideally the Add-On is integrated as an additional tab in the Add Reference dialogue.

Similarly to Ivy and Maven, Visual Studio references to a given DLL can be to a specific version of a DLL or they can be according to some kind of dependency resolving strategy (Ivy latest strategy). As an example, the latest minor version of a component for a given major version can always be looked for. Switching to a new major version should be done manually since it is assumed this would nearly always break the build.

Publishing a DLL should not be possible through the add-on since publishing should be done in a more controlled environment than a developer desktop . Instead publishing should be done as part of an automated build system

Build Tools

In order to accommodate build engines all functionality required for a build should be replicated in NAnt and MS Build tasks. In addition there should be tasks for publishing DLL’s to the repository.

A while ago I reflected on Object Oriented Programming and the fact that it really is more about classes than objects. Reading up on Newspeak, the new langugage proposed by Gilad Bracha I came across Self, one of the language on which Newspeak is indebted to. In Self no classes exists, only objects. More on this later.

Crystal Clear is the smallest of a series of methodologies for software development, all created by Alistair Cockburn. It is smallest in the sense of the project size it addresses (up to eight developers) and in the number of things it prescribes. Other Methodologies, deriving their names from the colors of crystal, are increasingly heavier. They all share the same “DNA” though, which is “expressed” differently with increasing project size and criticality, the latter meaning the higher cost in terms of money or at the extreme human life.

The book in itself has an interesting setup where each chapter addresses an aspect of Crystal Clear in a different format, tone and style. The purpose of this setup is to appeal to a large audience where each reader can find at least one chapter that conveys the essence of Crystal Clear to her clearly. The most peculiar chapter is probably the one where an ignorant Alistair queries a fictive Crystal character over a series of letters about the inner workings of a successful software development team; thus mimicking a Socratic dialogue. I am not sure this stunt works in practice, but at least true to the intent some chapters work better for me than others… All chapters are, however, still written in an easy and personal prose.

In the first chapter Cockburn discusses methodologies in the context of the skill set of the practitioner – somebody who masters software development probably need not pay too close attention to the exact steps in any given methodology since she understands the deeper principles and is able to derive what actions are needed from the principles in any given context. True to this the book’s reading instructions call readers experienced in Agile development methods to read the last chapter first and then (after they stop smirking) go back to read certain key chapters. Knowing something about Scrum and XP this is exactly what I did, including the smirking part…

Chapter 9

Distilled (The Short Version)

At the end it is time to roll it all back up again: What is the core of Crystal Clear, and what puts the team farther into the safety zone? This chapter is very short.

Crystal Clear is a highly optimized way to use a small, co-located team, prioritizing for efficiency, habitability, and safety in delivering a satisfactory outcome. The brief description of Crystal Clear for level-3 practitioners is just this:

The lead designer and two to seven other developers
in a large room or adjacent rooms,
using information radiators such as whiteboards and flip charts,
having easy access to expert users,
distractions kept away,
deliver running, tested, usable code to the users
every month or two (quarterly at worst)
reflecting and adjusting their working conventions periodically.

The team members establish the safety properties below using the techniques they consider appropriate. The first three properties are required in Crystal Clear, the next four get the team further into the safety zone.

1.Frequent Delivery
2.Reflective Improvement
3.Osmotic Communication
4.Personal Safety
5.Focus
6.Easy Access to Expert Users
7.A Technical Environment with Automtaded Tests, Configuration Management, and Frequent Integration

All the other pages in this book only expand on this page.

The above is the entire chapter and it really does succeed in summarizing Crystal Clear.

Patterns

Crystal Clear does not require any particular techniques but Cockburn still mentions a number of patterns of particular importance or not often seen elsewhere (according to the author). The patterns are divided in Strategies and Techniques. I find the Exploratory 360˚, Early Victory, Blitz Planning, Process Miniature and Side-by-Side Programming the most novel and interesting. Others like Walking Skeleton (aka Tracer Bullet or Spanning Application), Incremental Rearchitecture, Information Radiators, Methodology Shaping, Reflection Workshop, Daily Stand-Up Meetings and Burn Charts are, at least to me, well known from other Methodologies such as Scrum and may be considered standard practice; i.e. they are good patterns but hardly novel or unique in Crystal. The two remaining techniques Delphi Planning Using Expert Rankings and Essential Interaction Design are a bit too involved to my taste but may serve their purpose in some circumstances.

Exploratory 360˚
Simply put the Exploratory 360˚ strategy means that the project team should perform a gap analysis on all that is required to run a project successfully. In particular it also means to cover topics that really are the responsibility of others outside the development team, like the fact that there is proper funding and that the proposed project really has a clear recipient who wants the project to succeed. Cockburn supplies a list of the most common things to check for but there may be additional things particular to the organization or the project’s circumstances. If the gaps revealed are too wide or many the project can (and probably should) be terminated early and if nobody else have brought this to management’s attention it is the responsibility of the development team.
The Exploratory 360˚ strategy is something that is close to being self evident but I would guess often forgotten when starting a new project.

Early Victory
Many projects start out with the most difficult tasks first in order to minimize the risks. While this may be sound in theory, giving the team members an easy task to start with will boost morale when the team succeeds in it as well as show the sponsor(s) that the team is performant. Addressing the most difficult task first and then failing can be catastrophic for the team’s spirits and very late first delivery may erode the team’s credibility.
While I have given team’s easier tasks to start with in order to get things going I have never thought of it in terms of an Early Victory and as a reason to celebrate.

Blitz Planning
The Blitz Planning technique is similar to XP’s planning game or Scrum’s Sprint Planning but Blitz Planning uses index cards in a new, creative way. The project sponsor, developers and end users gather together and brainstorm on all the tasks that need to be done to deliver the system. Cards are collated and duplicates removed. The developer most likely to perform a task should make estimate on how long it will take to perform it. The tasks are then arranged in sequence on a large table parallel tasks are placed side-by-side and sequential tasks top to bottom. The sequence is divided in iterations and releases and cards are moved around to optimize development, to fit the sponsor’s priorities, make an Early Victory or a Walking Skeleton and so on. The planning may very well reveal the need for additional resources, change in scope etc. The outcome of the Blitz planning is a draft project plan.
What I like with the Blitz Planning is the simple and cooperative fashion in which the project plan is derived. Using index cards on a table makes changes easy and the result is very graphical.

Process Miniature
In order to learn a lengthy and/or complicated process a miniature version of the process may be run in a few minutes to a few days depending on the process being learned. If it is a development process, only trivial functionality may be developed or what is being built may simply be faked. Using Process Miniature is a variation of learning by doing but where the learning is substantially accelerated.

Side-by-Side Programming
In Pair Programming is a controversial technique in Extreme Programming. Some people find Pair Programming wasteful though proponents of XP claims it saves time in the end due to the lesser number of defects found in the final product. While this may be true some people simply do not like to program in pairs. An alternative to Pair Programming is Side-by-Side Programming where two developers sitting side-by-side with workstation of their own, helping out and reviewing code continuously. A similar effect as with Pair Programming is achieved but possibly with less wasted time.

Summary

What is interesting about the Crystal series of Methodologies (Clear, Yellow, Orange, Red) for software development is that they are founded on Alistair Cockburn’s interviews of people in successful software development projects, often in a fixed price, fixed scope contract situation. Agile methods are adaptive and often at their best in an explorative situation where the neither the scope nor the resources required are known beforehand. Thus Agile Methodologies are difficult to handle with a fixed price and scope. This begs the question as exactly what makes Crystal different. After reading the Crystal Clear I am still not clear on exactly why it should work better in fixed price and scope situation – the only reason seems to be developer participation in making estimates and a focus on always producing a workable system. And this is something that Crystal shares with all Agile methods.
Crystal Clear is probably the lightest of the Agile Methodologies I have come in contact with so far (mostly Scrum and XP) and this makes it true to its intent – it really is the minimum set of rules that could possibly work.

Since Clear only is applicable for projects up to eight developers due to its requirement of Osmotic Communication and many projects are substantially larger, it would be interesting to see how the ‘genetic code’ is adapted to fit larger projects. I guess I must read Cockburn’s other books as well…

I 100 sidor för dig som hellre käkar taggtråd än kontaktar kunder ger Carola Forshell en grundläggande lektion i hur en säljprocess för försäljning till företag bör läggas upp. Boken är baserad på hennes personliga resa, från någon som avskyr sälj till en som arbetar som säljare på heltid och dessutom utbildar andra i konsten att sälja.

Upplägget utgår från en rekommenderad säljprocess med början i identifiering av potentiella kunder (prospekts) till avslutande faktura med påföljande merförsäljning. Varje steg hanteras i ett eget kapitel och i appendix återfinns mallar och checklistor. Som motvikt till denna idealt strukturerade process kryddar författaren boken med anekdoter från egna misslyckanden inom sälj. Vad man möjligen kan sakna är mer en ingående diskussion om de problem som kan uppstå längs vägen och hur man bäst kan hantera dessa, men kanske det med rätta faller utanför denna första introduktion.

Bokens titel är dessvärre, om än fyndig, något missvisande. Alla som är intresserade av att lära sig en mer strukturerad säljprocess har nytta av boken, inte bara de som hellre käkar taggtråd än kontaktar kunder. De som faktiskt råkar ha en fobisk inställning har inte mer hjälp av boken än det exempel författaren själv utgör på att det faktiskt går att övervinna sin egen rädsla och ett par grundläggande tips. Tips som exempelvis det stöd man har i att vara väl förberedd inför ett möte och att skapa en enkel ritual kring kalla samtal för att inte förhala processen.
Detta till trots är boken mycket läsvärd – både lärorik och underhållande. Jag rekommenderar den varmt till andra tekniker likt mig själv eller andra som söker en introduktion till sälj.

In Beyond Software Architecture, Luke Hohmann addresses all things paramount to software product development that are usually not covered in books on software development. These things include licensing, software protection, branding, marketing and business plans and how they relate to the technical architecture and more. Every developer or architect that has been around a few projects probably will probably recognize the importance of some, if not all of these areas, in relation to creating and sustaining a winning solution.

The first and probably most important topic covered is the relation between the business model and the technical architecture. It is really an understatement to claim that the chosen business model has a serious and real impact on the technical architecture – it should be self evident that there the architecture will look quite different in an ASP scenario and a single user desktop application… Less self evident is the relation between the business plan and the technical architecture. What business segments are being targeted and in which order really does bear on the architecture. Each business segment will have its particular needs to be addressed as features in the software solution. The order is important since it will help spell out the technical roadmap for future releases.

The book covers a large number of topics and gives advice on a number of specific issues, too many to cover here. I have chosen but a few that have stuck after finishing the book.

Marketecture

The relation between development and business is generally acknowledged to be difficult and fraught with miscommunication and misalignment of goals. There are many books and methods addressing this gap between IT and business. Hohmann contribution to closing this gap is to distinguish between what he refers to as the Marketecture and the Tarchitecture. The Tarchitecture is short for technical architecture and its definition is similar to what other refer to as system or application architecture, i.e. it covers things like components and their relations, which patterns are used for what parts of the application, technologies, platforms and so forth. The Marketecture should contain all things related to the business side of the system or application. This includes business segments, the business model and plan, user manuals, marketing materials etc.

Closely related to the two architectures are the corresponding roles, the Marketect and the Tarchitect. The Marketect role is usually shouldered by the product owner, business manager or similar whereas the Tarchitect is the traditional systems or application architect or perhaps in some cases an IT-manager. It is rare for the two roles to be handled by the same person since the two perspectives can be difficult for one person to manage simultaneously.

The Marketect and Tarchitect should work closely together to create the Marketecture and the Tarchitecture. This is of course easier said than done, but to me the value of Hohmann’s definitions is primary in making the Marketecture needs visible. Coming from the IT-side, I believe this too often be neglected by the business side and often poorly understood by development.

Capabilities versus features

A minor point made by Hohmann (and perhaps trivial to many architects but enlightening to me) is the difference between a systems capabilities and features. The system’s capabilities are all the functionality made possible by a certain technical architecture whereas the systems features are the features actually implemented. Implementing a feature where the system lacks the capability means changing the underlying architecture. To me this seems different from the anti-pattern designing for the future. A good architecture has relevant capabilities making implementing the desired features easy, but this does not mean that a lot of time has been spent on implementing features that are not needed. It simply means that sound architectural choices have been made creating a sound system. This could be a fine line, however, since making constraining choices that limits the system’s capability, are sometimes necessary.

Release checklist

In appendix 1 a release checklist is found, summarizing the many of the core concepts in the book. This checklist seems like a sound thing to run through not only before each release, but also at the start of a development effort. Running through the list just prior to a release it may be too late to take care of things missed i.e. it will incur what can be referred to as a technological debt (a term used in the book but first defined by Ward Cunningham). Incurring a technological debt means that the development team will have to work harder in the next release to fix the things missed in the previous release and that quality suffers.

Patterns

The book sports A Pattern Language for Strategic Product Management found in the appendix. This pattern language defines common problems related to product development and proposes simple solutions. More thorough descriptions of the problems and the proposed solutions can be found in the beginning of the book.

Usability

Hohmann addresses usability in a chapter of its own. Usability in this context goes beyond user interface design and has a deeper, structural meaning. He stresses the need of a good metaphor that should permeate the whole architecture. This is reminiscent of the thoughts behind Domain Driven Design, though this is not mentioned in the book. A usable application or system should cater to the real users as found in each market segment. An application sold to two different segments may be very usable to one, but not to another. Consider for example an application that targets both an expert and amateur segment. Helpful wizards that guides the user through difficult steps may be very useful to the amateur but not to the expert or power user.

Summary

Beyond Software Architecture is a good read for architects and developers who wish to expand their view on Software architecture and development. It succeeds in addressing issues often neglected elsewhere in literature on software development. As with many more high level books, however, I believe the business side to benefit most from this book. A better understanding on the business choices and their technical consequences is often needed and the need for seriously addressing the business and technological should be recognized.

While browsing the The Server Side’s list of Most Requested Content for 2007 I ended up reading about Google’s algorithm MapReduce, Grid Computing and Giga Spaces. For the (admittedly rare) cases where the applications really have to scale to huge loads (read Google, eBay etc) JEE app servers do not seem to cut it. This is probably because there is no support for Grid Computing /massive parallellization.

Being a Spring advocate I am not at all surprised to read that there are some people that feels the time is ripe to replace JEE application servers with something new. Kimchy believes the Giga Spaces /Open Spaces is a precursor to such a next generation application server, much like Hibernate was to JPA.

I am not sure whether something like Open Spaces will replace JEE App Severs anytime soon (I need to read up on these, for me, new enterprise patterns in general and the Open Spaces project in particular) but I do agree in his thoughts there is a need to simplify and coordinate many of the services needed to develop a truly scalable application in a new app server like container. A container where something resembling JEE packaging can be used to deploy and manage applications.