Quick Guide to SCA (TUSCANY) edited by haleh mahbod
Page:
http://cwiki.apache.org/confluence/display/TUSCANY/Quick+Guide+to+SCA
Changes:
http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=53196&originalVersion=27&revisedVersion=28
Content:
---------------------------------------------------------------------
\\
{panel:title=A quick guide to
SCA|borderStyle=solid|borderColor=#6699ff|titleBGColor=#D5EFFF|bgColor=#ffffff}
Purpose of this guide is to help you understand the high level concepts in SCA
so that you can build a simple application. For more details on SCA please
refer to the various specifications available at
www.osoa.org.{section}{column:width=50%}
* [What is SCA?|#what is SCA]
* [SCA Component|#sca component]
* [SCA Wire|#sca wire]
* [SCA Composite|#sca composite]
* [SCA Domain and Contribution|#sca domain]
* [SCA .composite file|#SCA .composite file]
\\
{panel}{section}{section}
h2. {anchor:what is SCA}{color:#0099cc}What is SCA?{color}
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.
Now let's talk about SCA building blocks.
h2. {anchor:*sca component*}{color:#0099cc}SCA Component {color}
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:* Describes the functions that this type of component provides. A
component can offer one ore more services. A service is an interface.
* *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.
This is demonstrated below.
!component.png|align=center!
The implementation of a component can be in any language that is suitable for
the user, 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.
h2. {anchor:sca wire}{color:#0099cc}SCA Wire{color}
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.
h2. {anchor:sca composite}{color:#0099cc}SCA Composite{color}
Individual components like those described above can be used on their own, or
they can be assembled together in a composite. 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 credit check composite. 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 charactersitics 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 becom the
attribute of the composite. In the example below, you see a calculator
composite which consists of 5 components, a calculator service has references
to four components:Add, Subtract, Multiply and Divide.
!calc.jpg|align=center!
(on) The assembly or wiring is defined in .composite file through Service
Component Definition Language (SCDL). For example, calculator.composite would
define that calculator component references the other four components.
h2. {anchor:sca domain}{color:#0099cc}SCA Domain{color}
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 zip or 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.
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. A domain is a logical view of the
running applications or a coherent grouping of components that are working
together. A composite gets instantiated when it is actually used in an SCA
environment.
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.
Below is an example of domain with two contributions.
!domain.jpg|align=center!
---------------------------------------------------------------------
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
