SOA Programming Models

As the adoption rate of the Service-Oriented Architecture grows, it becomes more

apparent that the level of abstraction, provided by Web Services APIs (the most
popular technology for SOA implementation today), for example JAX-RPC in Java or
Web Services Extension (WSE) APIs in .Net, is not sufficient for effective SOA
implementations:
 The semantics of these APIs is geared more toward technical aspects of services
invocations and SOAP processing, then toward service usage and support.

 The majority of them provide only SOAP over HTTP support a , which is not always an
optimal transport for SOA implementation.
 The majority of them provide only synchronous and one-way service invocation b ,
which are only a subset of the service interaction styles.
 These APIs are directly exposed to the implementation code which leads to the
following:

o Business implementation code often gets intertwined with the service

communications support, which makes its harder to implement, understand,
maintain and debug.

o Any API changes (which usually happen at least once a year) require changes
in the business implementation.
 These APIs do not directly support many important service runtime patterns. For
example, implementation of dynamic routing requires custom programming and
usage of additional APIs (JAX-R in Java) for accessing registry.
In attempt to fix some of the issues of the current APIs sets there are currently
attempts underway to raise the level of abstraction through defining SOA
programming model (with many elements borrowed from other technologies), which
aim to reduce the complexity to which application developers are exposed to when
they deal directly with middleware or web services specific APIs. By removing the
majority of communications support from the business code and hiding it behind
programming model abstraction/implementation this approach facilitates 1:
 Simplified development of business services

 Simplified assembly and deployment of business solutions built as networks of

services

 Increased agility and flexibility

 Protection of business logic assets by shielding from low-level technology change

 Improved testability
One of the first attempts to create such type of model was Web Services Invocation
Framework (WSIF) 2 3 originally introduced by IBM and currently part of Apache
foundation.
WSIF attempted to align service usage model with the WSDL-based service
definition-WSIF APIs directly support WSDL semantics. This enabled WSIF to provide
a universal invocation model for different implementations of services over different
transports. Although WSIF never gained wide adoption by itself, it is used by many
BPEL engines, for example WPC from IBM and BPEL Manager from Oracle, as an API
for service invocations.

The three models currently gaining most popularity for SOA implementations are:
 Windows Communication Foundation (Indigo) programming Model from Microsoft,
which attempts to simplify service programming by creating a unified OO model for
all service artifacts.

 Java Business Integration (JBI) model from Java Community Process, which address
complexities and variabilities of services programming through creation of services
abstraction layer in a form of a specialized (service) container.

 Service Components Architecture (SCA) from IBM, BEA, IONA, Oracle, SAP, Siebel,
Sybase, etc., is based on the premise that a "well-constructed component based
architecture with well-defined interfaces and clear-cut component responsibilities can
quite justifiable be considered as an SOA" 4.

These programming models attempt to go beyond just service invocations by

seamlessly incorporating service orchestration support and many of the patterns
required for successful SOA implementation. They also serve as a foundation for
implementation of the Enterprise Service Bus. We will give a brief overview of each of
these programming models in this article.

Indigo Programming Model

Indigo is the latest implementation of the programming model for service oriented
architecture from Microsoft, supporting a rich set of technologies for "creating,
consuming, processing and transmitting messages". Indigo is planed to be released
with the next version of Windows-Vista.
A service is defined in Indigo as a program exposing a collection of endpoints, with
each endpoint defined as a combination of three major elements 5:
 The Endpoint's address-a network address through which the endpoint can be
accesses.

 The Endpoint's Binding specifies additional detail defining communications with

endpoint including transport protocol (e.g., TCP, HTTP) and policies-encoding (e.g.,
text, binary), security requirements (e.g., SSL, SOAP message security), etc.

 The Endpoint's Contract-specification of operations, exposed by this endpoint,

messages, used by these operations and Message Exchange Patterns (MEPs) such as
one-way, duplex, and request/reply.
Such definition effectively extends WSDL-based service definition by allowing to
expose the same functionality (service) through multiple endpoints with different
bindings and endpoint contracts (QoS).

A foundation of Indigo's programming model is OO implementation of all aspects of

SOA programming.
SO Entities OO Annotations
Entities

Service contract Interface Annotate interface with [ServiceContract]

Service operation Method Annotate interface method with [OperationContract]

Implementation class Class Annotate class with [ServiceBehavior] and derive it from service
contract interface.

Implementation Method Annotate method with [OperationBehavior]

method

Data contract Class Annotate class with [DataContract] and its members
with [DataMember]

Table 1 Relationship of SO Entities to OO Entities in Indigo.

