Stay up to date on the latest news from Rubicon Red. News, articles, customer success and press releases.
Industrialized SOA – Where are you? – Part 1
May 05, 2013
In my job I have had the privilege of working on some high profile SOA projects but more satisfyingly I have been able to see most of them through to success. This process can be rewarding but it also has its downsides and it is not (unfortunately) all Greenfields and jelly beans. In fact a lot of what I do is fire fighting and it is not easy rescuing projects on the verge of failure. You know the ones I am talking about, right? The toxic ones… the ones that no one wants to touch with a 10-foot pole.
My wife and I were fortunate to be eating an amazing Indian cuisine cooked by my colleague Arun’s wife (some of you may know Arun from his popular blog on Oracle BPM or as the author of Oracle SOA Suite 11g Administrator’s Handbook). This catch up over great food and wine turned out to be an excellent opportunity to really talk about our passion for software delivery; perhaps much to the boredom of our respective partners.
One of the things Arun had mentioned was that he had recently been impressed by Mark Nelson’s musing about SOA Development & Delivery. As a long-time subscriber to Mark’s blog, I was keen to check it out. So after a sound night’s sleep, I was quick to Google ‘RedStack’ and here it was….
While Mark did not say this directly, it seems clear to me that the SOA brand is tainted (in at least some contexts) and people are asking questions…
Is SOA really agile when you need to wait months for a new complex feature to be released and 15 components are impacted by it?
Does BPM really empower the business when your server goes down and the root cause is not easily discoverable?
Is Cloud really a way to lower risk and increase productivity when the elasticity comes with lengthy periods of non-realised benefits, ramp up and confusion?
If this resonates with you, you are at the very least... not alone.
So what is going wrong? Why in some cases, is the buzz seen to be spin, to be vendor marketing; little more than bended truths?
While I obviously don’t know all the answers I’ll take a stab and say it has more to do with maturity levels and insensible decisions then the failings of SOA and its promise.
As novelist Ellen Glasgow once said “All change is not growth, as all movement is not forward.” and with that I hope you’ll allow me to take this opportunity to wax lyrical on Mark Nelson’s gem by way of a few practical tips learnt in the trenches.
Don’t just version control your source code. Version control EVERYTHING that will change! This includes:
Composite Configuration Plans
WebLogic Deployment Plans
Start-up & Shutdown Scripts
“Health Check” Scripts
Application Server Configuration
(Optionally) The Binaries
Note: This is unnecessary and redundant if you follow good binary management which I’ll discuss in the next blog instalment.
And so on….
…But don’t let version control stop at the source code and configuration assets, you should version control all of your documentation as well. For this, I would strongly suggest a wiki. However, there are plenty of expensive EDRMS’ out there too if you prefer to let your documents die a slow and horrible death.
In the same vein as above, unit test everything! It is a myth that vendor tools don’t cut it when it comes to testing. You just need to know how! And sadly, they don’t always make it easy for you. Here are some suggestions:
Use a Web Service client such as soapUI or the OSB console to test for expected output of your synchronous services
Use instrumentation to test asynchronous functionality. If you don’t receive a response, don’t worry. You can let your component(s) log at the appropriate steps and your test framework to collate the times/payloads to determine test success or failure. Remember to make the logging pluggable so you don’t impact performance in production!
Don’t limit yourself to the happy path; test the unhappy ones as well.
Automate ALL unit tests and let Maven kick them off in its lifecycle. Even tests in soapUI and OSB console can be automated you just need to know how.
“We can’t migrate from 11g patch set 4 to the latest patch set 7. It would be too expensive”.
If you have heard a similar statement before then you my friend (unfortunately) may be involved in a project with poor quality control. As a big fan of test automation who has worked on many projects with little to no test coverage, it saddens me to still meet people absolutely terrified of change.
Did you know that acceptance tests, integration tests, unit tests can all be automated? Yep.
“But Craig, I know they can be automated but it is too technical and expensive.”
As a former believer of such a statement, I have to say I am converted. There are a number of very mature languages out there which allow for acceptance tests to be written in a business language. Here is one such example:
[code]Scenario: Replaced items should be returned to stock
Given that a customer buys a blue garment
And I have two blue garments in stock
And three black garments in stock.
When he returns the garment for a replacement in black,
Then I should have three blue garments in stock
And two black garments in stock[/code]
Can you read the above and understand what needs to be manually tested? If you can, then you may be surprised to know that this statement is actually executable and can be used to check whether the product delivers as expected… automatically. If the product doesn’t meet the criteria then it will fail the acceptance test and the whole team will know about it. Yep. This isn’t magic. It is a language called Gherkin and through tools such as Cucumber you can automatically acceptance and regression test your application. What a wonderful world we live in.
Automation as a Project
One of my favourite items in Mark’s blog was the statement that “people often try to automate the build process on a project by project basis.”
This is one of the biggest no nos in my book. When you’re providing all this agility through reusable components why on earth would you want to neglect this valuable discipline in your automation?
Always keep your configuration separate from your implementation via a DSL or Properties file. The moment you hardcode a password or a URL in a shell script which kicks off WLST you are basically saying “Hands off my script!”
[code]Sharing = Caring
Shell Script + Ant + WLST != "A Good Automation Solution"[/code]
As Luke Kanies founder of Puppet put it “ssh in a for loop is not a solution”.
In future instalments I will reveal more practical tips on:
If you liked this post, please subscribe or share it with your network. We love feedback so please don’t hesitate to hit the comments up below!