ESB as a political thing
Posted by Viktor Grgic mid-afternoon: October 5th, 2009
Many have assumption that IT / software architecture is a thing of logic. So, there are many discussions about ESB and that we should not have those. The fact is that in large companies, we do not often do architecture - we do politecture. The politics drive the architecture. It's not the way it should be, but that's the way it is.
Let's do one more shot...why do we need ESB? This time from politecture perspective:
Preventing a mess
It allows for a greater degree of control on delivered solutions. Before you even think about creating another quick and dirty integration solution; there is that annoying ESB compliancy making sure that integration mess created with each new technology is at least visible.
Disruptive Innovation
An alternative like REST is a "disruptive innovation" and does not fit in the line of old mindsets (CORBA, RMI, EJB, SOAP, WS-*,...). ESB fits in this line. Of course, it is a matter of time before something like REST wins from ESB's.
Legacy
Quite often the cleanest solution is to change or replace the legacy in case of integration problems. So you still don't need an ESB. But the real problem is who is going to let you change that legacy that has not been changed and (barely) working in production for a long time.
Bug Report that will help developers and testers alike.
Posted by Aman Arora around lunchtime: August 27th, 2009
I joined Xebia India as a tester for one of the project. While validating the defects the biggest problem that I faced was regarding the understanding of defect report and trying to reproduce the said problem when there were no steps. Being a new member to the team and joining the application in between the sprints added to it. Every time when I had to validate the defect and steps to reproduce were not there I had to run to the developer for their help. Developers too were tied up with their own tight schedules and sometimes the validation for the defect had to wait for sometime which created a backlog for me and then I thought to come up with the solution to it which I am discussing below. Using the following approach helped us and can help all.
(more...)
Versioning SOA services
Posted by Michaël van Leeuwen around lunchtime: August 3rd, 2009
Rik de Groot wrote a blog entry about a year ago about versioning services as part of the Top 10 SOA Pitfalls. He touched the subject on different versions in deployment and basically offered us the option of rerouting services using an ESB.
It is a common knowledge that consumers will keep on using a service hoping to only upgrade if *they* need additional or changed functionality. Services however are not meant for a single consumer but for a lot of consumers. Even if they want to upgrade they won't do it simultaneously. So you will have multiple versions of services running.
I see several options to address versions of services:
1. Minimize by using rerouting within the ESB.
2. Keep all versions running while in use.
3. Have a contractual agreement with expiry date.
4. Use content based routing.
5. Construct adapters for conversion
First I would like to look at which versions might appear. A major version increment of a service means we are no longer backward compatible. A consumer wanting to use the next major release therefore needs to start coding to make use of this service. When a minor increment occurs there is backward compatibility and additional functionality offered. This means a consumer can make use of it without much effort (changing the binding would suffice). A patch increment of a service indicates a change without breaking specifications. A new patch release can - and should - therefore replace the older version.
Clearly in all options we should limit the number of versions of a service created. This means services should not be created within projects but (re-)created in a separate track in order to have generic services and optimal reuse. This track should collect all requirements of (potential) customers, take the common denominator and bring a new version into existence. More than often a new version is created because a single customer wants certain functionality not yet offered and without looking around the new version is tailor-made.
(more...)
iCMG Architecture World 2009 Bangalore
Posted by ShriKant Vashishtha in the early morning: July 31st, 2009
Recently I got a chance to attend a 2 days architecture conference in Bangalore organized by iCMG. Some very experienced and renowned figures in software world took sessions on architecture and software development. It sounded like a conference on just software architecture but it catered various other topics which could be grouped under Software development in general. If we leave the question of whether the conference should have focused on architecture only, other topics were also quite good and relevant to software development.
Web performance in seven steps; Step 4: Test continuously
Posted by Jeroen Borgers at around evening time: July 22nd, 2009
Last time I blogged about the importance of representative performance testing. Having production-like properties for hardware, OS, JVM, app server, database, external systems and simulated user load are essential to prevent bad performance surprises when going live. In addition, I described how cloud computing can be utilized to generate high loads on-demand without having to worry about the infrastructure.
Continuous performance testing
With a representative test as one of the last steps before going live we prevent that expensive bad-performance surprises will pop up in production. However, the same surprises will pop-up, only earlier and with less impact. To save costs and prevent large architectural refactoring, it is crucial to test for performance as soon as possible. This is just like any other software defects and Quality Assurance: the later in the development process defects are detected, the more costly these defects are.
At a popular web shop I had the following challenge: (more...)
Web performance in seven steps; step 2: Execute a proof of concept
Posted by Jeroen Borgers at around evening time: June 15th, 2009
Last week I blogged about setting your performance goals: defining your requirements. This time I'll blog about the importance of a Proof of Concept for performance.
The IT world is very sensitive to trends. Having been around in the IT industry for 15 years, I’ve seen a few. A technology is hot for a while, and then quickly becomes out-of-fashion and yesterdays news. It will be replaced by something which is much better and what everyone follows almost blindly.
(more...)
Clouds… Everything-As-A-Service
Posted by Guido Schoonheim around lunchtime: March 13th, 2009
Yesterday was a very good day! After speaking at QCon the day ended with CloudCamp. An evening dedicated to everything cloud with an amazing turnout! More then 500 folks joined.
Turns out that although in general people tend to agree what a cloud is, nobody actually knows exactly what to do with it! (more...)
Refactoring Flex application from existing Adobe AIR codebase
Posted by ShriKant Vashishtha in the early evening: March 2nd, 2009
Adobe AIR is a great technology to provide platform-independent desktop RIA applications. Gone are the days when Windows operating system used to be ubiquitous in desktop market. That's the reason why Adobe AIR is considered as the future of desktop applications. Desktop applications are here to stay as they come with the power of providing rich features in efficient/optimal way compared to browser mode.
Clean Code vs. Implementation Patterns
Posted by Vincent Partington in the late evening: January 26th, 2009
I've just read Robert C. Martin's Clean Code and Kent Beck's Implementation Patterns back to back. I actually picked up Clean Code first because my colleagues were raving about it. But then Robert Martin's book quotes from Kent Beck's book on the third page of the first chapter already, and disagrees with the quote, so I decided it'd be fun to read Implementation Patterns too. 
(more...)
QCon San Francisco 2008 – Unleash Your Domain
Posted by Erik Rozendaal in the late afternoon: November 22nd, 2008
The talk "Unshackle Your Domain" given by Greg Young was the highlight of QCon for me. An architectural approach that is relatively easy to understand, incredibly scalable, and supports a rich domain model. (more...)
Categories
- Java (291)
- Agile (127)
- General (96)
- Architecture (47)
- Testing (45)
- Scrum (44)
- Performance (42)
- Podcast (31)
- SOA (25)
- Middleware (31)
- Deployment (20)
- Project Management (23)
- Xebia Labs (21)
- Quality Assurance (16)
- Tools (12)
- lean architecture (11)
- Articles (9)
- Virtualization (9)
- Security (7)