Tuscany glossary of terms

SOA（service-oriented architecture）

面向服务的架构

解决问题：面向服务、多语言、多种数据格式、多协议

SCA（Service Component Architecture）

Service-component architecture (SCA) is a group of specifications intended for the development of applications based on service-oriented architecture (SOA), which defines how computing entities interact to perform work for each other. Originally published in November 2005, SCA is based on the notion that all the functions in an enterprise should exist in the form of services that are combined into composites to address specific business requirements.

SCA major parts or models

The assembly model, which defines how components are combined, linked and packaged as services independent of the programming language.
The implementation model, which defines how services are packaged and accessed for specific programming languages.
The policy model, which defines service policies independent of the programming code.
The bindings model, which defines how components are accessed independent of the programming code.

Tuscany SCA

Tuscany是Apache对SCA规范的一个实现。

SCA提供了一套可构建基于面向服务的应用系统的编程模型。它的核心概念是服务及其相关实现。服务由接口定义，而接口包含一组操作。服务实现可以引用其他服务，称为引用。服务可以有一个或多个属性，这些属性是可以在外部配置的数据值。

SCA is a standard programming model for abstracting business functions as components and using them as building blocks to assemble business solutions. An SCA component offers services and depends on functions that are called references. It also has an implementation associated it with it which is the business logic that can be implemented in any technology.

SCA provides a declarative way to describe how the services in an assembly interact with one another and what quality of services (security, transaction, etc) is applied to the interaction. Since service interaction and quality of service is declarative, solution developers remain focus on business logic and therefore development cycle is simplified and shortened. This also promotes the development of reusable services that can be used in different contexts. For example, a shopping cart service can be used in a retail application or a travel application without changing. Services can interact with one another synchronously or asynchronously and can be implemented in any technology.

SCA also brings flexibility to deployment. A solution assembled with SCA is deployed as a unit and can be distributed over one or more nodes in the network and can be reconfigured without programming changes.

Applications that adopt SCA programming model can interact with non-SCA applications. Meaning non-SCA application can call into SCA enabled applications and SCA enabled applications can call out into non-SCA enabled applications.

The main building blocks of the Tuscany SCA Java runtime

SCA Component图例

SCA Composite

In an SCA application the component is the basic building block. A collection of components that make up all, or part of, an application is called a composite and is described using simple XML constructs.

An SCA composite consists of components, services, references, and wires that connect them. A composite is the unit of deployment for SCA.

A composite can be viewed as a component whose implementation is not code but an aggregation of one or more components co-operating to provide higher level services. Think of composite as a solution, for example a credit check composite may consist of multiple components that together perform the credit checking work. A composite can also be used within a larger solution, for example credit check can be part of a order processing composite. A composite has the same characteristics as a component. It provides Services, has References to other dependencies, and can be configured using Properties and can have intent policies in just the same way as an individual components can. In thise case, attributes of some of the components that are embedded in the composite get 'promoted' and become the attribute of the composite.

SCA Component

The basic building block for SCA is a component. It is the abstraction of a given business function. A component is described with the following attributes:

Service、Reference、Property、Intent policies、Implementation。

A component is a configured instance of some business logic. It provides services and can use services. Every SCA service has a name and an interface. The interface defines the operations that the service provides. A component can provide one or more services.

SCA components call a service using a reference, for example, the creditCardPayment Service Reference in the Payment component.

The connection between the reference and the service is called a wire. References are wired to services, and so a network of connected components is described within a composite application.

What’s more, this assembly approach allows components implemented with one technology, say the Java language, to be connected to components implemented in
another technology, say BPEL. The detail of a component’s implementation is abstracted away from the other components that it’s connected to.Building on this idea of abstraction, the technology used to join components together is unrelated to how the components are implemented. This is what SCA calls a binding.

Service

The SCA specification describes a service as an addressable interface of the component’s implementation. To put this into somewhat simpler language, every service has a name and an interface. The name identifies the service and distinguishes it from other services. The interface defines the names, inputs, and outputs of the operations that the service provides.

An SCA service provides a reusable piece of business function and has a well-defined interface that identifies how it can be called to provide that function.

Service interaction patterns

Local and remotable interfaces

顾名思义，本地接口和远程接口。Interface type为interface.wsdl总是remotable的；Interface type为interface.java的，缺省为local的，要添加注解@Remotable才变为remotable 。Local and remote service interfaces exhibit different semantics. Local interfaces are pass-by-reference while remote interfaces are pass-by-value.

Interaction patterns

Request response—The calling component sends a message to the called component. This is referred to as the forward direction. The calling component expects an immediate response for each message that’s sent. 同步的、阻塞
One way—The calling component sends a message and doesn’t wait for a response.异步、非阻塞；常配合Callback来处理服务的返回
Conversational—The calling component sends a sequence of related messages that are associated with each other by means of a common context maintained between calling and called components. When no conversation is in effect, each message is stateless and isn’t related to the messages that come before or after it.
Callback—A forward message from calling to called component instigates a call from the called component back to the calling component at some point in the future. This is referred to as the callback direction. When no callback is configured, messages travel in the forward direction only.

