Overview

First, I’ll cover some of the products that are being leveraged in this demo scenario. I have already mentioned some but to be more specific:

• IBM Integration Designer (IID) (previously known as WebSphere Integration Developer)
  From the IBM product page, “an Eclipse-based software development tool that renders your current IT assets into service components for reuse in service-oriented architecture (SOA) solutions.”. In simpler terms, it takes a bunch of business workflows, interface mappings and integration points described in XML and written in Java that can be deployed into a IBM Business Process Server.
  It also comes with an integrated Business Process Server test environment that allows a developer to deploy a project locally for development and testing purposes from the IDE. From within this environment, a developer can also export an ear file build that gets deployed to a Business Process Server.
• IBM Rational Team Concert (RTC)
  In a nutshell: integrated source configuration, work item, tracking and planning and build management. RTC integrates with IBM Integration Designer so that these capabilities are part of thedevelopers working environment. From here, the IID developer, can check in those workflows, mappings, interface definitions and other code, start builds (either personal or team) and collaborate with other developers through work items in an all-in-one integrated experience.
• UrbanCode Deploy
  Considering that this blog finds its home in the UrbanCode Blog, I won’t waste too many words about its functionality as the multiple blogs by my colleagues do a great job already. If you’re new to this product, this page gives an excellent description. For the purposes of the demo scenario, I’ll be using the WebSphere Application Server – Deployment Plugin and the built-in integration with RTC’s build system to provide automated deployment to IBM Business Process Servers (which are essentially WebSphere Application Servers with Business Process Management capabilities added).
• IBM Business Process Manager Advanced (BPM) (includes IBM Process Server; formally known as WebSphere Process Server)
  This contains the IBM Business Process Server that takes artifacts authored using IID and brings them to life. Any application (EAR) file that has been build using IID can be deployed to the IBM Business Process Server and it will start the required interfaces and bind the integration points as described by the workflows designed in IID. We will use UCD in combination with RTC to automate this process.

The relationships between the products in a topology would look something like this:

Product Roles

To make the demo realistic, I wanted to create a setup that somewhat reflected reality so I start out by setting up several BPM environments: Development (DEV), Integration (INT), Quality Assurance (QA), and Production (PROD). There are teams responsible for developing the code base that gets deployed onto these BPM servers. That is, they each have their own source code stream in RTC (besides PROD which receives build via promotion from other environments).

Environments and Teams

The teams and environments are described as follows.

• Development: This is representative of one more teams, each being principally responsible for the development of a product component (sometimes called a component team). The Development team’s team builds get deployed into the DEV environment.
• Integration: This team is responsible for maintaining a clean status of the integration build, the build that is backed by an integration stream (INT) that contains all the changes from all development teams. As there is the possibility of merges occurring, especially in a BPM scenario, the integration team is responsible for working across the development teams to ensure that merges occur cleanly.The INT BPM Server contains the build which integrates all teams’ builds prior to quality assurance subsequent to production.
• Quality Assurance: Integration Builds will be going through the rigor of QA testing and may contain additional artifacts (translation, legalese). There is an additional quirk in that a QA build can contain fixes performed by the Quality Assurance team that have not yet been integrated into development (now that’s agile!). This is why QA also has an RTC stream and build.
• Production: A production server heavily wrapped in red tape: approvals and gates. There is no RTC stream, as this is primarily a release engineering team.

For this blog post, I’ll demonstrate the end-to-end continuous integration scenario for deploying a DEV build, so we’ll just be dealing with the Development (DEV) stream but you will see the other streams, environments and teams reflected in the setup and the screenshots.

Setup

Describing the setup in some detail goes a long way to explaining the scenario, so let’s dive right into it. You can follow along but you will need to already have the IBM Business Process Manager Advanced and IBM Integration Designer products. As they are no publically downloadable evaluations or trails you’ll need to contact an IBM Sales representative to arrange one or already be entitled. There is, however, evaluations of UrbanCode Deploy server and Rational Team Concert for which I provide the links for below.

• UrbanCode Deploy Server
  I downloaded and installed a UCD Server on a server machine. If you don’t have UCD, you can fetch a trail version from here.
  If you are not sure about how to install UCD, you can find documentation here.
  There is nothing special about the install itself, I installed a versioning UCD agent on the same machine although it’s unused when using the RTC build system integration as builds are pushed from RTC’s build engine (Jazz Build Engine/JBE) and do not need to be pulled from UCD. (Pulling versions requires a versioning agent.) I install it anyway to get rid of the warning on the UCD page about a missing versioning agent but this is optional, you can simply ignore the warning.
