Key enhancements include:

• Significant performance improvements
• A free unique code generator for generating and downloading up to 1000 unique codes

The latter was included since using the SOAP API, released last November, is an investment. I wanted to see the tool being used and tested rapidly and the unique code generator is one way to do that.

an inherit conflict of interest in between the Development Manager and the Project Manager.

In my opinion the role serves as an essential counter weight, and by that I mean a counter weight to short term profit oriented actions in software development projects that end up killing long term profitability.

Before we get onto the iptables rules, here is the exact scenario to give this post context.

1. We have a system under test, which has a public IP address, and a remote test server which also happens to have a public IP address.
2. The system under test accepts REST calls on port 443, that is we are dealing with HTTPS traffic.
3. The system under test, in response to REST calls, will fire asynchronous REST callbacks to our remote test server, so we are dealing with bi-directional communication.
4. A corporate firewall dictates that the asynchronous REST callbacks can only happen on port 80 or on port 443.
5. Our remote test server already has a service running on port 80, so our HTTP listener, that waits for incoming REST callbacks, will have to run on another available port, say 8009.

So, here is the configuration that we will have to do on our test server.

# For a manual check of the rule below, run $sudo nc -l -v 8009 then ssh into the remote host (303.66.500.90) and execute $nc -v -z 55.333.536.4
iptables -t nat -I PREROUTING 1 -p tcp -s 303.66.500.90 --dport 80 -j REDIRECT --to-port 8009

Please note that the IP addresses where randomly generated. The rule above means that on our test server (with mentioned IP address 55.333.536.4), we’ll route traffic from our system under test (with IP address 303.66.500.90) on port 80 to port 8009. Presumably our test HTTP listener will be listening on port 8009.

Thats it, its working for me, hope it does for you too.

$ sudo apt-get install jenkins

If we have a service running on port 8080 Jenkins won’t start.

$ sudo tail /var/log/jenkins/jenkins.log

In such a case, lets change the port, and we’ll do so in the config file.

$ sudo nano /etc/default/jenkins

If this is a public server, lets add in authentication, and we’ll take the quick route by adding the following to the end of the JENKINS_ARGS (naturally change the password to suit):

–argumentsRealm.passwd.admin=topsecret –argumentsRealm.roles.admin=admin

The configuration up to this point is not enough when it comes to a public web server, since the world at large can still see our main Jenkins page, but its a start, since at the very least we have administrative control. We would still want to run our service over https and add http basic authentication, with the latter entailing fronting Jenkins with Apache and configuring an AJP connector between Jenkins and Apache.

If you are in  rush though, or just don’t want to install and administer Apache, you can use matrix-based security to disable read privileges for anonymous users, it is easy to lock out your sole admin user if you do this though, and if you do (as I did), you’ll have to shutdown Jenkins, edit /var/lib/jenkins/config.xml and in false in <useSecurity>true</useSecurity> and start it up again. All you’ll have to do is to follow the instructions on this page for matrix-based security exactly (the sign up step seems odd, but it seems necessary). After you have signed up, disable read access for the Anonymous user and you are good to go.

Upgrading

/usr/share/jenkins$ sudo service jenkins stop

/usr/share/jenkins$ sudo mv jenkins.war jenkins_old.war

/usr/share/jenkins$ sudo wget http://updates.jenkins-ci.org/download/war/1.480.3/jenkins.war

/usr/share/jenkins$ service jenkins start

The quick and dirty answer is just do this: singleFoo.getBars().size();

There it is. End of story. It is worth noting that I’m an advocate of using a Service Facade and DTOs, in other words clean APIs and I use Spring’s transactional annotations on the service layer. Also, you will come across posts mentioning Hibernate and initialization methods, this doesn’t help since we are only interested in pure JPA here.

Sure there is alot more to it and there are pitfalls to consider, that is old news, any layer of abstraction comes at it price and in some way dumbs you down (mmm, getting philisophical, its so easy to do).

This is one of the posts I was referring to, and it was a distraction: Avoid Lazy JPA Collections. A better read would be this one: JPA Implementation Patterns: Lazy Loading

I’d already been a Spring user for roughly 2 years, predominantly using 2.5.6 is a commercial setting, and had always wanted to do the Spring Core course, especially since there are areas of Spring 3 that I don’t use and don’t always get the time to work with when it comes to my day to day tasks.

What I liked about the course:

• The lecturer, who made the notes come to life. I had no idea who would be lecturing, as it turned out Spring sent a highly experienced industry veteran with a PhD in computer science, Dr. Paul Chapman.
• The student pack with notes, lab notes and preprepared SpringSource Tool Suite so we could get stuck into the labs without struggling with environment issues. Awesome.
• The labs, 30 to 45 minutes and they never cut corners, its all about best practices and Spring sticks to its guns all the way.
• The venue, with a view over the whole of Wellington.We had regular breaks with coffee and great cookies.
• The lunch vouchers and chatting to the lecturer and fellow students over lunch.
• The pace, we covered a broad spectrum of topics and roughly 12 labs. At an academic university these 4 days would have been spread over a semester.

I have a simple requirement, and that is to publish an artifact containing a SOAP wsdl and an accompanying set of Java classes, predominantly generated from the wsdl.

For now, I don’t want to, nor have the time to, spend hours researching the most appropriate license, all I want to do is to retain all my rights, in particular commercial rights, when it comes to my wsdl, as its my intellectual property. So, having already spent a few hours on this, including reading informative posts such as “Pick a License, Any License”, I’ve come the the conclusion that the best course of action is to pick the MS Reference License as a base and naturally I will be the Licensor, not Microsoft, and naturally there will be no platform restriction.

So, this is my way of getting my feet wet, perhaps I’m going down the wrong road, perhaps not.

The focus here is on getting it all working, not the most efficient solution, and neither the most secure. We choose a UsernameToken with plain text password and work that into the wsdl, then generate code with the Maven cxf-codegen-plugin, then find a way to add the missing security headers and finally write an integration test.

In terms of context, the steps below where followed in a project where a web service was implemented, and already thoroughly tested using the help of jetty and the maven-soapui-plugin with the latter executing tests during the integration-test phase.

Step 1: Modify The WSDL

The pretinent parts of the this wsdl are shown below. Note the wsp:PolicyReference below the wsdl:service element.

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:sch="http://vouchertool.com/vouchserv/schemas"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://vouchertool.com/vouchserv/definitions"
targetNamespace="http://vouchertool.com/vouchserv/definitions"
xmlns:wsp="http://www.w3.org/ns/ws-policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsdl:types xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
...
<wsdl:service name="VoucherServiceService" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
  <wsp:PolicyReference xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" URI="#VouchUsernameToken"/>
  <wsdl:port binding="tns:VoucherServiceSoap11" name="VoucherServiceSoap11" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
    <soap:address location="http://vouchertool.com:80/vouchserv/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"/>
  </wsdl:port>
</wsdl:service>

<wsp:Policy wsu:Id="VouchUsernameToken">
  <sp:SupportingTokens>
    <wsp:Policy>
      <sp:UsernameToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
        <wsp:Policy/>
      </sp:UsernameToken>
    </wsp:Policy>
  </sp:SupportingTokens>
</wsp:Policy>
 

Step2: Code Generation In Our Maven Pom Using cxf-codegen-plugin

<plugin>
  <groupId>org.apache.cxf</groupId>
  <artifactId>cxf-codegen-plugin</artifactId>
  <version>${cxf.version}</version>
  <executions>
    <execution>
      <id>generate-sources</id>
      <phase>generate-sources</phase>
      <configuration>
        <sourceRoot>${basedir}/src/main/java/</sourceRoot>
        <wsdlOptions>
          <wsdlOption>
            <wsdl>${basedir}/src/main/webapp/WEB-INF/wsdl/vouchserv.wsdl</wsdl>
            <extraargs>
              <extraarg>-verbose</extraarg>
            </extraargs>
          </wsdlOption>
        </wsdlOptions>
      </configuration>
      <goals>
        <goal>wsdl2java</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Step 3: Add A HeaderHandler and HeaderHandlerResolver

This post shows how to add the security headers. It works, try it. You’ll need some solution since the code generated by cxf will not provide any means of adding the headers, which is naturally suboptimal.

Step 4: Test It All Using An Integration Test

public class VoucherServiceIT {

@Test
public void test() {
  URL url = null;
  try {
    url = new URL("http://localhost:8080/vouchserv/vouchserv.wsdl");
  } catch (MalformedURLException e) {
   throw new RuntimeException(e);
  }

  VoucherServiceService voucherServiceService = new VoucherServiceService(url);
  HeaderHandlerResolver handlerResolver = new HeaderHandlerResolver();
  voucherServiceService.setHandlerResolver(handlerResolver);
  VoucherService voucherService = voucherServiceService.getVoucherServiceSoap11();
  RegisterRequest registerRequest = new RegisterRequest();
  RegisterResponse registerResponse = voucherService.register(registerRequest);
}

}

The voucher service was created as a reusable generic component intended to ultimately avoid having to reinvent the voucher management wheel which has no doubt been done countless times. Tutorials, extensive documentation and sample applications will be published as soon as time allows.

Performance Tests: Does Concatenating n Strings Really Take Time Quadratic in n?

Joshua Bloch, in Effective Java, advises that using the concatenation operator repeatedly to concatenate n strings requires time quadratic in n due to strings being immutable and the need to copy the contents of both strings when performing a concatenation operation.

In terms of Big O notation, the above means O(n²) or O-n-squared, which is disastrous time wise. To see just how disastrous, here are the results of 4 runs of a simple test, the 5th run was stopped since I was not willing to wait approximately 40 seconds squared.

The results show an exponential increase in time when looking at the concatenation time column and since big O time estimates are not exact, one can say yes, concatenating n strings really does take time quadratic in n.

If you’d like to run the tests on your machine, please find the simple program used below.

public class StringConcatenationPerformance {

	public static void main(String[] args) {

        final String base = getBaseString();
        int CONCATENATIONS = 1000;

        long startTime = System.currentTimeMillis();

        String result = base;

        for(int i = 0; i < CONCATENATIONS ; i++) {
            result = result + "b";
        }

        long estimatedTime = System.currentTimeMillis() - startTime;

        System.out.println(result.length());
        System.out.println(estimatedTime);

        startTime = System.currentTimeMillis();
        StringBuilder builder = new StringBuilder(base);
        for(int i = 0; i < CONCATENATIONS ; i++) {
            builder.append("b");
        }
        estimatedTime = System.currentTimeMillis() - startTime;
        System.out.println(builder.toString().length());
        System.out.println(estimatedTime);

    }

    private static String getBaseString() {
        StringBuilder builder = new StringBuilder();
        for (int i = 0; i < 1000; i++) {
            builder.append("a");
        }
        return builder.toString();
    }

}

String Concatenation: Under The Hood

Eyal Lupu has kindly done the hard work of opening the hood, meaning that he used the javap utility (java class file disassembler) to look at the generated byte code of a concatenation loop.

His results show that the following:

String result = "";
for (int t=0; t<10000; ++t ) {
 result = result + getSomeString();
}

Results, in effect, in the following:

String result = "";
for (int t=0; t<10000; ++t ) {
 result = new StringBuilder(String.valueOf(result)).append(getSomeString()).toString();
}

The above created 10 000 Strings on the heap, 10 000 StringBuilder objects, then there is the additional cost of, within StringBuilder.append, allocating an array large enough to fit our characters and copying characters from the old smaller array to the larger array.

References

1. Under the Hood of Java Strings Concatenating Performance, Eyal Lupu
2. java String concatenation, Tom Hawtin
3. Effective Java, Second Edition, Joshua Bloch, Item 51: Beware the performance of string concatenation
4. Java String Concatenation, Joseph Kulandai
5. Stivlo