Service Component Architecture

This article was due to content flaws on the quality assurance side of the computer science editorial added. This is done in order to bring the quality of the articles from the subject area of computer science to an acceptable level. Help to eliminate the shortcomings in this article and take part in the discussion ! ( + )

Reason: Article is judgmental and does not explain the lemma. - Temporary interest 1:43 p.m., Sep 14. 2009 (CEST)

The Service Component Architecture ( SCA ) is a collection of specifications that describe a model of a service-oriented architecture (SOA). SCA is based on open standards such as web services . Following the SOA concept, SCA components are independent of a specific technology.

partner

The following companies work together as partners to create the specifications for the Service Component Architecture: BEA Systems , Cape Clear , IBM , SpringSource , IONA Technologies , Oracle Corporation , Primeton Technologies , Progress Software , Red Hat , Rogue Wave Software , SAP AG , Software AG , Sun Microsystems , Sybase , TIBCO , Xcalia and Zend Technologies .

definition

The published specification seems vague in many ways. But it is developing rapidly and new specifications are emerging. The specifications define the following properties for applications designed according to SCA:

Decoupling of service implementation and provision from the specific possibilities of the infrastructure.
Should work with different programming languages and standards, including C ++ , Java , COBOL and PHP , as well as XML , BPEL and XSLT .
Must support various message constructs, in particular simple calls with no response, asynchronous communication, a conversation across several messages and notifications.
Infrastructure options such as security, transactions and reliable reporting should influence the coding via metadata.
Data should be represented as service data objects .
Components designed according to SCA principles should be easily reusable.
Local service calls should be more closely linked. This reduces the overhead for generating and parsing messages, which is only intended for transport via networks.

Further analysis

Gartner Group published a news release in 2005, concluding that the Service Data Objects (SDO) technology contained in SCA will experience more rapid adoption due to its maturity.

Advantages:

designed for all existing Java platforms and C ++ technologies (however, the SCA-C ++ component model has serious defects)
less technology-dependent - e.g. B. neither Java nor XML
uses SDO, the only industry standard for data access in SOA

Disadvantage:

A lack of support from Microsoft reduces the relevance of SCA for a large number of potential users.
The specification does not address the performance of SOA applications, which remains a disruptive factor for the application.

It is claimed that SCA is interoperable through an approach called activation. Compared to the older methods of "mediation" (e.g. JBI) or "Invocation" ( JCA ), this method ensures a high degree of component autonomy .

SCA artifacts

The SCA Assembly Model consists of a series of artifacts. These are defined by elements in XML files. An SCA application may have other non-standardized representations of artifacts at runtime that are represented by these XML files. In addition, it can allow the dynamic configuration of systems. However, the XML files define the portable representation of the SCA artifacts.

The base artifact is the compound word . This is also the delivery unit within SCA and contains services that can be accessed from outside. A compound word contains one or more components that contain the business functions provided by the module. Components provide their functions as services. These can either be used by other components of the same module or they are also available outside of the module via entry points . Components can depend on the services of other components - these dependencies are called references . References can either be linked to services of other components of the same module or to services outside the module, in particular those of other modules. References to services outside the module are defined in the module as external services. The module also contains relationships between references and services. These are carried Wires represents (wires).

A component consists of a configured implementation , the implementation being the piece of program code that implements the so-called business logic . The component configures the implementation and has so-called properties that are recorded for each specific implementation. The component can also change the configuration of the implementation by specifying the wiring of the references to specific services declared by the implementation.

Compounds are delivered within an SCA system . An SCA system represents a set of services which in turn provide a range of business functionality that is controlled by a single specific business unit. Example accounting: The SCA system could cover all finance-related functions. In addition, it could contain a number of modules that deal with separate areas of accounting: one for customer accounts, another for invoices. Subsystems help with the creation and configuration of an SCA system. Subsystems are used to group related compounds. Subsystems contain module components, these are configured instances of modules. Subsystems, such as modules, have entry points and external services that map the external services and references. Subsystems can also contain wires that connect the module components, entry points and external services.

Implementations

Rogue Wave HydraSCA
Covansys
Apache Tuscany
Paremus Infiniflow
Newton
SCA and SDO for PHP
PocoCapsule
Trentino
TIBCO ActiveMatrix Service Grid

literature

Wolfgang Beinhauer, Michael Herr, Achim Schmidt: SOA for Agile Companies, Symposion Publishing 2008, ISBN 978-3-939707-14-1 (www.symposion.de/it-management)