• UrbanCode Deploy WebSphere Deploy Plugin
  I downloaded the WebSphere Application Server – Deployment plugin, as for all intents and purposes installing an EAR file into IBM Process Server is identical.
• RTC Server installation
  I downloaded and installed RTC on a machine. If you don’t have RTC, you can download a version that’s free for 10 developers. If you are not sure about how to install and set up RTC, you can find documentation here.
  Remember to set the public URL of the RTC to something that is accessible from the UCD server and from the developer’s workstation, which will have IID with the RTC client integration.
• IBM Business Process Manger Advanced Servers
  1. I installed IBM Business Process Manger Advanced on all machines which constitute the environments (DEV, INT, QA, PROD) that will receive builds to deploy. The detailed installation instructions can be found here.
     I Installed the BPM into C:\IBM\WebSPhere\AppServer (as I was using a Windows machine)
  2. The UrbanCode Deploy Agent was installed on each of the BPM and connected them to the UrbanCode Deploy Server. This will allow the ear files built by the RTC Build Engine to be deployed into BPM.
  3. We also need to install the RTC Build System Toolkit on these machines. You can download the RTC Build System Toolkit here; it will need to be connected to the RTC server on start-up.
     As I installed BPM on Windows machines I created a build directory in C:\build that looks like this:
     
     

     Build Directory

     
     The startJBE.bat just contains the following line as I unzipped the Build System Toolkit into the root of C, https://demo:10443/ccm is the public url of my RTC server and I am using a demo user to connect. (You’d normally want to create a build user for these purposes.) I created a build engine definition in RTC called dev so that the build engine knows which RTC build engine definition it attached to. (More on this later). Pass.txt contains the encoded password for the demo user.

     C:\jazz\buildsystem\buildengine\eclipse\jbe.exe -repository https://demo:10443/ccm -userId demo -passwordFile pass.txt -engineId dev

     (It should be noted that these machines are great candidates for a Blueprint in UrbanCode Deploy Blueprint designer.)

  4. 1. Development Workstation
        The developer workstation has the IBM Integration Designer with the RTC capabilities installed via the the RTC p2 Install Repository. You can use the Install repository as a local updates site to install RTC from.

Product Configurations

Rational Team Concert

The idea is to set up a project area and several teams which are responsible for maintaining a team stream (responsible for development of some aspect of the system being deployed). Each team has a team lead and there could also be several other developers working on the teams. Each team member is responsible for ensuring that their team stream adopts changes from other teams via the integration stream and at the same time delivers changes into the integration stream. In doing so, they also need to ensure that they don’ break the team and integration builds. The team lead monitors the team build to ensure that the build and the deployment are green but they also need to ensure the integration stream build and deployment are green. The integration team would be responsible for making sure all changes from team streams delivered into the integration stream doesn’t break the build.

A typical DEV team flow would look something like this:

DEV Team Delivery

In order to shorten an already lengthy post, I will not go through such a large scenario in this blog and concentrate on this one team, DEV though I have set up the structure to respect the work flow depicted. Generally, the same pattern can be applied to the other teams and builds.

Check the RTC Knowledge Center if you don’t know the details of how to perform these operations. These are the things that I did to get the basic flow working:

1. As the RTC administrator user, created some other users in RTC: DEV Developer (devdeveloper), and DEV Team Lead (devlead).
2. Launched IBM Integration Designer and created a connection to RTC using the administrator (demo in my case) in the Work Item perspective.
3. Create a project area called Demo using the Scrum Process and assigned the administrator user as an administrator of the project and to the Product Owner role. I also assigned the DEV Team Lead (devlead) as a project Team Member.
4. I created a DEV team , assigned DEV Team Lead as the Scrum Master and the DEV Developer as a Team Member
   
   
5. In preparation for importing the IID sample project, I created Release 1.0 stream owned by the DEV team with four components:
   1. Library -> Contains the IID sample library project
   2. Mediation -> Contains the IID sample Mediation Project
   3. Service -> Container the IID Sample Service Project
   4. Release Engineering -> Contains the build files

We now have a basic stream setup and we should import some code. I switched to a new IID workspace and logged in as the DEV Team Lead user (devlead). Then I

1. Created a workspace off of the DEV team’s Release 1.0 stream with team visibility (scope) with all components.
2. Imported the IID Hello World sample project completed artifacts which can be imported via the Help->Samples and Tutorials -> IID Integration Designer menu.
   
3. Created a Release Engineering Eclipse project in the Java perspective with the following structure and these two files. These will be the files used by the build, the build.xml is used to communicate with RTC, which the iidBuild.xml uses BPM server service deploy tags to build the ear file. I right clicked on the project context menu, Team->Share Project… and added the Release Engineering Project to the Release Engineering Component in Jazz SCM.
   
