Mailing-List: contact commits-help@tuscany.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@tuscany.apache.org
Message-ID: <385376427.1233685320043.JavaMail.www-data@brutus>
Date: Tue, 3 Feb 2009 10:22:00 -0800 (PST)
From: confluence@apache.org
To: commits@tuscany.apache.org
Subject: [CONF] Apache Tuscany Docs 2.x: SCA Overview (page created)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

SCA Overview (TUSCANYxDOCx2x) created by Luciano Resende
   http://cwiki.apache.org/confluence/display/TUSCANYxDOCx2x/SCA+Overview

Content:
---------------------------------------------------------------------

* [What is SCA?|#what is SCA]
* [SCA Component|#sca component]
* [SCA Wire|#sca wire]
* [SCA Composite|#sca composite]
* [SCA Contribution|#sca contribution]
* [SCA Domain|#sca domain]
* [SCA Binding|#sca binding]
* [SCA Policy|#sca policy]

h2. {anchor:what is SCA}What is SCA?
SCA is a standard programming model for abstracting business functions as c=
omponents 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 th=
e business logic that can be implemented in any technology.=20

SCA provides a declarative way to describe how the services in an assembly =
interact with one another and what quality of services (security, transacti=
on, etc) is applied to the interaction.  Since service interaction and qual=
ity of service is declarative, solution developers remain focus on business=
 logic and therefore development cycle is simplified and shortened. This al=
so promotes the development of reusable services that can be used in differ=
ent contexts.  For example, a shopping cart service can be used in a retail=
 application or a travel application without changing. Services can interac=
t with one another synchronously or asynchronously and can be implemented i=
n 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 ne=
twork and can be reconfigured without programming changes.=20

Applications that adopt SCA programming model can interact with non-SCA app=
lications. Meaning non-SCA application can call into SCA enabled applicatio=
ns and SCA enabled applications can call out into non-SCA enabled applicati=
ons.

Now let's talk about SCA building blocks and concepts.

h2. {anchor:sca component}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 attri=
butes:

* *Service:* Describes the functions that this type of component provides. =
A component can offer one ore more services. A service is an interface. =20
* *Reference:* This describes the dependencies this type of component has i=
n order to function. A reference is an interface.=20
* *Property:* This defines configuration parameters that can controls how t=
he business function can behave. For example, what currency to use for an a=
ccount component.=20
* *Intent policies:* This describes assumptions on how the component will b=
ehave. There are two types of policies.=20
** Implementation policy- Impact the behavior of an implementation. For exa=
mple, transaction, monitor and logging=20
** Interaction policy - defines how the components behave with one another.=
 For example, security.=20
* *Implementation:*  Every component has some implementation associated wit=
h 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 an=
d some of which are exposed externally as callable services.  Component imp=
lementation can be in any technology, for example for example BPEL for busi=
ness processes or XSL-T for transformations or Ruby for scripting or pure J=
ava. How the services, references, properties and intents are defined for a=
n implementation is specific to that particular implementation type.=20

This is demonstrated below.
!component.png|align=3Dcenter!

The implementation of a component can be in any language that is suitable f=
or the user, for example BPEL for business processes or XSL-T for transform=
ations or Ruby for scripting or pure Java. How the services, references, pr=
operties and intents are defined for an implementation is specific to that =
particular implementation type. =20

h2. {anchor:sca wire}SCA Wire

As mentioned above, an SCA component may have zero or more references. Refr=
ences in SCA define how SCA components invoke services. The relationship be=
tween a reference and a service is typically demonstrated through a line in=
 a SCA diagrams and is referred to as a wire.=20

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 runt=
ime. This is realized through dependency injection in Tuscany.=20


h2. {anchor:sca composite}SCA Composite

An SCA composite consists of components, services, references, and wires th=
at connect them. A composite is the unit of deployment for SCA.
A composite can be viewed as a component whose implementation is not code b=
ut an aggregation of one or more components co-operating to provide higher =
level services. Think of composite as a solution, for example a credit chec=
k composite may consist of multiple components that together perform the cr=
edit 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 com=
posite has the same charactersitics as a component. It provides Services, h=
as References to other dependencies, and can be configured using Properties=
 and can have intent policies in just the same way as an individual compone=
nts can. In thise case, attributes of some of the components that are embed=
ded in the composite get 'promoted' and becom the attribute of the composit=
e. In the example below, you see a calculator composite which consists of 5=
 components, a calculator service has references to four components:Add, Su=
btract, Multiply and Divide.

!calc.jpg|align=3Dcenter!
(on) The assembly or wiring is defined in .composite file through Service C=
omponent Definition Language (SCDL) that is in XML. For example, calculator=
.composite would define that calculator component references the other four=
 components.

h2. {anchor:sca contribution}SCA Contribution

The artifacts that make up a solution get packaged into what is called a co=
ntribution. A contribution can take a number of different forms.  For examp=
le, it could be a jar file, or it could be a directory tree on the file sys=
tem. A contribution can contain composites, java classes, BPEL processes, X=
SD files, wsdl files, etc. An SCA application can be divided into multiple =
contributions with dependencies between them. In general, some services dep=
end 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 deployab=
le unit. A solution may require multiple contributions that share artifacts=
 and artifacts can be shared between (imported) between contributions.

h2. {anchor:sca domain}SCA Domain

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 interconne=
cted runtime nodes and is a logical view of the running applications or a c=
oherent grouping of components that are working together. An SCA Domain typ=
ically 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, compone=
nts, their implementations, *and the nodes* on which they run. Components d=
eployed into a domain can directly wire to other components within the same=
 domain. Communication with services outside of a domain is done through bi=
ndings.=20
=20

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 supportin=
g a single application
* a large domain could describe all the services within a department or com=
pany=20

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. Howeve=
r, during development one is not concerned with all this. The code is packa=
ged and made available for deployment. Tuscany SCA Java supports contributi=
ons in the form of JAR or filesystem.=20

Below is an example of domain with two contributions.
!domain.jpg|align=3Dcenter!

h2. {anchor:sca binding}SCA Binding
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 a=
ccessed with or with what communication method it can will access other ser=
vices.  There can be different types of bindings depending on technologies =
used to develop a solution. For example JMS binding, Webservices binding, A=
tom binding for web20 interaction, etc.=20

Services can be configured with different bindings and there can be multipl=
e bindings for a service.  Bindings for the services and references get def=
ined declaratively in the .composite file. There is a default binding calle=
d binding.sca which when used leaves the choice of binding to the underlyin=
g infrastructure by default.

The declarative bindings and the abstraction of protocols from business log=
ic brings agility to SCA applications. This allows SCA applications to be p=
urely focused on business logic and not be contaminated with protocol handl=
ing information. It also enables the SCA compositions to grow or change wit=
hout code modification while also working with applications that are not en=
abled with SCA.


h2. {anchor:sca polciy}SCA Policy
An enterprise application requires control beyond the business functional c=
apability which can include how security is handled in the enterprise or wh=
at transactional capability should be applied to services that are offered.=
 SCA policies define the constraints or capabilities that get applied to se=
rvices and their interaction. Two types of policies are defined in SCA.
* Interaction Policies - Define the policies that influence interaction of =
services for example whether authentication is required or not.
* Implementation Policies - Define how the components behave at runtime for=
 example whether it is transactional or not.=20

SCA mechanisms for defining policies such as intents and policySets can onl=
y be used in the context of a single domain. The fact that policies can be =
defined declaratively make applications adaptive to the environment that th=
ey get deployed into or to changes in the business requirements.=20
For more information about policy check out the [sca policy framework speci=
fication|http://www.osoa.org/download/attachments/35/SCA_Policy_Framework_V=
100.pdf]version=3D1]


---------------------------------------------------------------------
CONFLUENCE INFORMATION
This message is automatically generated by Confluence

Unsubscribe or edit your notifications preferences
   http://cwiki.apache.org/confluence/users/viewnotifications.action

If you think it was sent incorrectly contact one of the administrators
   http://cwiki.apache.org/confluence/administrators.action

If you want more information on Confluence, or have a bug to report see
   http://www.atlassian.com/software/confluence