Reference

This describes the dependencies this type of component has in order to function. A reference is an interface.

Property

This defines configuration parameters that can controls how the business function can behave. For example, what currency to use for an account component.

Intent policies

This describes assumptions on how the component will behave. There are two types of policies.

Implementation policy- Impact the behavior of an implementation. For example, transaction, monitor and logging
Interaction policy - defines how the components behave with one another. For example, security.

Implementation

Every component has some implementation associated with it. This can be a new business logic or an existing one that is now being used in the assembly. A business logic can handle different operations and some of which are exposed externally as callable services. Component implementation can be in any technology, for example for example BPEL for business processes or XSL-T for transformations or Ruby for scripting or pure Java. How the services, references, properties and intents are defined for an implementation is specific to that particular implementation type.

SCA Wire

As mentioned above, an SCA component may have zero or more references. Refrences in SCA define how SCA components invoke services. The relationship between a reference and a service is typically demonstrated through a line in a SCA diagrams and is referred to as a wire.
The term wire can at the begining seem confusing because you may ask how a wire is realized. There is no physical definition for a wire, it is really derived from the relationship between a Service and its refrence(s) at runtime. This is realized through dependency injection in Tuscany.

SCA Binding

You can use bindings on services or references.A binding is used as a means of communication between services and handles the protocols. It defines with what communication method a service can be accessed with or with what communication method it can will access other services. There can be different types of bindings depending on technologies used to develop a solution. For example JMS binding, Webservices binding, Atom binding for web20 interaction, etc.

Services can be configured with different bindings and there can be multiple bindings for a service. Bindings for the services and references get defined declaratively in the .composite file. There is a default binding called binding.sca which when used leaves the choice of binding to the underlying infrastructure by default.
The declarative bindings and the abstraction of protocols from business logic brings agility to SCA applications. This allows SCA applications to be purely focused on business logic and not be contaminated with protocol handling information.

Bindings provide the linkage between SCA and Tuscany and the rest of the world! Bindings can be used on SCA references to call non-SCA services using a standard communication protocol. In this case the roles are reversed; the client of the non-SCA service is implemented using SCA, and the non-SCA service uses some standard communication protocol and can be implemented using any technology that supports the chosen protocol.

SCA Contribution

The artifacts that make up a solution get packaged into what is called a contribution. A contribution can take a number of different forms. For example, it could be a jar file, or it could be a directory tree on the file system. A contribution can contain composites, java classes, BPEL processes, XSD files, wsdl files, etc. An SCA application can be divided into multiple contributions with dependencies between them. In general, some services depend closely on other services and it makes sense to package them together. If services are more independent it is best to package them separately so that they can be reused in different contexts. A contribution is a deployable unit. A solution may require multiple contributions that share artifacts and artifacts can be shared between (imported) between contributions.

SCA Domain

The SCA domain is a deployment and management boundary for SCA components. For example, a domain could be a single application server, a server cluster, or a group of servers or clusters. An entire domain typically runs a single vendor’s implementation of SCA.Every SCA component is part of an SCA domain.

An SCA domain manages a set of composite applications that can be connected using SCA wires and constrained by the same policy definitions. An SCA domain consists of
the following:

A virtual domain-level composite (that is, a domain composite) whose components are deployed and running
A set of installed contributions that contain composites, implementations, interfaces, and other artifacts

Running a composite application in a single process

Running a distributed composite application

Contribution packages get contributed to what is called SCA domain which is the scope of adminstration at runtime. An SCA Domain represents a complete runtime configuration, potentially distributed over a series of interconnected runtime nodes and is a logical view of the running applications or a coherent grouping of components that are working together. An SCA Domain typically represents an area of business functionality controlled by a single organization. For example, an SCA Domain may be the whole of a business, or it may be a department within a business.
Therefore, an SCA domain consists of the definitions of composites, components, their implementations, and the nodes on which they run. Components deployed into a domain can directly wire to other components within the same domain. Communication with services outside of a domain is done through bindings.
SCA Domains can vary in size from the very small to the very large:

a very small domain could be one within a test environment inside an IDE
a medium sized domain could be a single server or small cluster supporting a single application
a large domain could describe all the services within a department or company

In a large domain there may be all sorts of policies about where components can run and how they connect to each other or to external services. However, during development one is not concerned with all this. The code is packaged and made available for deployment. Tuscany SCA Java supports contributions in the form of JAR or filesystem.

Tuscany node

A Tuscany node is configured to run a composite application, which could be the entire SCA domain composite or a subset of this composite. The configuration captures the following information:

A collection of contributions that are required to run the components on the node
One or more deployable composites that describe the components
A list of binding base URIs that tells Tuscany what addresses are used to publish the service endpoints

To map an SCA domain to Tuscany nodes, you can partition the domain composite into one or more groups of components (denoted by composites) that are suitable to be run together. Each group of composites is configured as a Tuscany node.

SCA components typically depend on artifacts from SCA contributions such as the interface, Java implementation class, or XML schema. A list of installed contributions will be selected from the SCA domain for a node.