David Chappell has written an excellent introduction to SCA in a whitepaper hosted on his site. Let me share my notes on this whitepaper in this blog.
SCA defines an approach for creating components and for describing how these components can work together to develop an application. There are three primary constructs in SCA: component, composite and domain. The components can be combined into a composite and a aggregation of composites makes a domain.
Components are the atoms from which an SCA application is created. It is an instance of an implementation, which is appropriately configured. The implementation may be in Java or in BPEL or in any other programming language. The configuration is expressed as XML in the language called as Service Component Description Language (SCDL).
Each component comes with a set of services, references, properties and sometimes bindings. It implements some business logic, which gets exposed as one or more services. To provide the necessary functionality, it invokes references, which are nothing but services of other components. Components can also make use of properties, the values it can read from SCDL configuration file when it gets instantiated. A binding needs to be specified for a component when it needs to communicate with a non-SCA application or with a component from another domain. the kinds of bindings include web services binding, JMS binding and EJB Session Bean binding.
Composites can be said to be molecules of SCA applications. The SCA Assembly Model specification defines how components can be wired to make up composites. While developers can use the GUI-based tools to wire together the components, ultimately these wirings get expressed as XML in SCDL configuration file.
SCA Policy Framework specification is used to define two categories of policies. Interaction policies can be defined by developers to modify how a component interacts with another components, in terms of security and reliability requirements. The Implementation policies are to be specified to modify how the component behaves locally.
While specifications provide a starting point, what is required for adoption are developer tools and runtime. While almost all vendors except Microsoft are gearing up for providing both developer tools and runtime, we will also have open source alternatives. While Apache Tuscany and Fabric3 from codehaus represent open-source options for runtime, Eclipse SOA Tools Platform (STP) Project is engaged in developing SCA tools for developers.
It's very unlikely that organizations can start using SCA now. I feel SCA will be considered by user organizations for adoption only after ratification of SCA specification by OASIS. Till then, we will need to watch its evolution as it indeed provides a latest state-of-the-art approach for software application development.
SCA defines an approach for creating components and for describing how these components can work together to develop an application. There are three primary constructs in SCA: component, composite and domain. The components can be combined into a composite and a aggregation of composites makes a domain.
Components are the atoms from which an SCA application is created. It is an instance of an implementation, which is appropriately configured. The implementation may be in Java or in BPEL or in any other programming language. The configuration is expressed as XML in the language called as Service Component Description Language (SCDL).
Each component comes with a set of services, references, properties and sometimes bindings. It implements some business logic, which gets exposed as one or more services. To provide the necessary functionality, it invokes references, which are nothing but services of other components. Components can also make use of properties, the values it can read from SCDL configuration file when it gets instantiated. A binding needs to be specified for a component when it needs to communicate with a non-SCA application or with a component from another domain. the kinds of bindings include web services binding, JMS binding and EJB Session Bean binding.
Composites can be said to be molecules of SCA applications. The SCA Assembly Model specification defines how components can be wired to make up composites. While developers can use the GUI-based tools to wire together the components, ultimately these wirings get expressed as XML in SCDL configuration file.
SCA Policy Framework specification is used to define two categories of policies. Interaction policies can be defined by developers to modify how a component interacts with another components, in terms of security and reliability requirements. The Implementation policies are to be specified to modify how the component behaves locally.
While specifications provide a starting point, what is required for adoption are developer tools and runtime. While almost all vendors except Microsoft are gearing up for providing both developer tools and runtime, we will also have open source alternatives. While Apache Tuscany and Fabric3 from codehaus represent open-source options for runtime, Eclipse SOA Tools Platform (STP) Project is engaged in developing SCA tools for developers.
It's very unlikely that organizations can start using SCA now. I feel SCA will be considered by user organizations for adoption only after ratification of SCA specification by OASIS. Till then, we will need to watch its evolution as it indeed provides a latest state-of-the-art approach for software application development.
No comments:
Post a Comment