• High availability architecture concepts
• Spring Integration basics
• Competing consumers
• Challenges with competing consumers

The high availability architecture concepts were presented to frame the session.  There was little depth of discussion or new ground covered.  The same could be said for the section introducing the basics of Spring Integration.  The guys did a good job of describing competing consumers and the challenges of using competing consumers for ‘Single Source’ processing.

For the remainder of the session Gary and David discussed the solution they were developing for EMC.  I was interested in particular to hear what the presenters had to say on the subject of ‘Single Source’ processing in a HA environment as we have similar problems to be solved at Paddy Power.  If you are new to this type of processing I think you will find the content a little difficult to follow and if you are not new to this you probably won’t take a lot away from the discussion.

It was quite a frustrating session to watch as there was a significant amount of time spent trying to execute the demo application.  I would have liked if their own solutions were described more concisely and contrasted against some of the other solutions as leveraged by a number of peer-to-peer protocols such as chord.

He starts his presentation with a high level overview of the Spring Security framework and the variety of support it provides.  For those who have not used Spring Security this was quite informative and for those who are familiar with the framework it was a useful recap.  Spring Security is organised into the core framework and a number of extensions that provide support for OAuth, SAML, Kerberos etc.  This was mentioned by way of an overview and not delved into in any depth.

Havig used Spring Security before, I was particularily interested in what is new in version 3.1.  The two additions that I was particularily happy to see were:

• namespace support for multiple http elements
• a stateless authentication mode for RESTful services.

Unfortunately Rob did not delve into the stateless authentication mode.

Much of the session focused on a demo web application (Secure Mail) and how to leverage Spring Security to implement authentication and authorisation.  This was a through walk through the demo application that covered everything from the initial configuration of spring security to session management, user registration and proxy based authorisation.

In particular, I found the section on proxy based authorisation was well presented.  The difference between interface based proxies and class based proxies was explained along with the pro’s and con’s for both.  I also found the tips on preventing Spring Security from permeating into the application source code useful.  I hate seeing dependencies on framework code proliferate application code.

Rob was an informative and engaging presenter and this session is definitely worth watching if you find yourself with a free hour and a half.

Project 6 builds on the LED chase effect that was created by project 5 and adds a potentiometer that adjusts the speed of the chase.  Shame I dismantled project 5 when I finished up on day 1.  It took me a few minutes to reconfigure all the LEDs and connect them to the Arduino.  Once this was done attaching the potentiometer and the update to the sketch was quick and easy.  I skipped the two exercises at the end of project 6 as they were effectively programming exercises.

Project 7 involves creating a single pulsating LED.  This is achieved by doing an analog write to the output pin (the output pin is a digital pin).  An interesting explanation of how we get a digital pin to behave like an analog pin follows with a description of PWM (Pulse Width Modulation).

Project 8 creates a mood light that uses a clear red, clear green and clear blue LED  and adjusts the brightness of each to simulate a range of colours.  The sketch was interesting as it managed the transitions so that transitions from one colour to another were not too abrupt.

Project 9 creates a fire effect using two yellow and a red LED.  The wiring and sketch are more basic than the last couple of projects so there really wasn’t a lot to this project.

Project 10 uses the same circuit as project 8 but uses the serial monitor to manually input commands to the Arduino.  Simple commands allow manual control of each of the LEDs individually.

Project 11 puts away all the LEDs and starts to play with some of the other components, namely the Piezo Sounder and the terminal block.  The circuit is trivial but we start to see new functions within the sketch that control the Piezo Sounder.

Project 12 uses the Serial Temperature Sensor to output temperature readings to the Serial Monitor.  There appeared to be an issue (which I caould not find the source of) that caused my PC to freeze when I connected this circuit.  It seemed to be a problem with the sensor itself.  This was the first problem I had with the kit so far.

Project 13 uses a light sensor to adjust the rate at which a LED flashes.  Normal service resumed and after putting together the circuit and downloading the sketch the LED reacted to the lighting as expected.  I’m a little relieved that there is nothing wrong with the board!

I’m not going to finish projects 14, 15 and 16 as the next thing I want to try is to control the Arduino from a Java program.  But that’s for another day.

Figure 1: The Arduino Board

Project 1 in the book involved connecting an LED and resistor to the board (using a breadboard) and writing a short sketch to make the LED blink every second.  While it was pretty straight forward, I was quite pleased when it all went to plan (I think trouble shooting would be beyond me at this stage) and the little red LED started to flash when I uploaded the sketch to the Arduino.  The book then reviews the C code (which I skimmed over) before providing an overview of the hardware for the project.  Its on the hardware side that I will find my challenge so I needed to read this section carefully.

