Service Oriented Architecture is an approach to
building software. SOA doesn’t dictate an underlying
architecture, a hardware platform, an operating system, or a
specific programming language. Instead, SOA focuses on
interoperability among specialized services. SOA aims to build a
whole whose sum is greater than its parts.
If you lack a conceptual model of Service-Oriented Architecture, consider what could happen if your car breaks down in the middle of a business trip. As soon as the car is disabled, it could signal for a tow truck, sending specific GPS coordinates. If car travel was a scheduled part of your itinerary, the car could also signal your virtual assistant to generate exceptions, such as canceling a meeting, rebooking a flight, guaranteeing late check-in, and paging your spouse. In turn, a cancellation might cascade additional exceptions to alert each meeting attendee.
A pipe dream? Perhaps not. OnStar is already provided in a number of new cars, satellite radio is available in almost every car, and GPS navigation aids cost as little as $200, integrating maps, traffic alerts, and directories of local businesses. It’s not a stretch to imagine an inexpensive device with a full-duplex connection to a worldwide mesh of information transceivers. The technology is readily available — the challenge is interconnecting a myriad of disparate services.
Interconnecting services is the heart of Service-Oriented Architecture (SOA). SOA aims to build a whole whose sum is greater than its parts.
There is no single, good definition of Service-Oriented Architecture. If you scan Wikipedia or search the Web via Google, you can easily find over 100 “good” definitions.
Put simply, though, SOA is a philosophy, or an approach to building software. Specifically, each SOA application is built expressly to interact “intelligently” with other applications to swap…
Please log in to view this content.
Not Yet a Member?
Register with LinuxMagazine.com and get free access to the entire archive, including:
