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 supporta , which is not always an optimal transport for SOA implementation.
- The majority of them provide only synchronous and one-way service invocationb , 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 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
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 Entities||Annotations|
|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||Method||Annotate method with [OperationBehavior]|
|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 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 Computing8 - "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
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.
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.
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 email@example.com
1 Michael Beisiegel, Henning Blohm, Dave Booz, Jean-Jacques Dubray, Adrian Colyer, Mike Edwards, Don Ferguson, Bill Flood, Mike Greenberg, Dan Kearns, Jim Marino, Jeff Mischkinsky, Martin Nally, Greg Pavlik, Mike Rowley, Ken Tam and Carl Trieloff. "Service component architecture. Building systems using a service oriented architecture", November 2005
2 B. Lublinsky. "Web services invocation framework, part 1." WebSphere Developers Journal, June 2003.
3 B. Lublinsky. "Web services invocation framework, part 2." WebSphere Developers Journal, July 2003.
4 Rob High, Jr., Stephen Kinder, Steve Graham. "IBM's SOA Foundation. An Architectural Introduction and Overview". November, 2005.
5 "Windows Communication Foundation Architecture Overview". Microsoft Corporation. March 2006
6 David Pallmann. "Programming Indigo: The Programming Model". July 2005.
7 Chris Peiris. "Indigo programming model". 15 seconds, June 2005.
8 Steve Vinoski. "Java business integration". IEEE Internet Computing, July 2005.
9 "JSR 208: Java Business Integration (JBI)".
10 "Specifications: Service Component Architecture (SCA) and Service Data Objects (SDO)".
11 Tom Stahl and Markus Vlter. "Model-Driven Software Development. Technology, Engineering, Management." Wiley, 2006.
12 Nigel Daniels. "Developing Custom Mediations for Websphere Enterprise Service Bus". Developworks, January 2006.
13 Roland Barcia and Jeff Brent. "Building SOA Solutions with the Service Component Architecture - part 1." IBM WebSphere Developer Technical Journal, October 2005.
14 Roland Barcia and Jeff Brent. "Building SOA Solutions with the Service Component Architecture - part 2." IBM WebSphere Developer Technical Journal, December 2005.
a Although proprietary extension in Apache Axis and Websphere provide JMS support, and MSMQ is supported by Indigo (see below) these implementations are non-standard.
b Although WSE 2.0 and above and JAX-WS provide support for certain types of asynchronous invocations, these implementations have limitations and are still far from main stream SOA implementations.
c WS-* stands for collection ofWeb Services standards, including WS-Security, WS-Atomic transactions, WS-Addressing, WS-Policy, WS-ReliableMessaging, etc.
d Although this is correct theoretically, many of the current WS-* specifications are still evolving, which often breaks advertised interoperabity, due to the different versions of standards, implemented by different vendors.
e This kind of interception is a foundation of any container technology, for example J2EE application servers, Microsoft’s MTS, etc.
f The term "container" is used in two ways in JBI specification. A service engine can function as a container for engine-specific functionality, while the JBI environment itself is a container for service engines and binding components. Because of this, JBI is sometimes called a "container of containers" 9.
g Canonical message representation should not be confused with the canonical message structure olso often employed in EAI brokers. Canonical message representation supports technical interoperability, while the purpose of canonical message structure is to provide business interoperability.
In fact, I do believe that WS-Management which is WS standard for resource management, does have some similarity with what REST is trying to accomplish
JBI v SCA
JBI has issues to really solve the product integration challenge (needs to be multi-VM at least) but is a good "under the covers" solution to the old problem of it taking longer to integrate the products than actually do the integration to other systems. ( from Mike's blog)
SCA is again early but is a cracking model for design and development of services.
WCF is great for invocation, but IME its weak at the actual design/deploy of the services themselves as the concept of a deployable component/service isn't really baked into .NET in the same way as it is with the Java vendors.
Why not version 0.95?
- The article references version 0.9 - why not 0.95, which has been the current version since late August.
- A reference for catch-up on SMOs would be nice. Searching osoa.org for Service Message Object does not give a single hit.
- It would be nice to have the composition model commented.
Although not referenced in the article, I think it is interesting to see the SCA specification (Java binding) line-up to the implementations of dependency injection: Java EE 5, OSGi, SCA...
Re: Why not version 0.95?