4. Switched to the Business Integration perspective, right clicked on the project context menu, Team->Share Project and added the sample:
   
   1. HelloService to the Service Component
   2. HelloWorldLibrary to the Library Component
   3. HellowWorldMediation to the Mediation Component
   4. Delivered into the Release 1.0 (DEV) stream using the Pending Changes view

   

Once the code has been added, we can now create the build engine and definitions. To make things easier, I switch back over to the demo IID workspace as this is also our build user. Then I:

1. Created a build engine called dev which the build engine on the dev BPM machine will bind. There are several properties that are used by the ant scripts that should be defined here:
   

   jazzBuildTookit	C:\jazz\buildsystem\buildtoolkit
   jbePasswordFile	C:\build\pass.txt
   jbeProperties	C:\build\jbe-properties\${buildLabel}.properties
   jbeRoot	C:\build
   jbeWorkspaceRoot	C:\build\workspaces
   wps.home	C:\IBM\WebSphere\AppServer

2. We’ll create a build definition call DEV Service Build owned by the DEV team area using
   1. the Ant – Jazz Build Engine template
   2. The Jazz Source Control pre-build step
   3. Post-Build Deploy post-build step
3. In the DEV Service Build Overview tab, add dev as the Supported Build Engine
4. In the Properties tab set the following properties
   

   build.output.dir	${jbeRoot}/builds
   build.working.dir	${jbeRoot}
   componentVersion	${stream}-${buildLabel}
   library	HelloWorldLibrary
   module	HelloService
   stream	DEV
   team.udeploy.debug	false
   team.udeploy.timeout	480

5. In the Jazz Source Control tab
   
   1. Create a workspace that flows from the Release 1.0 (DEV) stream called Release 1.0 DEV Service Build that is DEV team scoped and contains all the components.
   2. In the Load Options, set the Load directory to ${jbeWorkspaceRoot}/${team.scm.workspaceUUID}
   3. Select Delete directory before loading and all the Accept Options
6. In the Ant tab
   
   1. set the Build file to ${team.scm.fetchDestination}/Release Engineering/ant/build.xml
   2. Set the check mark to include the Jazz build toolkit tasks
   3. Set the Properties file to ${build.output.dir}/${componentVersion}/jbe.properties
7. In the Post-build deploy tab
   
   1. set the Enable flag and deploy if build has no errors or warnings
   2. Do not set deploy for personal builds
   3. Set the Server URI of the UCD server. This is the URL you use to access the UCD web interface
   4. Set a user name, the user needs to have appropriate access to the resource in UCD related to deploying the service component to the DEV environment. For now we can use the UCD admin user. This can be changed later. Test the connection to ensure connectivity.

   Set these properties

   1. Component: ${module}
   2. Version: ${componentVersion}
   3. Base Directory: ${build.output.directory}
   4. Include Files: ${module}.ear
   5. Links: RTC Build Result=${repositoryAddress}resource/itemOid/com.ibm.team.build.BuildResult/${buildResultUUID}

   In the Process Section Enable “Run Application Process” and set

   1. Application: HelloWorld
   2. Environment: ${stream}
   3. Process: Deploy
8. You should now duplicate this build definition and call it DEV Mediation Build. Everything should be kept identical except:
   1. Create and use a new workspace called Release 1.0 DEV Mediation Build that also flows from the Release 1.0 (DEV) stream that is DEV team scoped and contains all the components.
   2. Set the module property in the Properties tab to HelloWorldMediation

At the end of this your project tree should looks something like this:

Make sure not to forget to start the RTC build engine on the BPM DEV machine after which you should be able to create builds in RTC but unless we create the artifacts in UCD that are used by RTC, it won’t deploy.

UrbanCode Deploy

UCD will be much simpler to setup as I have exported the entire application. The only thing you need to make sure is that you have loaded the WebSphere Application Server –Deployment Automation Plugin in the UCD Settings before you attempt to import it or continue. We’ll need some of the resource roles provided by the plugin in order to set up the resource tree in UCD to reflect the BPM deployments.
If the agents were installed correctly they should already be in the Agents tab under Resources.

