TECHniques SOA ENABLEMENT EDITION | ISSUE 2, 2009 Technology SPOTLIGHT implementation and container types is an absolute necessity! An additional challenge faced by businesses adopting SOA-centric application development is how to bridge the gap between the sketchy drawings of the business processes conceived by the business departments with the myriad details of the actual implementation and deployment of the software artifacts owned by the IT departments. Hence, the composition architecture must also decouple the implementation details from the component interface and composition definition level. To address these two key requirements, a new standard called Service Component Architecture (SCA) is emerging in the OASIS consortium. The SCA suite of specifications identifies a simple, yet powerful, recursive ‘component definition and assembly model’ that enables building SOA-based service components, composites and integrations, independent of underlying implementation and deployment container types. Service-oriented Architecture (SOA) is a core technological approach that enables flexibility and reduces the complexity of solutions in an enterprise IT environment. A key characteristic of SOA lies in realizing business applications, and their inherent computational logic, as aggregations of reusable ‘service’ components, so that existing implementations are reused in different applications, instead of reinvent- ing the wheel each time around. However, in a typical large enterprise environment, implementations happen in different languages and programming paradigms involving a multitude of runtime environ- ments. This kind of environment results in a heterogeneous population of service (SOA) components, each of which may be implemented in any language, deployed into disparate containers and runtime environments. To fully realize the power of SOA and to enable enterprises to leverage existing and legacy implementations, a ‘service composition architecture’ that can encompass service components of varying SERVICE COMPONENT ARCHITECTURE – A TECHNICAL OVERVIEW By Prasad Yendluri, Vice President, Deputy CTO, Software AG Figure 1: SCA Assembly Model SCA OVERVIEW Service Component Architecture (SCA) defines a simplified programming and composition model for SOA. It identifies a recursive composition model for building elemental service components, assembling those components into composites and eventually into applications that can be deployed into distributed runtime environ- ments. SCA permits mixing and matching components of any implementation type that can be accessed using native or Web services access methods, in a platform, language, implementation, and container independent way, as depicted in Figure 1. Either existing implementations (bottom-up approach) or newly created interfaces and code (top-down) can be turned into SCA components by encasing them in simple XML-based metadata wrappers. SCA composition tools can make these compo- nents available for composition via simple “wiring” together, without exposing the implementation details. SCA currently supports components of different imple- mentation types including Java, C++, EJB, COBOL, Ruby, Spring and even orchestra- tions defined in BPEL. Figure 1 captures the concepts of SCA components, composites and associate assembly model in a concise fashion. At the lowest or atomic level, an SCA compo- nent exposes a service interface such as a WSDL port-type or a Java Interface. The component is realized or implemented by any of the possible implementation types including Java, C++, BPEL, COBOL etc. Each component may also have dynamically configurable values called “properties” that can potentially take different values for each instance of the component.
Transcript
TECHniquesSOA EnAblEmEnt EditiOn | iSSuE 2, 2009
technology Spotlight
implementation and container types is an
absolute necessity! An additional challenge
faced by businesses adopting SOA-centric
application development is how to bridge
the gap between the sketchy drawings of
the business processes conceived by the
business departments with the myriad
details of the actual implementation and
deployment of the software artifacts
owned by the IT departments. Hence, the
composition architecture must also decouple
the implementation details from the
component interface and composition
definition level.
To address these two key requirements, a
new standard called Service Component
Architecture (SCA) is emerging in the OASIS
consortium. The SCA suite of specifications
identifies a simple, yet powerful, recursive
‘component definition and assembly model’
that enables building SOA-based service
components, composites and integrations,
independent of underlying implementation
and deployment container types.
Service-oriented Architecture (SOA) is a
core technological approach that enables
flexibility and reduces the complexity of
solutions in an enterprise IT environment.
A key characteristic of SOA lies in realizing
business applications, and their inherent
computational logic, as aggregations of
reusable ‘service’ components, so that
existing implementations are reused in
different applications, instead of reinvent-
ing the wheel each time around. However,
in a typical large enterprise environment,
implementations happen in different
languages and programming paradigms
involving a multitude of runtime environ-
ments. This kind of environment results in
a heterogeneous population of service
(SOA) components, each of which may be
implemented in any language, deployed
into disparate containers and runtime
environments. To fully realize the power of
SOA and to enable enterprises to leverage
existing and legacy implementations, a
‘service composition architecture’ that can
encompass service components of varying
Service component Architecture – A tEchnicAl OvErviEwBy Prasad Yendluri, Vice President, Deputy CTO, Software AG
Figure 1: SCA Assembly Model
SCA Overview Service Component Architecture (SCA)
defines a simplified programming and
composition model for SOA. It identifies a
recursive composition model for building
elemental service components, assembling
those components into composites and
eventually into applications that can be
deployed into distributed runtime environ-
ments. SCA permits mixing and matching
components of any implementation type
that can be accessed using native or Web
services access methods, in a platform,
language, implementation, and container
independent way, as depicted in Figure 1.
Either existing implementations (bottom-up
approach) or newly created interfaces and
code (top-down) can be turned into SCA
components by encasing them in simple
XML-based metadata wrappers. SCA
composition tools can make these compo-
nents available for composition via simple
“wiring” together, without exposing the
implementation details. SCA currently
supports components of different imple-
mentation types including Java, C++, EJB,
COBOL, Ruby, Spring and even orchestra-
tions defined in BPEL.
Figure 1 captures the concepts of SCA
components, composites and associate
assembly model in a concise fashion. At
the lowest or atomic level, an SCA compo-
nent exposes a service interface such as a
WSDL port-type or a Java Interface. The
component is realized or implemented by
any of the possible implementation types
including Java, C++, BPEL, COBOL etc. Each
component may also have dynamically
configurable values called “properties” that
can potentially take different values for
each instance of the component.
SCA DeplOyMent ArChiteCtureSCA specifies a packaging format for
bundling an SCA-based solution along with
its metadata and implementations into a
deployable entity called “SCA contribution”
(like zip archives). The SCA contributions are
deployed into “SCA runtimes” that manage
deployment and coordination of constituent
components of SCA contributions into
appropriate runtime containers. SCA
runtimes are conceptual middleware compo-
nents that can be ESBs that understand SCA
formats directly or a thin layer of middle-
ware that interfaces with the ESBs, keeping
ESBs immune to the details of SCA packag-
ing formats. Another example of SCA
runtime is the Java Business Integrator (JBI).
The concept of SCA contribution and the
deployment of the contributions into SCA
runtimes realized by the ESB infrastructure in
an SOA platform are shown in Figure 4. This
also shows how the development and life
cycle of SCA components and composites
can be governed via an SOA governance
framework, just like all other SOA artifacts.
2
Examples of properties are:
A “Currency” property which can take
values like Euro or Dollar.
A “Time-Zone” property that signifies a local time zone.
A component may also declare the inter-
faces it invokes (or needs) called “Refer-
ences”. References are interfaces supplied
by other components that a particular
component depends on or invokes to
accomplish its purpose. A component
can only define a single service interface
(the service it provides) but may have
multiple references (use multiple other
service interfaces).
In the SCA assembly model, other larger
components (called composites) may be
built recursively by assembling other
components or composites by “wiring”
them together (as shown in Figure 1). The
resultant SCA composite promotes one of
the constituent component service interfaces
as its own service and all unsatisfied
references as references of the composite.
All properties of the constituent compo-
nents also get exposed as the properties of
the composite.
SCA components and composites are
serialized into instances of documents in
the format defined by the SCA standard,
called Service Component Description
Language (SCDL). SCDL is an XML-based
description language used to capture the
SCA specific metadata associated with a
component. An example of an SCA compos-
ite serialized in SCDL is shown in Figure 2.
The composite’s service interface, constitu-
ent components, properties and references
are highlighted and correlated with the
pictorial depiction of the composite.
A multitude of like or disparate types of
components and composites can, in turn,
be integrated into solutions or applications
called “domains” (in SCA terminology).
One such integration is depicted in Figure 3.
•
•
Figure 2: SCA Composite Serialized in SCDi
Figure 3: Component/Composite integration into Domains
SCA SpeCiFiCAtiOnSSCA specifications went through compre-
hensive refinement and stabilization in the
OSOA consortium, of which Software AG is
a member. The ‘stable’ six key SCA specifi-
cations from OSOA were submitted to
OASIS last year and are being normalized
in six respective OASIS TCs.
The progress in OASIS has been very rapid
and Software AG expects the SCA specifica-
tions to become OASIS standards in less
than a year (most likely summer 2009). In
addition to contributing to the develop-
ment of the SCA specifications in OSOA,
Software AG has been a member of the
SCA-related technical committees in OASIS
since their inception and is involved in the
development of these specifications.
Figure 5 is an overview of the SCA specifi-
cations, illustrating their hierarchical
dependency. SCA specifications are split
into four major groups. The Assembly
group that sits at the top of the hierarchy
is the primary specification that defines the
SCA component and assembly model for
composing SCA components into compos-
ites and domains, etc. The assembly
specification also specifies the syntax for
the Service Component Description Lan-
guage (SCDL). The packaging and deploy-
ment aspects, including the SCA contribu-
tion meta-format, are also specified by the
SCA assembly specification. The SCA
binding specifications define the runtime
and protocol bindings for accessing/
invoking the service interface offered by
the SCA components. SCA currently defines
the binding for Web services (WS-*/SOAP
based) access, Java Messaging Service
(JMS), EJB Session Bean, Java EE Connectiv-
ity Architecture (JCA) and vendor specific
access method (called SCA binding). Other
bindings such as REST are in development
for future normalization. SCA language
specifications specify concrete language
mappings of SCA assembly model. They
specify how to define an SCA component
for an implementation in a specific lan-
guage (conversely how to realize imple-
mentations in a specific language as SCA
components). Currently the SCA language
specifications are available for Java (POJO,
EJB, Spring Framework), C, C++, BPEL and
COBOL. PHP and Ruby are also in develop-
ment. SCA policy specifications enable
specification of Quality of Service Policy
requirements of the components as policy
intents and bind them to concrete policy
specifications in the form of policy asser-
tions in concrete policy frameworks such as
W3C WS-Policy Framework and the related
WS-Policy Attachment mechanisms. The SCA
policy Framework also makes it possible to
attach different policy requirements based
on the specific bindings for the interfaces
(and references) of the subject SCA compo-
nents and composites.
3
Figure 4: SCA Contribution and Deployment of Contributions into SCA runtimes
Figure 5: SCA Specifications Overview
COnCluSiOnThe SCA suite of specifications is a major step forward in realizing the SOA promise of
service re-use and recursive composition. SCA provides a programming model for building
composite applications and systems based on the SOA principle that business function is
provided as an aggregation of reusable service components assembled together to create
solutions that serve a particular business need. These composite applications contain both
new services created specifically for the application and business function from existing
systems and applications implementations, reused as part of the composition. SCA provides
a model both for the composition of solutions and for the creation of service components,
including the reuse of existing application function within SCA compositions. SCA also
defines a packaging and deployment model that is aligned with runtime infrastructure
