SOA Integration: Services, Adapters and/or Proprietary Solutions
Another PIOCON white paper for the upcoming Collaborate ‘07 in Las Vegas April 15-19.
Session 523, time TBA
Services, Adapters and/or Proprietary Solutions
Tom DeLise, Piocon Technologies, Inc.
From the Overview:
In today’s IT and SOA landscape is there really a need for adapters? The answer is a resounding “Yes”. Distributed computing has been around for a very long time, but SOA in its most current incarnation is still very young. Early on vendors jumped on the bandwagon and laid claims that they were SOA compliant, since most people didn’t understand what true compliancy meant there wasn’t really an outcry until people started to use the software, but even then there wasn’t a resounding “call to arms”. Integration can be a daunting task, when a company does a large scale integration, adding one more system that should have had native service calls to a list tends to get missed in the grand picture.
Let’s go back and re-write history and ask the same question. Even if every vendor out there had all their current software available as services, would there really be a need for adapters? Again, the answer is a resounding “Yes”. The reason why is due to legacy systems. All large companies and just about all mid-size companies have made large investments in time and money to get their legacy systems to run the way they need to function in day to day business. So what is the answer; to “rip and replace”, to throw away the current corporate assets and invest even more into new technology and deal with the inherent downtime and bugs? Even though there is a legacy replacement strategy within SOA, this type of project is not easy and by design is an iterative phased endeavor. Let’s ask the question again, but slightly differently. How can we get the advantages of a SOA environment and utilize our legacy and standalone software while we execute on a long-term plan of action for an overall SOA environment? The quick answer here is services, adapters and / or proprietary solutions.
In this document I will go over three different techniques used in SOA integration. I will discuss what each technique is and how you might use pieces of them. I will show you some architectural examples and demonstrated some of the decisions that take place when implementing these integration techniques. I also will show how simple requirement changes could have big effects in how you integrate systems. I will then discuss a simplified pro and cons discussion for each of the three techniques outlined, finishing in some general pointers to consider when taking on a SOA integration project
·
