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:
  • Business implementation code often gets intertwined with the service communications support, which makes its harder to implement, understand, maintain and debug.
  • 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 ¹:

• 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" ⁴.

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 ⁵:

• 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.

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 ⁶. 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" ⁷. 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 ⁵:

• 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 supporta 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⁸ - "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 ⁹- 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 ⁹:

• 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 ⁹:

• 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) ¹⁰ 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 ¹¹:

• Type metamodel
• Composition metamodel

Type metamodel

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

Figure 2 Metamodel for components, interfaces, and their dependencies

A component implementation is defined by the following four groups of specifications ¹⁰:

• 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 ¹¹.

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) ¹⁰, 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 ¹², 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}.

About the author

Boris Lublinsky has over 25 years experience in software engineering and technical architecture. For the last several years he focused on Enterprise Architecture, SOA and Process Management. Throughout his career, Dr. Lublinsky has been a frequent technical speaker and author. He has over 40 technical publications in different magazines, including Avtomatika i telemechanica, IEEE Transactions on Automatic Control, Distributed Computing, Nuclear Instruments and Methods, Java Developer’s Journal, XML Journal, Web Services Journal, JavaPro Journal, Enterprise Architect Journal and EAI Journal. Currently Dr. Lublinsky works for the large Insurance Company where his responsibilities include developing and maintaining SOA strategy and frameworks. He can be reached at blublinsky@hotmail.com

References: