Constant Customer Communication

It's important...

Upgrading Spring Security from 3 to 4

There are a few changes to the configuration defaults in the Spring Security 4 release that may initially break your application.

Mostly this applies to applications using XML-based configurations. In the 4.0 release, there was an effort to align the XML-based Configuration defaults with the more recent JavaConfig counterparts.

For starters, turning on DEBUG logging for org.springframework.security will give you some hints.

The first change was in the main Spring Security Filter Chain. The CSRF token filter is added to the filter chain and turned on by default. This may cause your login form submit URL to fail the CSRF check and you will see the following in the log:

06/22/2015 18:26:19 DEBUG org.springframework.security.web.FilterChainProxy (FilterChainProxy.java:324) - /doLogin at position 5 of 13 in additional filter chain; firing Filter: 'CsrfFilter'
06/22/2015 18:26:19 DEBUG org.springframework.security.web.csrf.CsrfFilter (CsrfFilter.java:106) - Invalid CSRF token found for http://localhost/unity/doUserLogin

The change is described in SEC-2347. To restore the previous functionality, you can turn off CSRF by adding a disabled <csrf> element to your <http> configuration. Keep in mind that if you don't have another mechanism for CSRF protection in your app, you really should consider enabling Spring's CSRF.

  <http use-expressions="true">
    <csrf disabled="true"/>
    <intercept-url pattern="/app/login.do"  access="permitAll()" />
    <intercept-url pattern="/app/logout.do" access="permitAll()" />
    <intercept-url pattern="/app/**"        access="isAuthenticated()" /> 
    <intercept-url pattern="/**"            access="permitAll()" />
    <form-login login-processing-url="/doLogin"
      . . .
    />
  </http>

SSL/TLS Integration between Java and .NET

Through the years, I've done a lot of integration between Java and .NET platforms. Mostly things play well together, but every once and while an interoperability issue is raised that I haven't encountered before.

Recently, we had a service written in C# on the .NET 4.5 platform that exposed a custom length-based framing protocol over TCP. Essentially requests and responses are prefixed with length-bytes which indicate the subsequent message length, and the same is true for any variable-length fields within the message itself. We needed a Java 7 client library for this service, so I wrote one that exposed a contextual service API backed by a connection pool. The pool would eventually serve-up reusable secure connections with the SSL sessions being reused as well to reduce overhead.

I had built in support for SSL throughout, but had turned it off in my local configuration for most of the development testing. At this stage, all of our concurrency and throughput tests were passing. However, when we flipped the switch to turn on secure connections, any tests that reused a connection were failing. Breaking the problem down to the smallest reproducible scope, we could recreate the issue with 2 sequential requests.

1. Create secure socket to the service and complete handshake
2. Send request A to the service
3. Receive response to A from the service, OK
4. Reuse previous secure socket
5. Send request B to the service
6. Service never responds with a response
7. Timeout occurs

Out comes Wireshark on both sides to see what's going on...

Too Busy to Improve?

Adopting DevOps

There are many lessons learned (originally outside of software) in lean manufacturing and single-piece flow that profoundly improve an organization's ability to rapidly produce software products and services.

In some companies, the culture maintains a notion that the development group has its own delivery pipeline, separate from the IT operations pipeline. This approach is more of  a delivery conveyor belt anti-pattern. The software team is only ever committed to transporting product to the end of their conveyor. From there, it's off to a different belt and becomes another team's problem.

In contrast, a deployment pipeline delivering value directly to the customer implies a continuous and constant flow. At the very least, it starts with the source-commit (or sooner) and doesn't end until value is delivered to the customer. That pipeline is a common resource, owned and shared by all teams, to deliver products and services directly to the customer as a continuous stream of value. Just like water does not need hand-holding as it flows through a pipeline, the ideal road to production should be fully automated with sensors along the way ensuring quality is maintained.

Spring-integrated Hibernate 3 to Hibernate 4 Upgrade

I recently upgraded a large Java web application from Hibernate 3.6.6 to 4.3.5. Given the level of Spring and Hibernate integration in this application, I also upgraded Spring from 3.2.2 to 4.0.5 at the same time.

This was a relatively painless major upgrade. The application configuration changes were pretty straightforward and the code changes were minimal.

Here are the changes required for this particular upgrade:

Continuous Stream of Value

New customer acquisition, existing customer retention, and continuous improvement are three major pillars for any business. For software products, these needs tend to converge as work items for the software development team.  In fact, the number of items being added to the team's work backlog is directly proportional to the amount of time that passes. Business will always need more features and fixes, deployed in less time. These are constants we can and should rely on. We're engineers after all -- we like reliable. 

Since business value is only realized when work items are deployed to production, monitoring the performance of the software development team directly relates to the three major business pillars above. So how well is the team doing? Is the road to deployment a traffic jam or a high-speed freeway to production? Are releases large and high-risk, or small, frequent, and high-quality?

I've found that in a healthy team culture, using an agile methodology to deploy small, frequent, low-risk, high-quality releases, a natural team velocity is reached that more than meets the business need. As the team establishes a cadence, estimates improve and business teams are bolstered with a high level of confidence in the software delivery process. Much like software teams, they too find a natural cadence and velocity. 

As the teams engage this pull-based work management model, the business leadership is no longer pushing on the delivery process and can maintain focus on customer acquisition, retention, and continuous improvement. Sales teams and relationship managers are empowered with a healthy "can do" support structure behind them. With the teams working together in more positive and efficient ways, customers enjoy a continuous stream of value and the business as a whole is able to maximize growth.