Access Keys:
Skip to content (Access Key - 0)
community header community tab mule tab ibeans tab muleforge tab

Gap Analysis: The difference between what is needed and what is available. The difference between where you are and where you want to be.

Functional Gaps

This page describes the elements of the SCA specification (beyond configuration syntax) that mule does not support, or does not fully support that would be required to make Mule SCA compliant.

Composites

SCA has the notion of composites, that is services that are built from other services. Mule too allows you build services from other services but differs in approach.

The implementation of composite services in SCA is explicit and declared through the wiring of services and references. In mule service composition is implemented in more open, event-based manner via message routing between endpoints.

What would be required to support SCA style composite?

This is the equivalent of taking a Mule model and making this available as a single unit, a service in it's own right. The features of the model then could be overriden when specific implementations of the model are used.

Conversational State

This is correlation across multiple invocations.

Interface Specification

The interface between components can be specified and may include WSDL or Java interface definitions.

Multiple Implementation Types

A component can be specified to be implemented in more than one implementation type, e.g. Java/WSDL.

Policies

In SCA a policy is a declaritive specification of non-functional contractual obligations on services. In SCA this is a unified concept, in Mule currently this is a collection of mostly imperative configurations.

Adaptavist Theme Builder (3.3.3-conf210) Powered by Atlassian Confluence 2.10, the Enterprise Wiki.
Free theme builder license