SOA and Integration

Posted on
Like what you see? Share it.Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone

There seems to be some confusion about the nature of service-oriented architecture (SOA) in the world of IT today. Some describe it as a hot new trend, which it undeniably is, but this explanation overlooks the fact that SOA has been around for quite some time. Others characterize it as a bundle of Web services, and while that’s certainly not false, it is a somewhat incomplete description. The truth is that the definition of SOA—that is, two or more computing services interacting to perform one of their functions—is so broad and vague that it’s not all that easy to pin down.


The description of SOA as an in-demand set of application-integrating Web services might not be all-encompassing, but it does speak to the aspect of this process that enterprises are most interested in at present. “It’s pretty high on the hype meter,” said Joe McKendrick, an analyst with research firm Evans Data Corp. (EDC). “Every vendor with a product to offer in the software marketplace is calling it an SOA-enablement product.”


However, this is a phenomenon of the past five years or so. Prior to the advent of Web services such as XML (extensible markup language), SOAP (simple object access protocol) and WSDL (Web services description language)—which breathed new life into the field—SOA was exemplified by somewhat obscure ventures like CORBA (common object request broker architecture). Developed in the 1990s, CORBA was promoted heavily by infrastructure vendors like IBM, but came up short primarily due to a lack of interest from Microsoft.


That’s a key difference in the buzz around the latest incarnation of SOA. Aside from the actual capability of these Web services, one of the main reasons SOA is getting so much positive attention is that most of the key companies seem to be on the same page this time. “By using these Web services standards, you can build application components that can talk to other application components from any other vendor, as long as they support that same standard,” McKendrick said. “The vendors have done a fairly decent job of supporting Web services. There’s always some contention going on behind some of the standards, but overall, this agreement has been a fairly remarkable event in IT history. The Web services standards are providing the building blocks that would enable the concept and the vision of SOA to actually take formation.”


Many observers predict that Web services-driven SOA will contend with enterprise application integration in the coming years as a method of combining various IT applications into a cohesive whole. Yet for the time being, that’s still a long way off. Most SOA users are currently content to limit it to peripheral tasks that won’t make or break their businesses. “It’s very much in the pilot stage, the experimentation stage,” McKendrick said. “You have some early-adopter companies that are implementing some SOA-type projects. There are some success stories coming out of these early adopters.”


When the capabilities of Web services eventually do catch up to industry expectations, enterprises will have to implement SOA across their organizations in order to optimally utilize it, McKendrick explained. “The problem is if you have one department of a company that has this Web services-centric structure in place, but it’s the only one that’s using that, it’s not really giving you any more value than a proprietary application would be. The ultimate advantage of an SOA will be the reuse—the ability to take an application or a service that’s being generated by an application, and apply that to a process in another part of the organization without the time spent to write the code and do integration work. Essentially, it will be right there in some type of repository and can be plugged in to (another) part of the enterprise.”


As an EDC analyst, McKendrick has extensively researched the topic of SOA, which the organization defines as a set of standardized application components that are shared between two or more units of the business. “The reason we use that definition is that you can have a whole series of Web services-enabled applications,” he said. “If you go buy a package application on the market today—it doesn’t matter what it is—to some degree, it’s going to support Web services standards.”


Still, in spite of the best efforts of McKendrick and other industry experts to establish the terms of the IT industry’s dialogue around SOA, a great deal of confusion lingers about what it is and what its implications are. “It’s still kind of a vague term,” he said. “There really is no ‘there’ there, at this point. It’s kind of this vision of an infrastructure of applications that can be assembled or disassembled as business processes demand, but at what point do we reach that stage? At what point can a company say they have an SOA? You could have two application components that talk to each other and complete some type of process, but is that an SOA? Or is it something bigger that encompasses the enterprise? It’s going to be a long time before we can say a lot of people have SOA, or something close to SOA.”


–Brian Summerfield,

Like what you see? Share it.Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone


Posted in Archive|


Leave a comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>