Project 2 used the same hardware configuration but changes the sketch to signal S.O.S in Morse Code via the LED.  Given this only involved a rather simple sketch and the same hardware configuration I did not find this interesting.  On to the next project.

Project 3 simulates the light sequence on a set of UK traffic lights; that is, red, red-amber, amber and green.  Given the two previous projects this was pretty straight forward.  Different resisters were used this time so that the LED’s were not as bright as in the previous projects.  Given the additional components, I can see now why a strong table lamp is a necessity for this type of activity. Anyway, I’ll press on without one.

Project 4 adds a set of pedestrian lights (red and green) and a push button to the previous project.  Steady state shows the traffic green and the pedestrians red.  On pushing the button, the traffic is shown amber then red.  The pedestrians are then shown green.  After a little time passes the green pedestrian light flashes before changing to red.  The traffic lights then transition to amber and then green thus completing the sequence and returning to the steady state.  The circuit was straight forward although given the number of components I had to recheck the connections a couple of times.  I also made the mistake of placing and LED the wrong way around thus it did not illuminate.  This was easy to detect and diagnose.  The code itself was fairly straight forward.

Project 5 creates a LED chase effect.  Both the hardware and sketch are straight forward but given it uses 10 LEDs and 10 resistors it is fairly time consuming.  I worked through it anyway for completeness.

So far it has been fun learning about the Arduino and I’m looking forward to working my way through the other projects in the accompanying book.  It’s getting late so time to pack up for today.  Hopefully I’ll get some time over the Christmas holidays to tackle the rest of the projects.

Now, I wanted to write code and not comments so this did not come naturally but on my best days I would diligently comment every class/method declaration and adorn non-trivial methods with a liberal spattering of the same.  After a while I noticed the amount of noise produced by comments that added no value or that were no longer relevant was a considerable distraction.  In fact, this distraction was increasing the maintenance cost rather than reducing it as I had previously been told.

Since then much has changed and the publication of books such as The Pragmatic Programmer, Clean Code and The Clean Coder has changed the perceived wisdom surrounding the commenting of code.  The authors of these books suggested that better code maintainability will come from writing better code (who would have thought!).  By better code they meant code that is easier to understand but how do we write code that is easier to understand.  A good start is to:

• Use descriptive class and method names.
• Do Not Repeat Yourself
• Write SOLID code.
• …

Given the way in which modern logging frameworks work, using descriptive class and method names also increases the value of your application logs.

Bob Martin said that “The proper use of comments is to compensate for our failure to express yourself in code. Note that I used the word failure. I meant it. Comments are always failures.”.  I’m a little more open to comments and still see the value in class and public method comments (please, no bean accessor and mutator commenting!) but regardless of each individuals personal preferences for comments its is good that people are thinking about the subject and doing what makes most sense for them rather than blindly commenting everything.

The ‘Messaging for Modern Applications‘ session at SpringOne 2GX starts by talking about the trends in modern applications. Much of this reiterated the information in the key note session by discussing the diversifying of user platforms and applications, massive scale of data requirements and the continuing emergence of Cloud computing. Tom McCuch points out that synchronous communication protocols have often led to brittle architectures that evolve slowly. Much of this is due to the fact that often components are coupled in time, their release cycles require significant co-ordination etc. Components are typically stateful leading to scalability challenges that can be met by asynchronous architectures that retain state within messages passed between components. I tend to agree with this assertion (generally!).

Moving on, Tom speaks about Spring Integration and its ability to simplify building of messaging application components. I’ve used Spring Integration many times before and found its alignment to the Enterprise Integration Patterns catalog (see www.eaipatterns.com) and the messaging DSL meant a reasonably gentle learning curve for what is a very powerful framework. Coupled with Spring Bean Profiles this creates a great mechanism for decoupling the messaging implementation so that different implementations can be used in different environments (particularly useful for integration testing). The tried and tested Coffee Shop demo was adapted and wheeled out to demonstrate many of the concepts.

I was particularly interested in the section focusing on AMQP and its support within Spring Integration and RabbitMQ. As with the rest of the Spring portfolio, Spring Source are working to make it easier to deliver applications using these technologies from concept to production. This all encompassing approach is one of the reasons Spring has become so popular and it’s good to see that this has not changed.

