CSA and SOA

CSA and SOA

The essence of SOA is ability to create a composite application by quickly assembling heterogeneous services. CSA is a step in this direction. Heterogeneous components can be defined in SCA format. SCA component talk to each other via wires. These wires can be configured. There is no need for hard coded API calls. Once a composite has been defined, its different component can be deployed in different run time environment. A composite file – an xml file, linked together different components of composite and provide a single point of unification for different inter related components.

All most all major vendors support CSA standard – IBM, SAP, Oracle, Adobe and many more. Due to this CSA is likely to reach a tripping point in near future. J2EE has been traditionally considered a more complex working environment in comparison to donet . Specially, EJB's are notorious for their complexity. CSA is an attempt to simplify J2EE environment and increase developer productivity. Many of SCA concepts are similar to WCF (Window communication foundation) of dotnet world. The ultimately , the focus in both Dotnet and J2EE environment is to increase developers productivity without compromising quality and because of this both world are going to survive in near future .

CSA or components service architecture

CSA (component service architecture), is an attempt by J2EE world to develop an xml based standard for defining components metadata. CSA was earlier known as SCA and is now an OASIS standard. Component metadata includes services exposed by components, services reference (used) by components and properties of components. CSA standard facilitates assembling of composite components by configuration, without requiring hard coded api calls. In CSA standards, there is clear separation between developments of components business logic and non functional requirements required for deploying the components into a run time environment. CSA is also called "programming by intend". Developer can write business logic in medium of their choice – java, C++, Cobal, Python, BPEL, Spring and even C#. etc. and express their intend for non functional requirements (NFR) a.k.a. as policy sets. Policy sets can be applied/modified during deployment time. SCA support two of annotations. One type of annotations can be used to define components services, references and properties. Other type of attributes are used for define policy sets. Subsequently, a tool can read these attributes to generate an XML file which defines a components metadata. During the deployment type, another tool introspects policy set related annotation and then applies policy sets for meeting NFR.