Service Component Architecture

Service Component Architecture (SCA) defines a model for developing applications based on a service-oriented architecture. Business job is provided as a set of components assembled into a structure called a composite. SCA is the foundation of TIBCO ActiveMatrix support for service-oriented Applications. This section introduces the elements of SCA: composites,components, services, references, implementations, properties, interfaces, bindings, and message exchange patterns.

Composites

As described in the SCA Assembly specification, a composite is a configuration of services comprising an application that conforms to a service-oriented architecture. A composite contains components, services, references, the wires that interconnect them and properties that are used to configure the components. Composites can be nested (contained by other composites). A root composite equates to an SCA application.

The constituents of a composite can run in a single process on a single computer or be distributed across multiple processes on multiple computers. A complete application might be constructed from just one composite or it could combine several different composites. The components making up each composite can be implemented using different technologies.

Components

A component is the basic element of business function. It is defined at design time.  Components are configured instances of implementations. More than one component can use and configure the alike implementation.

Components can have services, references, and properties. All of these can be promoted to the composite level during design time. Promotion enables an Administrator to wire or configure services, references, and properties when the application is deployed. Services, references, and properties that are not promoted are private to the application and are set at design time only.

Components can have several different types of dependencies. Components can express dependencies on product features, custom features, other components, and resources. All of a component's dependencies must be fulfilled for it to be deployed to a node. Components can be deployed to multiple nodes for fault tolerance or load balancing.

Component Implementations

A component's implementation concretely provides the business function. TIBCO ActiveMatrix supports the following implementation types:

• Java

• Mediation

• Composite

• WebApp

• Spring

• C++

• Adapters

An abstract component is a component whose implementation type is unspecified but whose interfaces and connections to services, other components, and references are defined. Abstract components can be used by system architects to defer the choice of implementation type while specifying the relationship of a component to other composite elements. Abstract components cannot be packaged or deployed.

Services and References

Applications interact via services and references. A service is a set of operations and the Messages required by the operations. A reference identifies the service consumed by a component or composite. Applications offer services and call up references to other services. An application's services and references are promoted from the services and references of the components it contains Component services can be consumed by other components within the composite or promoted as composite services for use by consumers outside the composite. A composite service has an interface and one or more bindings.

Component references consume services provided by other components in the same composite or services provided exterior the composite. A composite reference has an interface and one binding.

Interfaces

An interface defines the contract for services and references. Services and references can interact only when they have the same interface. An interface defines one or more operations and each operation has zero or one request (input) message and zero or one response (output) message. The request and response messages may be straightforward types such as strings and integers or they may be complex types. In the current release, TIBCO ActiveMatrix supports WSDL 1.1 port type interfaces.

Bindings

Abinding specifies how communication happens between a reference and a service. A service binding describes the mechanism a client uses to access a service. A reference binding describes the access mechanism a reference uses to invoke a service. References can have at most one binding.

TIBCO ActiveMatrix supports the following binding types:

• Virtualization

• SOAP

• JMS

• EJB

• Adapters

Virtualization bindings connect services and references to the Messaging Bus. Virtualization bindings are automatically created for every composite service and every wired component service and reference. At design-time, Virtualization bindings of component services and references are implicit; their properties cannot be viewed.

There are two types of Virtualization bindings: internal and external. An internal binding is associated with a component service or reference. An exterior binding is associated with a service or reference promoted to the root composite. Administrators can create or modify wires connected to external bindings and can monitor, start, and stop external bindings.

SOAP, EJB, Adapters, and JMS bindings are explicitly created by architects and developers only on promoted services and references.

Properties

Aproperty is an externally visible data value. Properties enable object behavior to be configured at deployment time.

A property has a type, which may be either simple or complex. Implementations, components, composites, bindings, logging configurations and appenders, and resource templates can have properties. Implementation, component, and composite properties are defined in TIBCO Business Studio. Binding, logging configuration and logging appender, and resource template properties are defined by the ActiveMatrix platform.

Properties can have explicit values or may be bound to substitution variables, which can be set at deployment time in various scopes. Depending on the object possessing the property, the property value can be bound at design time, deployment time, or both:

• At design time you can provide default values and indicate whether a composite or component property value must be set at deployment time.

• Some properties can be bound to substitution variables.

At design time, a composite property value can be set to a constant or bound to a substitution variable. Either type of binding can be overridden at administration time. However, only the properties of the root composite of an application or those on bindings associated with application level services and references can be overridden. If there are nested composites (component of type composite) then their property values cannot be changed by an Administrator.

A composite property is specific to an application. Often the same property may be defined in more than one application. For business reasons or ease of use an Administrator may want to define the value only once and have it be used by more than one composite property. This is achieved by binding the composite property to a substitution variable, which can be defined at the enterprise, host, environment, node, application, and application fragment levels. The following figure shows a property named Greeting bound to a substitution variable named Greeting.

 A component may be deployed to more than one node and you may want to have different values passed for a component property in every node. In such cases you would set the component property to a substitution variable, and set the substitution variable to different values on each node.

Message Exchange Patterns

A provider generates and responds to messages according to the operations defined in the interface it offers. The interface is always written from the perspective of the provider. That is, if an interface says that the messages are input and then output, the provider first receives a message and then sends a message. A consumer uses a service, and interprets an interface in order to consume a service. The consumer handles messages in the opposite direction from the provider.

A message exchange pattern (MEP) defines the sequence and cardinality of messages sent between the provider and the consumer. MEPs contain both normal and fault messages. TIBCO ActiveMatrix software supports following MEPs:

• One-Way (In-Only) A consumer sends a message to a provider.

• Request-Response (In-Out) A consumer sends a message to a provider, with expectation of response. The

Provider sends a response message. The provider may generate a fault if it fails to process the message.

Faults are errors that can occur at any point during the processing of a message. Faults can also be thrown by the target service while processing messages. In service-oriented applications, clients expect specific fault responses to be returned when errors occur. For example, SOAP clients expect a SOAP fault message to be returned when an error occurs during processing. Each implementation type supports methods for generating faults in response to error conditions.