Read More in Architecture & Design »
The Role of Component Architecture in the Realm of Service Oriented Architectures (SOA)
By Surekha Durvasula
This article will show you how the two concepts of Component Architecture and Service Oriented Architectures (SOA) might fit together within an environment without having to decommission all the work done using the principles of component architecture. The premise of SOA is to not have developers adopt a rip and replace philosophy to upgrade mission critical systems but to make those systems more accessible to business users and make them easier to maintain.
The Tenets of Component Architecture
First, here is a brief recap of the tenets of component architecture that are still applicable to the SOA paradigm. These include constructs such as the separation of the top-level interface from the implementation, use of standardized protocols to transmit messages from the component, having access to robust plumbing and integration utilities available in standardized application server containers, and so forth. All of these made the component architecture programming model more efficient and less error-prone.
However, a major limitation of the component-based distributed architecture implementation was that components were syntactically bound to specific implementation languages. This language dependence forced the providers and consumers to come to a design-time agreement on the message formats/parameters being shared and the component interface code fragment being called to make the "remote call," thus forcing component-based interactions to become tightly coupled.
SOA Enters the Picture
SOA now builds upon these concepts by standardizing not just the protocols and integration plumbing but also leveraging platform and language-independent representations of the message formats (XML) that enable the provider and consumer to be implemented in a language-agnostic manner. Further, standardizations of the wire-format and transmission technologies allow the tool vendors to offer service authoring and service deployment utilities. Table 1 summarizes some of the obvious distinctions between the two models of distributed architecture.
Table 1: Distinctions between the two models of distributed architecture
Typically used to create a service façade that expresses a business interface to a common enterprise-worthy business function, business activity, or a business process Typically a good choice for a service implementation layer wherein the business behavior advertised on the service façade has to be aligned with the internal representation of the business information available to the enterprise
Synchronous and asynchronous interaction model support allows cross-platform and language-agnostic interactions Message Oriented Middleware usage that transmits a standardized message is the only way to achieve platform and language neutral interactions
Leverages a platform, vendor, and technology agnostic transmission protocols such as SOAP Leverages technology-specific RPC transmission protocols
Allows loose coupling by trading XML representation of business objects and not just language-dependant objects Tightly coupled to trading business objects and/or value objects
Use of XML Schema based documents allow one to deal with service versioning Object parameters being traded may or may not be able to deal with versioning changes without breaking the entire communication/execution path
Infrastructure components such as ESB are standards based to support service call routing and mediation. Message Broker is the key infrastructure component used to route calls when business messages are published from a component
Leverages standardized SOAP-based encoding to instruct infrastructure components on how to handle message delivery, message reliability, transaction support, and other run-time behaviors Does not offer standardized SOAP-based encoding to instruct infrastructure components on how to handle message delivery, message reliability, transaction support, and other run-time behaviors. Application server technology and vendor-specific deployment descriptors are the closest representations to achieve configuration-based Quality of Service encoding
Supports Service Repository and Service Registry concepts for defining and publishing service usage semantics Supports concept of Service Discovery and Late binding
Adapters to various technologies and platforms are available to express legacy assets as reusable web services JCA adapters have to be provided for business application translations but not for technologies
Enables service composition to allow new business offerings Cross-technology service chaining is not possible
SOA-style services primarily have a published interface and a more protected service implementation. The reason for this is to separate the public view of the service—the "service interface"—from the more volatile view of the service-based business logic that is embedded in the "service implementation." This way, the consumers of the service are insulated from any changes to the service implementation as long as the service interface has remained intact.
This article was originally published on February 5, 2009