1. In the Components Tab Create two components called HelloService and HelloWorldMediation, leaving all the defaults. These are just placeholders for now.
2. In the Resource tree
   1. Create a folder called DEV Servers and add the DEV BPM server agent to the folder. This should create a new resource bound to the agent. If you want to keep things simple, rename the resource (not the agent) to dev.example.com as it will already be bound to the environment when you do the application import. (Otherwise you’ll have to bind it yourself)
   2. Click Show->Resource Roles to bring up the resource roles panel and drag WebSphere Cell under dev.example.com and rename it to PSCell1 (the default for BPM)
   3. Modify the entries in the tree to facilitate this path, these are the defaults unless you changed them during BPM install and configuration, in which case use the value from the DEV environment BPM.
      /DEV Servers/dev.example.com/PSCell1/Nodes/Node1/Servers/server1/
   4. Add the HelloService and HelloWorldMediation components directly under /DEV Servers/dev.example.com/PSCell1/Nodes/Node1/Servers/server1/

   When finished the resource tree should looke like:
   

3. At this point is probably worthwhile to define a resource template for the agent so that when configuring the resource tree for other agents, the template can be implied instead of redoing the entire tree. (Unless the cell, node and server names are different for all your servers in which case a template may not be as useful.)
4. Finally, import the HelloWorld.json Application in the zip file and selecting “Upgrade Component If Exists”.
   

