Service-oriented architecture isn’t a new approach to software design. Some of the notions behind SOA have been around for years. Jess Thompson, a research director at Gartner, says the underlying concepts date back to the early 1970s, when researchers started drawing boundaries around software and providing access to that software only through well-defined interfaces

(an idea called encapsulation). But lately, SOA has been gaining traction, especially as CIOs begin to think seriously about Web services. Gartner estimates that by 2008, more than 60 percent of enterprises will use SOA as a "guiding principle" when creating mission-critical applications and processes.

But to implement an SOA, you must first understand it?and that isn’t always easy. So let’s begin with some simple questions and (hopefully) simple answers.

What the Heck Is an SOA?

SOAs start with services, which are groups of software components that carry out business processes, for example, verifying a credit card transaction or processing a purchase order. At its most basic, an SOA is a collection of services on a network that communicate with one another. The services are loosely coupled (meaning that an application doesn’t have to know the technical details of another application in order to talk to it), have well-defined, platform-independent interfaces, and are reusable. SOA is a higher level of application development (also referred to as coarse granularity) that, by focusing on business processes and using standard interfaces, helps mask the underlying technical complexity of the IT environment. It’s like translating a high school science text for your kindergarten-age daughter; you can tell her that the heart pumps blood without getting into the mitral valve and pulmonary veins.

Isn’t SOA Just Corba in New Clothes?

No. SOA is an evolution from traditional tightly coupled application connections?including common object request broker architecture, or Corba?to loosely coupled ones, such as Web services. Tight coupling makes it hard for applications to adapt to changing business requirements, as each modification to one application may force developers to make changes in other connected applications. Also, object-oriented development uses a finer level of granularity?objects might be defined at the level of employee or customer order. In an SOA, a service is defined at a more abstract level, say, a business process such as generating a phone bill.