Table 1 shows the mapping (defined by Indigo programming model) between SO
and OO concepts and the annotations that link them together 6. This fusion of SO
and OO is simultaneously a major strength and weakness of Indigo:
 OO is a well-established paradigm familiar to the majority of developers. This means
that the can start developing new Service-Oriented Architecture solutions using a
familiar techniques. Indigo runtime, in this case, converts, under the covers, OO style
invocations into interoperable SOAP messages for communications.

 SO is significantly different from OO. Usage of OO as a mechanism for defining and

implementing services can create a significant implementation mismatch (granularity,
coupling, etc.), which might leads to suboptimal or even plainly bad Service-Oriented
Architecture implementation.

Indigo supports two major approaches to the service invocation:

 RPC style invocations (both synchronous and asynchronous) carrying lists of typed
parameters (initial Web Services vision). This type of service invocations is similar to
the traditional methods invocations, used in distributed objects and RPC
implementations. Messaging style invocations (both synchronous and asynchronous).
These types of service invocations are similar to the traditional messaging systems
(compare to semantic messaging introduced earlier in the book).
Depending on the what type of access service provides (RPC vs. Messsaging), its
contract is defined either in the form of interface (RPC) or message (Messaging)
contract (see Table 1).
Another foundational feature in Indigo is introduction of connectors - managed
framework, providing secure and reliable communications - for accessing of service
endpoints. Usage of connectors reduce the amount of the "plumbing code" required
for building of interoperabale services, consequently simplifying creation of a web of
"connected systems" 7. This is achieved by separating "plumbing" into separate
classes (class hierarchies) and providing a "standard" implementation in most cases.
The Indigo connectors use a small number of concepts (port, message, channel) to
allow invoking of services independent of transport or target platform. The most
important of these concepts is a channel, which represents a core abstraction for
sending and receiving messages to and from a port. There are two categories of
channels defined in Indigo 5:
 Transport channels handle support for a specific transport, for example HTTP, TCP,
UDP, or MSMQ and topologies, for example, point-to-point, end-to-end through
intermediaries, peer-to-peer, publish and subscribe.

 Protocol channels handle support for specific QoS characteristics, for example,
security channel encrypts message and adds security header. Indigo uses WS-
*c specifications for implementation of protocol channels. Adherence to the standards
makes Indigo's implementation interoperable with other systems, based on WS-*
complaint implementation d.

Indigo also support the notion of channels composition-layering of channel on top

of another channel. For example, a security protocol channel can be layered over
HTTP transport channel to provide secure communications over HTTP.

The Indigo connector has a build in support for intermediaries including firewalls,
proxies, and application-level gateways. These intermediaries are the foundation for
implementation of many of the patterns required for successful SOA implementation,
including message validation, security enforcement, transport switching, monitoring
and management, load balancing and context-based routing.

In addition to supporting creation of the business services, Indigo provides several

system services, that can be used by by any business service implementation.
Examples of such services are:
 Identity federation. This service is based on WS-Federation and supports
management and validation of identities both internally in the enterprise and from
foreign trust boundaries. Its implementation provides authentication brokering
between the service and the corresponding trust authority.

 Transactional support. This service is based on WSAtomicTransactions specification

and simplifies service-based transactional programming (it supports SQL Server,
ADO.NET, MSMQ, distributed transaction coordinator (DTC), etc).
JBI Programming Model

Capitalizing on the success of applications servers for hosting applications, Java

community process has based its JBI implementation on a notion of a service
container.
As defined in Java business integration. IEEE Internet Computing 8 - "JBI is a pluggable
architecture consisting of a container and plug-ins. The container hosts plug-in
components that communicate via message routers. Architecturally, components
interact via an abstract service model-a messaging model that resides at a level of
abstraction above any particular protocol or message-encoding format."

In the JBI-based implementation services do not interact with each other directly.
Instead, similar to the message broker architecture widely adopted in EAI
implementations, JBI container acts as universal intermediary routing messages
between services (Figure 1).

Figure 1 Mediated Message Exchange through JBI

This separation of the participants in an exchange - foundation of JBI architecture 9-
provides a layer of decoupling between service providers and consumers and
simultaneously a well-defined place for mediating service traffic (inserting all of the
additional required functionality) e.

Mediations, in this case, can support a wide variety of functionality, ranging from
message transformation and security enforcement to content-based routing and
service versioning.
JBI container hosts two distinct types of plug-in components 9:
 Service Engine (SE). SEs are essentially standard containers for hosting service
providers and service consumers that are internal to the JBI environment f. Example of
SEs often present in JBI environment are data transformers, business rules containers
and BPEL engines.
 Binding Component (BC). BCs provide connectivity to services consumers and
