SCA Extensions for Event Processing and Pub/Sub
A new SCA specification, Assembly Model Specification Extensions for Event Processing and Pub/Sub describes the Event Processing and Pub/Sub Extensions for the SCA Assembly Model, which deals with:
- Event Processing, which is computing that performs operations on events, including creating, reading, transforming, and deleting events or event objects/representations. Event Processing components interact by creating event messages which are then distributed to other Event Processing components. An Event Processing component can, in addition, interact with other SCA components using SCA’s regular service invocation mechanisms.
- Publication and Subscription (often shortened to Pub/Sub), which is a particular style of organizing the components which produce and consume events in which the producing components are decoupled from the consuming components. Components that are interested in consuming events specify their interest through a subscription rather than an interface. The same event may be received by multiple subscribers.
The introduction of event processing provides a more loosely-coupled method of combining components than using service interfaces. Events place fewer requirements on the components at each end of the communication. Effectively, in event processing it is only the event types that are shared between the producers and the consumers. Even looser coupling can be achieved through the use of Pub/Sub. In this case, producers are not connected directly to any consumers, instead producers are connected with consumers through a logical intermediary - the pub/sub engine.
In SCA, event producers can be linked to event consumers via a third party called a channel, where producers are configured with the channel as a target and consumers are configured with the channel as a source. A producer declares where the messages it produces are sent through a list of one or more target URIs in its target attribute. A consumer declares the sources for the messages it receives through a list of one or more source URIs in its source attribute.
A channel is a new SCA artifact that is used to connect a set of event producers to a set of event consumers. The channel can accept events sent by many producers and it can send all of these events to each consumer which is subscribed to the channel. The channel exists separately from any individual producer or consumer. A channel acts as if it has a single consumer element with the name "in", to which producers can send events. A channel acts as a single producer element with the name "out", from which subscribers receive events. A channel may be configured with filters, which define the set of events that the channel accepts. If an event does not match the filters defined, the event is discarded.
Channels can exist either at the domain level or they can exist within a composite used as an implementation. Channels at the domain level can be used as targets for producers at any level within the composition hierarchy. They can be used as sources for consumers at any level within the composition hierarchy. Channels within a composite used as an implementation are private to the components within that composite. These private channels can only be the targets for producers existing within the same composite as the channel. Private channels can only be sources for consumers existing within the same composite as the channel.
This division of channels into global channels and private channels permits the assembler of a solution to control the set of components involved in event exchange, if required. Producers and consumers of global channels are effectively uncontrolled - they exist at the domain level and they can be added or removed at any time through deployment actions. Private channels have restricted sets of producers and consumers - these sets are decided by the assembler when the composite container is created.
Support for consuming and producing messages by a component is implemented through adding consumer and producer tags to a component definition. The component element can have zero or more consumer elements as children, which are used to configure the consumers of the component. The consumers that can be configured are defined by the implementation. The component element can also have zero or more producer elements as children which are used to configure the producers of the component. The producers that can be configured are also defined by the implementation.
Events in SCA have an event type associated with them. Each event type is identified by a unique event type name. An event can have no event type metadata associated with it - for example, this can be the case for events which are created by pre-existing non-SCA event sources. SCA has a canonical representation of event types in terms of XML and of event shapes in terms of XML schema. SCA event shapes are describable using an XML infoset, although they don't have to be described using XML Schema, other type systems could be used. SCA events can have a wire format that is not XML. Events can also have programming language specific representations. The details of the mapping between language specific formats and XML are defined by the SCA implementation language specifications.
With continuing convergence between SOA and EDA, the introduction of events support in SCA strengthens its position as a premier SOA programming model.
What About OASIS?
This is unfortunate because it does not align with promoting SCA as an open standard. It appears as if the vendors are interested only in slapping a standards label on their existing products rather than gaining community feedback.
Olav Maassen, Liz Keogh & Chris Matts Mar 08, 2014