• Home
  • RSS Feed
  • Log in

Posts Tagged ‘Architecture’

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.

  • Share/Bookmark

Tags: Architecture, esb, SOA
Filed under Architecture, Middleware, SOA | 1 Comment »

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...)

  • Share/Bookmark

Tags: Architecture, SOA, versioning
Filed under Architecture, SOA | No Comments »

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...)

  • Share/Bookmark

Tags: Architecture, Java, Performance
Filed under Architecture, Java, Performance, Quality Assurance, Requirements Management, Testing | No Comments »

QCon San Francisco 2008 – Architects & Agilists
Posted by Erik Rozendaal in the wee hours: November 21st, 2008

The QCon San Francisco 2008 conference was opened with an interesting keynote by Rebecca Parsons and Martin Fowler. In their talks they addressed the often strained relationship between traditional architects and agile development and how to improve this relationship to the benefit of both the agile development team and architects. These benefits include cross-project and cross-department knowledge exchange, sharing of the architects many years of experience with the developers, and only working on the architecture that is actually needed. (more...)

  • Share/Bookmark

Tags: Agile, Architecture, qcon
Filed under Agile, Architecture | No Comments »

Deployment automation for Java application running on Websphere, WebLogic and JBoss

Archives

  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009

Xebia Sites

  • Xebia Corporate
  • Xebia France
  • Xebia India

Categories

  • Java (282)
  • Agile (109)
  • General (50)
  • Testing (42)
  • Performance (42)
  • Hibernate (36)
  • Scrum (33)
  • Podcast (31)
  • Architecture (31)
  • Spring (28)
  • SOA (24)
  • Maven (22)
  • Project Management (22)
  • Middleware (23)
    • Deployment (14)
  • Flex (17)
  • JPA (17)
  • Eclipse (15)
  • Xebia Labs (15)
  • Quality Assurance (14)

Tag Cloud

    Performance IntelliJ Agile Lean Architecture Scala fitnesse Seam JavaOne Maven XML product owner qcon Groovy Introduction to Agile Testing Hibernate Java Functional Programming Semantic Web SOA Scrum Grails Spring esb Xebia Poppendieck Agile Awareness Workshop Closures Ajax