Comparing SCA Specification to Mule ESB

Bird's eye view of the SCA specification and comparison of concepts and terms with Mule ESB.

The SCA specification consists of four main elements:

• Assembly Model - Describes a model for service assembly.

• Component Implementation Specifications - Describe how busniness logic can be written in different languages.

• Bindings Specifications - Describe the access mechanisms used to call services.

• Policy Framework - Enforcement mechanism for non-functional requirements

Assembly Model

The SCA Assembly Model consists of a series of artifacts which define the configuration of an SCA system in terms of service components which implement and/or use services and the connections which describe how they are linked together. The assembly is defined in terms of a set of SCA composites, which define components and reference the implementation code that provide business function and which also describe services and references and the wires that link them.

The assembly model is defined by a number of concepts and the specification of the the configuration of their assembly:

Component

"Components are configured instances of implementations. Components provide and consume services. More than one component can use and configure the same implementation, where each component configures the implementation differently."

A SCA Component is directly analogous to a Mule Service (2.0) or Mule Descriptor (pre 2.0)

Service

"The externally accessible software functionality of an implementation"

In Mule, SCA Services are Inbound Endpoint's, each mule descriptor having one or more inbound endpoints through which service consumers invoke the service.

Reference

"A dependency on another service."

In Mule, the closest concept to that of SCA Reference is Outbound Endpoint, which may be configured and used as within outbound routers or nested routers. These outbound endpoints are used to forward messages to other mule/external services either sync or async.

Implementation

"Component implementations are concrete implementations of business function which provide services and/or which make references to services provided elsewhere. In addition, an implementation may have some settable property values. SCA allows you to choose from any one of a wide range of implementation types, such as Java, BPEL or C++, where each type represents a specific implementation technology."

In Mule, SCA Implementations are Service Components. Mule allows Java POJO implementations which are retreived from Container Contexts (Spring, Hiveming, EJB, Pico etc) and script components. Other implementation types are easily added by wrapping them in a java service component implementations.

Properties

"Properties allow for the configuration of an implementation with externally set data values"

In Mule, mule service/descriptor properties are very similair to SCA implementation properties. The only difference is that in SCA they are implementation properties while in Mule these properties are set on the descriptor/service (SCA Component) and are available to the implementation.

Composites

"Composites can contain components, services, references, property declarations, plus the wiring that describes the connections between these elements.

In Mule, Composites are simialiar to the Mule Model in that both contain a number configured Mule Services or SCA Component. Where they differ is in the way composition is implemented; in SCA a composite has services/references and composes components and/or other composites... whereas in Mule a model is a just a set of Mule services configured within a single model element in the same configuration file with the same model type (e.g. SEDA, Streaming)

Interfaces

"Interfaces define one or more business functions. These business functions are provided by Services and are used by References. A Service offers the business functionality of exactly one interface for use by other components. Each interface defines one or more service operations and each operation has zero or one request (input) message and zero or one response (output) message."

SCA currently supports 3 interface types i) Java ii) WSDL 1.2 portTypes iii) WSDL 2.0 Interfaces
SCA has the following concepts: local interfaces, remotable interfaces, bidirectional interfaces, callback interfaces and conversational interfaces

Mule does not define services with interfaces. The Callable interface is optionally used internally to resolve the component entry-point but this does not compare with SCA service interfaces as it is not an outwardly visable interface available to the service consumer.
Mule web-service endpoints are the only endpoints that define interfaces, this is done through the axis/xfire web-service stacks.

SCA Domain

There is no specific term for this in Mule, but it is basically a Mule-based solution which is deployed to a set of servers.

Component Implementation Types

Component implementation types or "Client and Implementation" specification define the way in which different technologies can be used to implement SCA service components. They define the way in which these technologies should be used with the SCA assembly model and any technology specific interfaces that will be used.

SCA

• Java
• Spring
• BPEL (Requires WSDL interface types on participant services)

Mule

• Java
• Spring, Hivemind, Pico etc.
• Scripting

Bindings

SCA Bindings apply to services and references. Bindings allow services to be provided, and references to be satisfied, via particular access methods or transports. This is almost identical to the concept of transports in Mule.

SCA

Mule

Policy Framework

The capture and expression of non-functional requirements such as security is an important aspect of service definition, and has impact on SCA throughout the lifecycle of components and compositions. SCA provides the Policy Framework to support specification of constraints, capabilities and Quality of Service (QoS) expectations, from component design through to concrete deployment. This specification describes the framework and its usage.

Mule implement transactionality and security declaratively. A number of the SCA policy "intents" are implements in Mule but not through a policy framework as such.