providers external to a JBI environment. BCs allow to integrate
components/applications that do not provide Java APIs and use remote access
technologies to access them.
Interactions between plug-in components employ standardized service definitions
based on WSDL 2.0. WSDL 2.0 definitions provide shared understanding, between
services consumers and providers and serves as a foundation of interoperability in JBI
implementations.
In addition to standardized service definitions JBI uses the notion of "normalized"
messages supporting global components interoperability. Message normalization
allows for mapping protocol and business specific context into a generic,
transportable fashion and is similar in concept to introduction "canonical" message
representation often used by EAI implementations g.

Each JBI container exists within a single JVM and houses all BCs and SEs, belonging
to this container along with a set of services, providing operational support for SEs,
and BCs implementation.
JBI also defines a standard set of JMX-based controls allowing external administrative
tools to perform a variety of system administrative tasks, as well as administer the
components themselves. This administration support provides standard mechanisms
for 9:
 Installing plug-in components.

 Managing plug-in component's life cycle (stop/start etc.)

 Deploying service artifacts to components.

Service component Architecture

Although Service Component Architecture (SCA) 10 is defined as a specification

defining a model for building systems using Service-Oriented Architecture it is
effectively a model for composing components into services extended to additionally
support composition of services into solutions.
SCA is based on two main metamodels 11:
 Type metamodel

 Composition metamodel

Type metamodel

This metamodel (Figure 2) describes component types, interfaces, and data

structures 11.
Figure 2 Metamodel for components, interfaces, and their dependencies
A component implementation is defined by the following four groups of
specifications 10:
 Provided interfaces-set of interfaces, defined by a component. These interfaces are
usually defined as WSDL port type or language interface, for example Java or C++. A
component can expose zero or more interfaces. Each interface is comprised by
several methods.

 Required specifications (references)-set of interfaces used by a component's

implementation. These interfaces are usually defined as WSDL port type or language
interface, for example Java or C++. Component can have zero or more references.

 Properties that may be set on the component to tailor or customize its behavior. Each
property is defined as a property element. Component can contain zero or more
property elements.

 Implementation artifacts defining the implementation of the component. SCA allows

for many different implementation technologies such as Java, BPEL, C++, SQL, etc
SCA defines an extensibility mechanism for introducing new implementation types.

Composition metamodel

This metamodel (Figure 3) defines component instances and how they are
connected 11.
Figure 3 Component instances and their connections in the composition
metamodel

A notion of instance in this metamodel is different from the notion of instance used
in OO. A component instance here is a component implementation with complete
resolved set of properties, modifying component behavior for solving of a particular
problem.

A composition defines a number of component instances, interacting with each

other, where interactions are defined using wires.

Wiring in SCA abstracts out most of the infrastructure level code (similar to channels
in Indigo). For example, wires can be defined to be synchronous or asynchronous,
support transactional behavior of components invocation, etc. SCA handles this
infrastructure details under the covers. A wire can also connect between different
interface languages (e.g. Java interfaces and WSDL portTypes/interfaces) in either
direction, as long as the operations defined by the two interface types are equivalent.

In addition to wires SCA also supports module to module communications through

special types of components-imports and exports. Combination of wiring, import and
export components, allows for components referencing external services.

Component's composition, defined by composition metamodel is both similar and

different from the service composition, although both of them define the way to
make components/services work together. Service composition allows enhancing the
functionality of participated services through functionality introduced by the
composition itself, while this metamodel defines only connections between
components (closer to the service implementation).
SCA implementations rely on the Service Data Objects (SDO) 10, providing the
technology to represent a universal model for data. SDOs are the basis for the data
exchange in component's interactions. The fundamental concept in the SDO
architecture is the data object-a container holding primitive typed data and/or other
data objects. Information about included data is provided by metadata, explicitly
referenced by the data object. A combination of the data objects in SDO is
represented by the data graph. In addition to the objects themselves, this graph
contains a change summary that is used to log information about what data objects
and properties in the graph have changed during processing (similar to ADO in
Microsoft environments). In addition to SDOs SCA introduces Service message
objects (SMOs) which provides an abstraction layer for processing and manipulating
messages exchanged between services (compare to normalized messages in JBI).
SCA is currently in its infancy (version 0.9 at the time of writing) and does not
support the majority of patterns required for SOA implementation. Instead, current
SCA implementation from IBM-Websphere ESB/WPS 6.0 introduces mediation
framework 12, based on SCA and providing a well-defined mechanisms for mediation
implementation and placing (similar to intermediaries in Indigo).
SCA implementation is especially powerful, when it is supported by GUI, allowing for
graphical connection of the components on the palette, the way it is implemented in
IBM's WebSphere Integration developer (WID) 13 14.