The process of developing applications as a collection of Service Components that exchange information via request/reply or events is referred to as Service Component Architecture ( SCA ). In contrast to traditional monolithic applications that are designed as a single whole, SCA applications consist of a coalition of Service Components that communicate either via events ( EDA ) or via request/reply calls ( SOA ). SCA offers several key advantages over the traditional approach of monolithic application design:

• Flexibility of Development. Service Components are easier to develop because the semantics of each independent Service Component are significantly less complex than the overall of a single, (relatively large) monolithic application; each Service Component can be developed by a different team of developers, each of whom focus only on their component without having to know the details of work done by others.
• Reuse. Since each Service Component has well-defined interfaces, each component can be developed, tested and debugged independent of the other components. This not only speeds up project implementations but, in the case of well-designed Service Components, also leads to significantly enhanced reuse.
• Dynamic Deployment and Runtime Modification/Replacement. Service Components can be dynamically deployed to remote nodes at runtime, and components within a process can be easily replaced by new or updated components, further reducing the time taken to modify or change an existing process in response to business requirements.
• Configuration Management and Version Control. Service Components facilitate version control and dynamic configuration management, allowing fine-grained control over deployments across the enterprise.

Service Component Domains
Enterprises that choose the SCA approach will have multiple domains of Service Components to ease the task of developing and deploying componentized SOA and EDA applications. For instance, the finance department may have a set of reusable Service Components that only make sense in that domain; likewise, the manufacturing department may have its own unique set of Service Components developed to optimize the processes within that department.

While it may not be organizationally or technically possible to effectively reuse all Service Components across multiple departments, most large organizations will federate their domains to maximize their reuse of component designs and implementations. In many cases, even when an enterprise has multiple packaged-applications and/or complex legacy systems, it is possible to create a Service Components that access the relevant modules to permit reuse. Even though multiple component domains are an absolute requirement for most enterprise over time, a single set of base Service Components can address the needs of over 70% of most small to medium-sized integration projects. The Fiorano ESB platform incorporates this base set of components "out of the box" allowing a large number of integration projects to be implemented by business analysts with little or no programmer intervention.

Learn more:

 The Mission of Application Integration

 Streamlining your Integration Strategy

 Service Component Architecture: Unifying SOA and EDA