Feel free to examine the component processes in UCD and the environment, most of the heavy lifting is done by the WebSphere Plugin and all we do is provide bindings between the RTC build output and BPM.
The last thing is to create users for the DEV Team Lead and DEV developer in urbancode deploy. As I did in RTC, I also created team corresponding to the environments I then assigned DEV Team Lead and DEV developer to the Development team using the pre-packaged manager and developer roles. I then assigned the relevant objects using the team object mappings using the Standard type.
Agent: dev.example.com
Application: HelloWorld
Component: HelloService, HellowWorldMediation
Environment: HelloWorld/DEV
Resource: DEV Servers/** (the entire resource tree)


That should do it; you now have a continuous integration pipeline! To see it in action kick off a build in RTC, this should succeed in create a build record linked to the version that is uploaded to UDC. This version will be deployed using the application process for the specific environment bound to the BPM server. Checkout the following screenshots to see it in action.

As I mentioned previously, the main goals of this rewrite are discoverability and efficiency. We want it to be easier for you to find the configuration you’re after, and faster to make changes when required. We’re also dragging the admin UI from it’s humble lightly-scripted beginnings into the brave new world of HTML5 (we might even drop the quaint “AJAX-powered” terminology from our website ). For example: the new UI makes use of HTML history APIs to finally integrate with the back/forward navigation of the browser.

We’ll be making things more discoverable in two key ways:

1. Providing an overview page for each project, which displays a summary of the main configuration in one place (key details from the SCM, recipes, requirements, properties, stages and dependencies). This will allow you to see what the project is about at a glance, without digging into the details.
2. Making it easier to find where projects override values set in their template ancestors, as these are usually the key things you want to see and/or change. Currently overrides are marked but can only be found by browsing to their specific location in the configuration tree.

On the efficiency side, we also have multiple changes, some more visible than others:

1. Navigating through the template hierarchy will be possible in a consistent way on every configuration page. You’ll be able to navigate to the same configuration in any other project (not just direct ancestors and descendants), where such configuration exists.
2. The project and agent trees will be searchable, making it easy to jump straight to the instance you’re after.
3. As mentioned above, proper browser history navigation is supported so you can easily jump back and forth.
4. Under the covers a lot less data will be transferred between the Pulse master and browser, and the master will do a lot less work. The existing implementation has become heavyweight through multiple iterations and is being replaced with a lighter HTTP-friendly API with more work done on the client.

These are ambitious changes and as such we’ll be launching them in a new major version: Pulse 3.0! The implementation will also lay the groundwork for updates to other parts of the UI, as well as a new config API, although these will be held back for future releases. We prefer to ship sooner and tackle other areas incrementally rather than embark on a full rewrite. As always, while the next major version is in the works, Pulse 2.7 will be actively maintained including minor feature updates where practical.

Now, back to the UI work!

Dependency Injection used was always something very mystical to me. Until I learned what it’s really about.

I’d like to share this revelation with you. So let’s take an easy problem and solve it in couple of different ways.

Cowboy FizzBuzz

The problem is the well-known FizzBuzz Kata. This is the simplest code that makes it work:

public class FizzBuzzCowBoy {
    public static void main(final String... args) {
        for (int i = 1; i <= 100; i++) {
            if (i % 15 == 0) {
                System.out.println("FizzBuzz");
            } else if (i % 5 == 0) {
                System.out.println("Buzz");
            } else if (i % 3 == 0) {
                System.out.println("Fizz");
            } else {
                System.out.println(i);
            }
        }
    }
}

What’s wrong with this code? First of all, it’s very difficult to test.

Then, it’s unnecessarily difficult to make certain changes:

• Collect 5 lines and print them in a separate Thread
• Print the FizzBuzz of the first 20 Fibonacci number.
• Or you could emit Fizz when the number is divisible with 3 or contains the digit 3

Suppose this code plays an important role in a lean startup. You need to make certain statistics whether the email FizzBuzz or the Standard out FizzBuzz is more profitable. So you want to do some A/B testing. Well, that’ll hurt.

Template FizzBuzz

The Template Method Pattern is a straightforward way to decompose this cowboy code into smaller pieces.

This is the template method:

public class FizzBuzzTemplate {
    
    public void doFizzBuzz() {
        getFizzBuzzNumbers.forEach(num -> {
            final String msg = getFizzBuzzText(num);
            printFizzBuzz(msg);
        });
    }
    //...
}

The template above needs three operations:

• getFizzBuzzNumbers
• getFizzBuzzText
• printFizzBuzz

You can find the operations in the same class:

public class FizzBuzzTemplate {
    //...
    protected Stream getFizzBuzzNumbers() {
        return IntStream.rangeClosed(1, 100).boxed();
    }

    protected void printFizzBuzz(final String msg) {
        System.out.println(msg);
    }

    protected String getFizzBuzzText(final int num) {
        if (isDividable(num, 15)) {
            return "FizzBuzz";
        }
        if (isDividable(num, 5)) {
            return "Buzz";
        }
        if (isDividable(num, 3)) {
            return "Fizz";
        }
        return Integer.toString(num);
    }

    private boolean isDividable(final int num, final int div) {
        return num % div == 0;
    }
}

Invoking it

Finally, this is how we can invoke it from a main method:

public class Main {
    public static void main(final String[] args) {
        final FizzBuzzTemplate fizzBuzz = new FizzBuzzTemplate();
        fizzBuzz.doFizzBuzz();
    }
}

A/B testing is a bit coarse-grained. We can use a system property or whatever so we run either FizzBuzzTemplateA or FizzBuzzTemplateB.

Testing the template with test subclass

Now that we have well-factored methods, it’s easy to create a new FizzBuzz solution. Well, actually I already created one when I tested the template method:

public class TestFizzBuzzTemplateWithTestClass {
    // ... test methods that rely on the testing subclass
    private static class TestFizzBuzz extends FizzBuzzTemplate {

        private final List printed = new ArrayList();

        @Override
        protected Stream getFizzBuzzNumbers() {
            return IntStream.of(1, 2, 3).boxed();
        }

        @Override
        protected void printFizzBuzz(final String msg) {
            printed.add(msg);
        }

        @Override
        protected String getFizzBuzzText(final int num) {
            return "TEST";
        }
    }

Based on  JUnit recipes, this is how we should test template methods. See, this is a case when testing makes your code more flexible: we didn’t only test all the parts in isolation but we made sure that we can create new kind of FizzBuzz-es if we want to.

Unfortunately, it takes lots of time to write these test-subclasses. It’s also difficult to read these test. What now?

Partial Mocking

Alternatively, you can test the code with partial mocking, like Mockito.spy:

public class TestFizzBuzzTemplateWithSpy {

    private FizzBuzzTemplate sut;
    private Stream oneTwoThree;

    @BeforeMethod
    public void setUp() {
        final FizzBuzzTemplate template = new FizzBuzzTemplate();
        sut = spy(template);
        oneTwoThree = IntStream.of(1, 2, 3).boxed();
        doReturn(oneTwoThree).when(sut).getFizzBuzzNumbers();
        doNothing().when(sut).printFizzBuzz(anyString());
    }

    @Test
    public void testStreamRetrieved() {
        // WHEN
        sut.doFizzBuzz();

        // THEN
        verify(sut).getFizzBuzzNumbers();
    }
    // ... more test methods
}

Are we happy? No, not really. According to this SO page and to Mockito.spy documentation, partial mocking is a bad practice, recommended only for legacy code. You don’t use this with TDD, they say.

Dependency injection

We can beautify this code even further. We can create method objects for the individual operators.

The parts

One for the numbers we want to process:

public class FizzBuzzNumberProvider {
    public Stream getFizzBuzzNumbers() {
        return IntStream.rangeClosed(1, 100).boxed();
    }
}

Another for deciding what to print:

public class FizzBuzzTextProvider {

    public String getFizzBuzzText(final Integer num) {
        if (isDividable(num, 15)) {
            return "FizzBuzz";
        }
        if (isDividable(num, 5)) {
            return "Buzz";
        }
        if (isDividable(num, 3)) {
            return "Fizz";
        }
        return num.toString();
    }

    private boolean isDividable(final int num, final int div) {
        return num % div == 0;
    }
}

And here is a class for printing the fizzbuzz text:

public class FizzBuzzPrinter {
    public void printFizzBuzz(final String msg) {
        System.out.println(msg);
    }
}

Indeed, there’s a Method Object for printing FizzBuzz to the standard output. Isn’t it this overkill? It depends on what your crystal ball tells you about upcoming requirements how far you want to go for clean code.

Bringing the pieces together

I used constructor injection for this case.

Constructor injection means that an object receives its collaborators in a constructor and stores them. Later it uses them when needed:

public class FizzBuzzManualInjection {

    private final FizzBuzzNumberProvider numberProvider;
    private final FizzBuzzTextProvider textProvider;
    private final FizzBuzzPrinter printer;

    public FizzBuzzManualInjection(final FizzBuzzNumberProvider numberProvider,
        final FizzBuzzTextProvider textProvider,
        final FizzBuzzPrinter printer) {
        this.numberProvider = numberProvider;
        this.textProvider = textProvider;
        this.printer = printer;
    }

    public void doFizzBuzz() {
        numberProvider.getFizzBuzzNumbers().forEach(num -> {
            final String msg = textProvider.getFizzBuzzText(num);
            printer.printFizzBuzz(msg);
        });
    }
}

And this is how they’re wired together in a main method:

public class Main {
    public static void main(final String[] args) {
        final FizzBuzzNumberProvider numberProvider = new FizzBuzzNumberProvider();
        final FizzBuzzTextProvider textProvider = new FizzBuzzTextProvider();
        final FizzBuzzPrinter printer = new FizzBuzzPrinter();
        final FizzBuzzManualInjection fizzBuzz = new FizzBuzzManualInjection(numberProvider, textProvider, printer);
        fizzBuzz.doFizzBuzz();
    }
}

Testing it is quite easy now: you can mock out the collaborators.

Invoking it

It’s easy to add different FizzBuzz implementations for A/B testing: We need some system property that helps us decide which particular implementation we need to inject.

Wrapping up

In this post we could see that the Template Method is a good alternative to Dependency Injection.

Well, good for the FizzBuzz kata. What about real world examples then? Why are there lots of frameworks for Dependency Injection, and only a few for Template Method? Let’s see:

• Template Method won’t create separate code for configuration. That’s a must in complicated projects.
• If you need to flexibly combine the pieces, then you need Dependency Injection.
• If you have heavy-weight, general-purpose dependencies, like an ORM or a Transaction Manager, then Template Method just won’t fit.

Wrapping up, really

You can use Template Method for fairly simple cases. For Big Things (TM) you need Dependency Injection. Later we’re gonna explore that.

Where you can find the code

You can find the code on github: cowboy, template method and manual dependency injection.

• Share information about planned features with non-technical stakeholders easily, and get actionable unambiguous feedback from them
• Ensure and document shared understanding of the planned software, making the definition of done stronger and more objective
• Document software features and APIs in a way that is easy to understand and maintain, so you can reduce the bus factor of your team and onboard new team members easily
• Make any kind of automated tests readable to non-technical team members and stakeholders

DaSpec helps teams achieve those benefits by validating human-readable documents against a piece of software, similar to tools such as FitNesse, Cucumber or Concordion. The major difference is that DaSpec works with Markdown, a great, intuitive format that is well supported by a large ecosystem of conversion, editing and processing tools. Run and play with the key examples in your browser now, without installing any software, to see what DaSpec could do for you.

DaSpec’s primary target are teams practising Behaviour Driven Development, Specification by Example, ATDD and generally running short, frequent delivery cycles with a heavy dependency on test automation. It can, however, be useful to anyone looking to reduce the cost of discovering outdated information in documentation and tests.

For more information on what’s new in version 1.0, check out the release notes.

The first version of DaSpec supports automation using JavaScript only. We plan to port it to other platforms depending on the community feedback. Get in touch and let us know what you’d like to see next.

Now, that left us with a problem. Our core UrbanCode Deploy offering (like its competitors) would be an incomplete solution for the new normal. Well, problem solved.

Today, we're excited to announce that we are including the cloud blueprint capability in UrbanCode Deploy. Existing customers can just download version 6.1.2, upgrade, and have the capability today.

So what new capabilities do UCD customers get today?

• A rich, graphical editor for OpenStack Heat that makes defining new environments easy and fast.
• Full-stack management of applications, being able to promote infrastructure changes with code changes
• The ability to provision or update cloud environments in SoftLayer, Amazon, VMWare and OpenStack compatible clouds.
• Access to sandbox testing environments that are quick to create and destroy.

How does it feel to use these cloud blueprints? It feels like the cloud actually helping our developers deliver quicker. So grab the new bits and start taking advantage!

I recently started to use Apache Tapestry for work.

Tapestry is a web component framework with ambitious goals. E.g. it’s a web component framework that’s easy to extend. Also, it gives you the ease of development of scripting languages within the java ecosystem. Moreover, it provides an Inversion of Control (IoC) container with nice aspect-oriented features too.

This is my learning log: I completed the official tutorial. Then completed an in-house tutorial that shows how tapestry and the other moving parts fit together in our application. Finally, I read the Tapestry 5 book.

Earlier I wrote about its component and scripting parts. Here I’ll dissect its Dependency Injection parts

What is dependency injection?

J.B. Rainsberger wrote an excellent post about Dependency Injection in general. Here is a brief summary:

When an object doesn’t create its collaborators, but instead a caller provides them then, then it’s dependency injection.

So if an object receives its collaborators through the constructor, then it’s constructor-based injection. If it receives them through setter methods, then it’s property-based injection. If the collaborators are automagically set into the fields without constructor or setter then its field-based dependency injection.

Why dependency injection good for us?

It’s good for us because you don’t have to type ‘new’ that often. Pun intended.

Dependency injection has a couple of advantages. First of all, it doesn’t tie one implementation class to another. I.e. your code depends on abstractions like EmailSender while you can configure to use RealEmailSender for production and FakeEmailSender for testing.

Another advantage is that your framework can lazy-load your classes. So you can get the performance benefit without having to write extra code like Proxy pattern. And that’s a great win, even though there’s default class for that.

Funny, huh? When you talk about dependency injection, people will think about long xml configurations and annotation through the code. But that’s just a pattern that Spring and Java EE follows. Here we’ll see how Tapestry implements DI.

But then, what’s an IoC container?

As a one-liner: an IoC container is an actual implementation of the concept of Dependency Injection.

Other than that, an IoC container is a controversial thing. On the one hand, it makes it nicely separates configuration from the rest of your code. On the other hand, it makes you to deal with complicated framework like Spring or Java EE.

Tapestry services

A service in Tapestry is an object that you can inject into your pages. See, in Tapestry calls the dependencies services.

Tapestry has lots of services that help you to do stuff.

First of all, you can configure Tapestry in class called AppModule. Well, that’s not entirely true. Tapestry defines three environments: Production, QA and Test. You can configure then in AppModule, QaModule and TestModule respectively.

This might look a bit like magic. But it follows the usual Dependency Injection pattern. It’s common to see DI configuration in xml, like in Swing and Java EE. But Guice too lets you configure your classes in java.

For Tapestry-IoC, this is not the end of the story. The heart of Tapestry-IoC is a Registry. This is where the services are stored to and retrieved from. This Registry is configured through various modules. There are lots of predefined modules. AppModule QaModule, TestModule happen to be the ones that you can tweak.

A custom service

Let’s pretend there’s a custom service that we need to inject. Basically, it can be anything. I.e. it can help us to persist object into a mongoDB database. It can invoke a complicated calculation in a 3rd party system called AIMMS.

It can also be a FooBar service. A Foobar service has a foo() method that returns a Bar object. From a programming point of view, there’s an object that has some methods that we can invoke from our Tapestry pages.

So, this is our service definition:

public interface FooBar {
    public Bar foo();
}

This interface has a production-quality implementation: FooBarImpl:

public class FooBarImpl implements FooBar {
    public FooBarImpl() {
        // Default no-arg constructor.
    }

    @Override
    public Bar foo() {
        //... doing important stuff
    }
}

And this is how they’re wired together:

public class AppModule {
    public static void bind(ServiceBinder binder) {
        binder.bind(FooBar.class, FooBarImpl.class);
    }
}

Why is this so simple?

FooBarImpl has a no-arg constructor so Tapestry knows how to build the service. There are some sophisticated rules how Tapestry finds the right constructor and injects its parameters – but I’ll skip it for the sake of simplicity.

For the record, you can take more control over instantiation your service: you can write your builder method. In that method you can do whatever you need to initialize your service:

public class AppModule {
    public static FooBar buildFooBar() {
        ExperimentalFooBarImpl fooBar = new ExperimentalFooBarImpl("Haruki Murakami");
        return fooBar.dance().dance().dance();
    }
}

How do you use it?

Tapestry has field-based injection. So you just create a private field, annotate it with @Inject, that’s it:

public class WriterPage {
    //...
    @Inject
    private FooBar fooBar;
    //...
    @OnEvent
    public Object handle() {
        return fooBar.foo();
    }
}

Design issues

You could argue that injecting heavy-weight services into Tapestry pages isn’t right. You could come up with alternatives, like using another IoC container that injects Tapestry into other objects. However, your web pages are going to need an abstract service that they can call on user actions. At the end of the day, you’ll have to inject stuff into your pages.

Still, you could ask, how do we inject not-so-controversial objects into our pages? Well, actually, the @Component annotation injects a Tapestry component. It can inject default components like Select, as well as it can inject your custom components too.

So why didn’t I show examples like this? Because Tapestry provides a built-in method to inject them. Part of this built-in method is the ComponentClassResolver that will find the components if you place them into the right package. Another part is the TapestryModule which has lots of built-in logic. Remember, AppModule is a module that you can tweak. Well, TapestryModule is one that you can not. Still, it’s nice to recognize the IoC methods in its source code.

By the way, I covered components in the previous post.

Contributing Value Encoders

You can not only define new services. You can contribute smaller sub-services to them too. ValueEncoders are a good example for this.

ValueEncoders define how you can serialize and deserialize objects from and to String. They are used to send objects as HTTP parameters. Suppose you want to use a specific ValueEncoder. The only thing you need to do is to write a specific encoder, then contribute it to the AppModule:

publicclassAppModule {
    ...
    @Contribute(ValueEncoderSource.class)
    public staticvoidprovideEncoders(MappedConfiguration<class, <span="" class="hiddenSpellError" pre="" data-mce-bogus="1">ValueEncoderFactory> configuration,final BlogService blogService) {
        ValueEncoderFactory</pre>
<article> factory = new ValueEncoderFactory<article>() {
            public ValueEncoder<article> create(Class<article> clazz) {
                return ...;
            }
        }
        configuration.add(Article.class, factory);
    }
}

So what can we see here?

You can contribute your code in the very same class where you can define the services. All you need to do is to write a ValueEncoderFactory, then add it to the MappedConfiguration. ValueEncoderFactory is a Factory class so Tapestry can defer creating this encoder. MappedConfiguration works like a map so you can add your app-specific configurations.

Benefits of Proxy pattern

Earlier I mentioned the proxy pattern. Tapestry-IoC actually uses proxies for its services – given that the service has one interface and one or more implementations. Let’s take a quick look on some of those benefits:

Service Status

You can check the service status of your web app. All you need to do is to run your app in development mode and type http://yourhost/appname/servicestatus in your browser. See this page for further details.

On that page you’ll see a list of your services. Some of them are loaded while others were not even referenced. So you have lazy-loading out of the box. Compare it with the burden of writing and maintaining it yourself.

Writing lazy-loading is more difficult than you think. See this SO page if you have any doubts.

Method Advices

Proxy objects let you write interceptors. Also known as aspects. These things let you do things before and/or after a certain method runs. These things let you do it very conveniently: you can write this before/after code in one class and apply them to another.

The typical method advice examples are logging, security checks and transactions. No wonder that the CommitAfter annotation is implemented with a method advice.

The HibernateModule (see, another Tapestry IoC module) has this method:

    /**
     * Adds the CommitAfter annotation work, to process the
     * {@link org.apache.tapestry5.hibernate.annotations.CommitAfter} annotation.
     */
    @Contribute(ComponentClassTransformWorker2.class)
    @Primary
    public static void provideCommitAfterAnnotationSupport(OrderedConfiguration configuration)
    {
        // If logging is enabled, we want logging to be the first advice, wrapping around the commit advice.
        configuration.addInstance("CommitAfter", CommitAfterWorker.class, "after:Log");
    }

If you check what CommitAfterWorker does, it’ll lead you to the CommitAfterMethodAdvice. In the advise method we can see the real transaction handling logic:

@Override
public void advise(final MethodInvocation invocation)
{
    //... skipped some stuff for brevity
    if (transaction != null && !transaction.isActive())
    {
        transaction.begin();
    }
    
    try
    {
        invocation.proceed(); // going on with the method being annotated
    } catch (final RuntimeException e)
    {
        if (transaction != null && transaction.isActive())
        {
            rollbackTransaction(transaction);
        }
    
    throw e;
    }
    
    // Success or checked exception:
    
    if (transaction != null && transaction.isActive())
    {
        transaction.commit();
    }
    //... skipped some stuff for brevity
}

Wrapping up

This is what we learned so far:

• Now we know what’s dependency injection and Inversion of Control
• We know that Tapestry has an extensible Inversion of Control framework
• We saw examples on how to extend this framework
• We know that tapestry relies heavily on this framework