Listen to the Computerworld TechCast: Introduction to SOA.
Given the buzz about service-oriented architecture today, let's make a few important points: The SOA concept isn't new, it's not a technology per se, it isn't just the use of XML and Web services, and it's a good deal more than a development methodology.
More
Computerworld
QuickStudies
SOA is a pretty simple idea: Standardize those generic functions that are widely used by many applications into reusable components (services) that are accessible over a network, and code more specific logic needs into the application itself. Indeed, every operating system is a prime example of an SOA in action, if not in name.
IT organizations were successfully building and deploying SOA applications years before XML and Web services existed. They just talked about the process using terms like modularity, reusable components, object-oriented programming or application programming interfaces. Although none of those concepts is identical to SOA, they all embody aspects of it.
SOA is just the latest shorthand for a method of designing, developing, deploying and managing discrete pieces of computer logic (read "services") within a computing network. It's a way of structuring applications, organizing IT infrastructure and standardizing business functionality. Although SOA is often associated with the use of XML and Web services, these latter two are merely the latest implementation of the SOA principle.
SOA requires developers to design applications as collections of services, even if there's no immediately apparent benefit to doing so. SOA requires developers to think beyond their current application, to consider reusing existing services and to examine how other developers might reuse the services they are creating. SOA encourages developers to use alternative technologies and approaches, such as messaging, and to build applications by linking services together rather than by writing new code. This type of application structure allows a company to react quickly to changing market conditions; instead of having to develop new application code, they can simply modify the messaging.
By focusing on business processes and using standard interfaces, SOA can help hide the underlying technical complexity of the IT environment. Analyzing the interaction between services in an SOA lets companies understand when and why specific business logic is being executed, which makes it easier to optimize business processes.
Loose vs. Tight Coupling
One key feature of SOA is the use of loosely coupled connections. Traditionally, connections between applications or between applications and services have been tightly coupled, as with CORBA (Common Object Request Broker Architecture). The difference is important.
Eric Van der Vlist, author of XML Schema: The W3C's Object-Oriented Descriptions for XML (O'Reilly, 2002), describes the differences between the two types of coupling with this analogy: In a tightly coupled system, you have direct control over the operation. For example, flipping a wall switch to turn on a light is a tightly coupled system. However, making a telephone call to order a book is a loosely coupled system. It could be tightly coupled only if you had access to the button controlling the printer that will print the book you order.
Tightly coupled systems are usually fast and safe, and the risk of transmission errors is very low. Loosely coupled systems, on the other hand, are usually more error-prone but also more flexible. The clerk you talk to on the phone may misunderstand the ISBN number of the book you want to order or make an error while entering it. But if you don't remember the ISBN number, you can still tell the clerk that you want the latest book on the World Wide Web Consortium's XML schema by a guy with a Dutch name from a publisher that puts pictures of animals on its book covers—and when you do that, you've got a good chance of being understood.
Tight coupling tends to make component maintenance and reuse much more difficult, because a change in one component automatically means changes in others. Similarly, tight coupling makes extra work when an application has to adapt to changing business requirements, because each modification to one application may force developers to make changes in other connected applications.
In general terms, a Web service is a type of SOA in which interfaces are based on standardized Internet protocols. In addition, except for binary data attachment, Web service messages must be in XML. Generally speaking, a Web service is little more than an SOA that uses Simple Object Access Protocol and the Web Services Description Language. However, an SOA doesn't require the use of Web services as we understand them, and some types of Web services can be deployed without an SOA.
 | |
|
Kay is a Computerworld contributing writer in Worcester, Mass. Contact him at russkay@charter.net.
Are there technologies or issues you'd like to learn about in QuickStudy? Send your ideas to quickstudy@computerworld.com.
See additional Computerworld QuickStudies