One of the slides presented contained a statement that really rang true for me. It was that “Existing middleware impacts agility by tightly
coupling applications to underlying application server and other middleware components”. Again, I would agree that there are few exceptions to this statement. Of course, Spring Integration aims to reduce this coupling through its many abstractions in the same way that Spring did for J2EE.

Tom finished up this session by discussing RabbitMQ. He briefly covered its support for AMQP, clustering, federation etc. It peaked my interest enough to look into it further.

Thoughts

Similar to the key note session, I found the content really interesting. For such as session I think the pace was a little slow and Tom could have rattled through the material a little faster. Worth a watch if you can spare the 90 minutes it runs for.

The session was introduced by Ben Alex who discussed 4 key computing trends:

• Diversification of user devices.
• Increase of internet bandwidth and stagnation in network latency.
• Reducing cost of data storage.
• Reduction in clock speed and increase in number of processor cores.

These trends are having a significant impact on how we are developing applications today and will increase in relevance into the future. This paved the way for a number of discussions on how to exploit these trends to deliver tomorrows applications.

Next Generation Clients

Because of the increasing diversification of user devices developers must find a way to bring the ‘Write Once, Run Anywhere’ philosophy to the client. Spring Source are working on delivering this promise by supporting development using Html 5 and JavaScript while using bridging frameworks such as Phone Gap to ensure these applications have access to native features and are available through existing app stores.

Keith Donald demonstrated a reference architecture (expense application) built using Html 5, CSS, JavaScript and Phone Gap on the client. Authorisation utilised OAuth while services were exposed using a RESTful API. He also did a demo of pushing application updates. Compelling stuff!

Next Generation Authorisation

Craig Walls and Roy Clarkson then presented on authentication which focused on the utilisation of OAuth and Spring Security. Interesting in the context of access control for RESTful services but fairly typical application of OAuth to provide SSO.

Next Generation Data

Html 5 application caching was touched upon and a demo of the previous expense application was performed using a disconnected device. Big Data was then discussed and placed in the context of the Spring Data project and its sub-modules. I’ve not looked at Spring Data in any great depth but really liked some approaches adopted by the Spring JPA sub-module (which was not covered in this session).

Next Generation Architecture

Finally, Tim Fox closed by discussing the adoption of asynchronous application architectures to deliver the massive scale that today’s applications are expected to achieve.

Thoughts

It was a really enjoyable session that was interesting and informative. A broad range of topics were covered by presenters who are clearly very knowledgeable.

I think overall, a really compelling vision of how developers will meet the challenge of delivering tomorrows applications was provided.

For that reason, it was with much anticipation that ‘Continuous Integration’ was published back in 2007 (shame on me for only reading it now!).

Getting Started

The book starts of with a gentle introduction to the subject providing a preview of the material to come. Chances are that if you have purchased this book that you already know roughly what CI comprises and how it works so you won’t learn a lot here. Still though, its good to lay some ground work and review that activities that typically occur as part of a CI system.

Introducing Continuous Integration

Next we cover a number of practices that encapsulate what I would call the discipline of CI. It is not enough just to have this thing called CI running in the background and expect it to protect you from all evil. You must:

• Commit Code Frequently
• Fix Broken Builds Immediately
• Write Automated Tests
• Run Private Builds
• Avoid Broken Code

These disciplines must be followed religiously because if one person on the team fails to adhere to them, the entire CI system is devalued. My experiences have always reflected the the broken windows theory, as the frequency of broken builds increases, people become more tolerant of them and thus the build breaks more often.

Reducing Risks Using CI

So, CI is principally about integrating early and often to reduce risk, reduce defects and increase quality. A number of scenarios are outlined along with the rationale for why CI can help alleviate the problems illustrated by those scenarios. Again, while there was nothing ground breaking for me, the information was well presented and did a good job of conveying some use cases for CI.

Building Software at Every Change

The book examines each of the activities that form part of an effective CI system. This begins with building the software. Some of the points made like centralised software repository, consistent directory structure etc. are so ingrained that today we often take this for granted. Source code repositories and dependency management solutions have become part and parcel of software development.

It was useful though to highlight that CI builds should be capable of ‘Building for any Environment’ and come in the form of a private build, integration build and release build. In order to maintain a rapid feedback cycle, you might also utilise stage builds that execute varying levels of testing, code analysis etc.

Continuous Database Integration

Continuous database integration is one of the activities of a CI system that is easy to get wrong. Done right, it removes a lot of frustrations from the development process. I often see teams who spend inordinate amounts of time tracking down issues with data, its structure or storage. There are lots of options to achieve continuous database integration ranging from in memory databases up to dedicated instances and these are explained in detail.

