WebServices dot org

Why Services Are Not Components, and Vice Versa

There has been some debate in the industry on the differences between Service-Oriented Architecture (SOA) and Component-Based Architecture (CBA). Differences between SOA and CBA such fine grained vs. coarse grained, business vs. IT, or high-level vs. low-level are probably good observations, but I think the main point lies elsewhere.

At the end of the day, a component can be as high-level, 'business level', and of the same 'granularity' as any service. Or a service can be easily as fine-grained as a component.
CBA and SOA are indeed different as they address very different issues. If you work with components you work with code; while if you work with services you use some remote functionality over network under some contract. Composing services into higher-level processes is totally different story than linking some components together into an application. A service contract is totally different from a component interface.

Component-based architectures may be very relevant to service providers, as they might be the way in which a particular service is implemented.

The following functions are part of CBAs:

• Contracts: don't exist.

• Governance: project planning, internal architecture, compatibility of interfaces, proper usage of open source libraries, testing, etc.

• Impact analysis works with code dependencies, versions - of interface, language, runtime, etc.

• Policies: Few security and transaction settings within deployment descriptors.

• Checkout from repository.

• Deployment descriptors parade.

• Compilation.

• Packaging linking into apps.

• Deployment.

SOA is an architecture of an environment of running services. These services might be implemented as set of (even distributed) components, or objects, or shell scripts. But who cares? Designing, building, running, and governing an architecture of services is a different task than doing the same for components. From an SOA point of view, components are irrelevant.

SOA involves the following functions:

• Contracts: SLAs for bandwidth, operation hours, price per transaction, responsibilities for proper operation.

• Governance: keeping contracts, auditing of metadata, message inspections, and policy compliance.

• URL, HTTP GET, RSS, REST, WS-*, WSDL

• Bind and call.

• No compilation, no linking, no interest in code.

Of course, there is no clear boundary between SOA and CBA. A component can also offer its functionality over a network. But if you don't use some entity EJB as a service, then it's likely to be a component within your J2EE application - like a library for XML parsing. And, you can theoretically check out a service code from your repository (if you own it) and link it directly into your application.