|
First, it's important to understand that SOA adds a layer of abstraction on top of existing IT environments, which is part of why it's so useful in heterogeneous situations. So, you will typically have an existing architecture, whether it is client/server, n-tier, and/or component-based, underneath your SOA implementation.
That being said, the loosely coupled, Web services-based SOA that we talk about today owes much of its heritage to component-based approaches. The vision of component-based development (CBD) was to build business-oriented objects that offered functionality that made sense to business users. Typical components might be Customer or PurchaseOrder or the like. SOA takes this notion and applies it to business-oriented services. Typical business services might be "customer information" or "process purchase order" -- clearly paralleling the intent of CBD.
Where CBD had problems -- where SOA comes to the rescue, as it were -- is the fact that components have tightly coupled APIs. Objects that had to communicate with components had to be tightly controlled, and any changes to a component typically impacted each piece of software that accessed that component. As a result, CBD was still inflexible and hard to scale.
Because SOA relies upon abstracted, discoverable interfaces, however, service providers (which may be components) and consumers are loosely coupled. Each component may now have multiple service interfaces to meet the needs of different consumers, and consumers can dynamically discover the interfaces they require. Making this discovery-based abstraction work is challenging, but get it right, and your SOA will be flexible and scalable.
|