Continuous Testing

When most people think about continuous integration they immediately think about automated testing. Automated testing plays a major part in the continuous feedback that makes CI so compelling.

In order to get the most out of automated testing its effectiveness must be measured. This is typically achieved through code coverage tooling but is all coverage equal? Automated testing can also be time consuming and so should be categorised to facilitate different execution frequencies depending on the type of testing being carried out. This is discussed in a clear and informative manner.

Continuous Inspection

I remember when I started writing code in a corporate environment (yes, way back then!). The first thing I was given was a document describing the style in which code was to be written. After a while, I got to look at actual code and found that it bared no resemblance to the style guide I had been given. This sort of quality check is far better automated.

But we can go even further and actually gather some insight by using other quality metrics. Starting with duplicate code and moving on to measures such as cyclomatic complexity, afferent coupling and efferent coupling we can get a real insight into the overall quality of our code base. Using tools like Sonar, these quality metrics can be tracked over time to measure improvement or deterioration and have an impact on the processes and techniques adopted by a project or product team.

Continuous Deployment

Having implemented a process whereby software is automatically build, integrated and tested the next logical step is to automate the deployment of the software. This is an area where there are significant return on investment to be had. Software deployment is often complicated and involved. Automating this process frees up developers to do what they enjoy and more importantly are being paid to do (or maybe what they are paid to do and more importantly enjoy!!). It also reduces the time lag from the cost of producing the software to releasing the value of that software.

Continuous Feedback

The book finishes by discussing the ways in which a CI system can provide feedback to the development team. The default mechanism of email can so easily be ignored. Alternatives such as flashing or coloured lights, SMS and audible feedback are discussed.

Thoughts

Although I was very familiar with much of the material, reading this book was a useful refresher. It is well written and easy to follow. It is certainly not a “how to” book but you will walk away with a firm grasp of the theory. There are lots of sources of information related to how to implement specific CI systems.

It may or may not be due to my technology background, but I found the book a compelling read. The google story on its own is one of a meteoric rise that pitted a young, highly motivated and infinitely talented company against the establishment. More interesting for me though was the personal experiences and the insight into how all those people, individually very talented, melded together to create the biggest technology success of the internet era.

I thoroughly enjoyed how, chapter after chapter, Douglas described the significant milestones of Google’s growth story. Each milestone describes how the individuals involved were challenged and how they responded to the challenge. Naturally, the interactions with Larry and Sergey were of particular interest.

Since Fielding’s dissertation, REST has been adopted widely by the software industry and a number of frameworks have evolved that support the development of RESTful services on today’s platforms. The availability of frameworks to simplify the implementation of RESTful services has further accelerated the adoption of REST.

As with any new technology, creating frameworks that make it easy to adopt that technology can, and in the case of REST has, become a double edge sword. I say this because making technology adoption easy also makes it easy for those implementing that technology to get by with a minimum of understanding. ‘REST in Practice’ aims to inform those adopting REST by providing a compressive guide to REST and building the readers knowledge progressively from start to finish.

The Web as a Platform for Building Distributed Systems

Rest in Practice begins by providing a high level description of the infrastructure of the web including resources, URIs, caching etc. The term ‘Resource’ is defined along with its relationship to URIs. Resources are of course fundamental to REST and it is important to distinguish between a resource and its representation. Brief mention is given to how the web supports loose coupling, business processes, consistency and scalability. The introduction of the Richardson Maturity Model is particularly useful in understanding what level your REST services are at and where you might need them to be. The notion of hypermedia as the engine of application state is introduced as part of the model and is covered in more detail later.

Introducing Restbucks

I often find that technical books are easier to follow when an example is taken from conception to completion as part of the learning experience. Rest in Practice leverage’s the same example Gregor Hohpe used when explaining interaction patterns (Your Coffee Shop Doesn’t Use Two Phase Commit). For me personally, this was a good choice as it was a scenario I was already familiar with having read Enterprise Integration Patterns and associated material on the companion web site. More generally, it is an easy scenario to follow and something most people can relate to.

The scenario interactions and message formats are described before briefly introducing the modelling of protocols and state transitions.

Basic Web Integration

The public API of a REST service consists of URI templates and the message payload (headers and body) definitions. URI templates should strive to be intuitive and URI tunneling is discussed in detail in the context of the Restbucks example. The fundamental properties of the GET verb frame the discussion on why not to use URI tunneling to modify a resource.

