What is Service Oriented Architecture (SOA)?

Here's a youtube video that provides an animatic explanation on Service Oriented Architecture (SOA) seems to be quite simple and easy to understand for those wondering what SOA is all about.

Is SOA dead?

An obituary on SOA was written on the Burton Group blog post at the turn of this year. This subject has been propagated over the net so many times over. The idea is the economy hurled a massive comet into the SOA universe and freeze it into an ice age.

According to the post, "With the tight budgets of 2009, most organizations have cut funding for their SOA initiatives." Which also said, "SOA is survived by its offspring: mashups, BPM, SaaS, Cloud Computing, and all other architectural approaches that depend on 'services'".

I can accept some of the points mentioned, but somehow I got a feeling that there are others who simply "forget" that SOA is dead.  Service-Oriented is an architecture. Talking about how various systems are inter-connected via services, is... talking about a Service-Oriented Architecture ie: SOA. At JavaOne this year, topics on SOA still has loads of audiences.  While it's understandable that many adopters out there got hang up on the term SOA rather than focusing on the "service oriented" part, SOA is still alive and well.

While I agree that mashups and cloud computing has gained significant audience from the masses, after almost the same amount of time to prepare the birth of a baby, the report on the demise of SOA seems a little premature. Give it another wave of financial meltdown in the stock market and the big boys selling expensive solutions may start to wither lacking its food source.

The "free" renegades of the solutions, just like anything viral and nimble will rebirth itself as the survivors of the industry. The needs to provide bridges between the old and expensive to the new and agile by focusing on systems inter-connectivity using services will keep the architecture alive absorbing solutions that make sense for SOA to keep going.

Agile Best Practice of Continuous Integration (CI)

Setup an integration build environment that triggers every 5 minutes! That type of instruction will send your head spinning pretty fast if you don't see what's exactly involved. The purpose of doing so is for a best practice of Agile Software Development called Continuous Integration. For those practicing Agile, this is a familiar term. If you've done iterative software development before, you'll value the need for a continuous integration.

How in the world are you going to trigger a build every five minutes? The next guy wouldn't get a chance to send in his changes! Well, that's exactly where the strength of CI is. Anything missing from the build will become apparent very quickly and the culprit can be quickly chastised if necessary. =) The idea is to find integration errors and tests failure ASAP before the procession of events get further away and costs more to fix.

Martin Fowler introduced CI as follows: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly." (read more here)

The frequent code check-ins and automated build execution helps tightened the feedback cycles to increase software quality. This means not only developer's feedback cycles are increased, it will also increases business users and stake holders satisfaction of the product. Less bugs means less problem at demos and less iritation to the stake holders, which hopefully generates constructive improvement requests.

Back to the crazy 5 minutes automated build frequency, this does not mean the automated build will terminates itself and checkout new codes before it finishes its cycle. Rather the CI mechanism will check if any new changes can be detected in the source/version control system. If there's any new changes then the automated bulid will run until it finished and then wait for the set frequency (in this case 5 min.) and repeats the process. If no changes is detected, then no build is executed.

Apache Maven Basics Video

If you are new to Maven, you may want to read this article written by John Ferguson Smart published by JavaWorld. It's a little old, written at the end of 2005, but I think its still cover the basics of Maven 2. I attended John's session at JavaOne 2009 and I liked it.

There's a video on you tube covering Generating a basic project in Maven 2. I embed it below.