A number of other integration approaches are described including XML over HTTP and XML-RPC.

CRUD Web Services

CRUD Web Services sit at level two of the Richardson Maturity Model. The majority of REST services I discuss with colleagues or interviewees would sit at this level. Often it is the case that little awareness exists of more sophisticated services. CRUD services are what most people think of when REST is mentioned. The HTTP verbs POST, GET, PUT and DELETE are introduced as are there utilisation within a RESTful service. Once again, these concepts are placed in the context of the Restbucks scenario.

For the most part this chapter does not introduce anything new. Of more interest was the application of ETag and If-Match headers to provide safety and idempotency. Interestingly, the chapter rounds up by stating that ‘CRUD is good, but it’s not great’. I tend to agree!

Hypermedia Services

Things start getting interesting when the authors introduce hypermedia services and the domain application protocol. A domain application protocol specifies the legal transitions from one resource to another. It informs the consumer of a resource of available transitions to other resources in the same way the html links inform a web browser of transitions to other web pages. Within the context of an enterprise application, this facilitates the representation of state machine like behaviour.

An immediate impact of providing hypermedia services is that consumers now only need to know how to enter the system. They will then transition to other resources via links embedded in resources. This reduces the coupling between the consumer and the application (because only the semantic meaning of the links are shared, the location can be changed without any impact on the consumer..they just follow the new link).

The value of hypermedia services are brought to life when applied to the Restbucks scenario.

Scaling Out

One of the most impressive characteristics of the web is its shear scale. When talking about the web as a platform, it would be remiss to omit how its scale is achieved and how this might apply to scaling RESTful services within an enterprise. The scale of today’s web can be attributed in part to the caching mechanisms employed by its infrastructure and the HTTP protocol itself. As anyone who has built a caching solution of any significance can testify, caching is a complex business that involves decisions on the sensitivity of the data, liveliness of data, expiry policies etc. These topics are discussed in the context of RESTful services.

The Atom Syndication Format

The typical enterprise approach to building event based systems is to utilise a messaging system of some form or other. Messaging systems that support point-to-point and publish subscribe paradigms are perfect for this type of requirement. On the web, Atom Syndication can also be used to the same effect and this is described in detail with examples in Java and .NET.

Atom Publishing Protocol

Building on the previous chapter, the atom publishing protocol is is described as a ‘domain application protocol for publishing and editing web content’. I’m not completely convinced about the advantages above an beyond those provided by HTTP itself.

Web Security

A layered design is used to provide a robust approach to security on the web. This starts at the transport layer with SSL and is built upon at the protocol later through the Basic and Digest authentication mechanisms provided by HTTP.

Significant air time is given to OpenID and OAuth which I did not find entirely interesting. In most enterprises, other mechanisms will already have been established and be leveraged by any RESTful service implementation.

Semantics

Having recently completed a course on knowledge based systems and the semantic web I found the discussion on semantics interesting. That said, I’m not sure that most people will find it entirely relevant as semantics will typically be agreed as part of a RESTful service specification as opposed to dynamically. Nevertheless, those with an enquiring mind or an interest in the future of the web will find this chapter interesting.

The Web and WS-*

A lot of people who come to look at REST have previous experience of the WS-* stack. This section reviews some elements of the WS-* stack and provides a comparison with REST. The similarities between the two approaches are also identified before a discussion on the differing approaches to security and transactional messaging. Finally, WS-* is placed at level 1 on the Richardson Maturity Model.

Building the Case for the Web

The authors wrap up by ‘building a case for the web’. They align the proven features of web architecture to the requirements of enterprise architecture. This includes attributes such as scale, latency, cost and security.

Thoughts

It has only been in the last year or so that I have started to utilise REST and before that I had only a cursory knowledge of the architectural style. Then a requirement landed that had REST written all over it but I needed to know more before pinning my colours to the mast. To this end I looked for some learning resources that would fill the gaps in my knowledge and I found this book was a great aid. I read it cover to cover and found each chapter built on the next to provide a comprehensive understanding of the fundamentals.

I find often that when I discuss REST with those who have been utilising frameworks such as JAX-RS etc. that there is often a gap in knowledge of the fundamentals of REST and the maturity of REST services. In particular, I’m disappointed that few are aware of the Richardson Maturity Model or of the notion of hypermedia as the engine of application state. Having read this book, I now know that building CRUD services is only the entry level of what REST services can be. If you think you are doing REST but are not sure what the fuss is about, read this book and get a real understanding of the power of REST.