OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Restating issue 249

I don't want to just change the issue directly unless someone advises me 
that that is the correct thing to do.

Here's my restatement of the issue:

Title: Need some way for assembler to indicate subsequent "destinations" 
in conjunction with a producer, and a binding thereof.

Target: Assembly 1.2 WD 01

For some uses of eventing, a key point of using an event driven system 
is to decouple a collection of asynchronous interactions.

For example, consider components A, B, and C that send a messages to a 
channel (Channel-Z).  Events from Channel-Z then arrive at component D.  
Component D then produces events in reaction to what it received, and 
those subsequent events from D go to different destinations based on 
which component from which the received event came.

One possible way to accommodate such an approach according to the 
current draft, is to add data to the event corresponding to where it 
originated, and then have D look at that data to decide which producer 
to send subsequent messages to.  However, if I were to then introduce a 
fourth and fifth component called E & F, and they also send to 
Channel-Z, then with the approach just outlined, component D may have to 
change to address the introduction of those components.

To avoid changing D, and to reinforce the loose coupling of the 
composition, I want the assembler of the composite to control this 
dispatch, rather than having the implementation of the component D do 
so.  A key way to do this is to allow the composer to associate one or 
more destinations in conjunction with an outgoing event.  Then, upon 
receiving messages from Channel-Z, the implementation of component D can 
request the destination from the incoming message, and use that for the 
subsequent messages it sends (if any) in reaction to the incoming 
messages.  Note that component D now does the exact same thing for all 
messages, rather than having special handling based on message contents.

Note that it may be useful to associate more than one destination with 
the outgoing event from the original component (A, B, C, E, F)

Concretely, JMS, for example, includes the JMSReplyTo property. This 
allows for asynchronous communications, and allows for the sender to 
dictate a single piece of information as to where the "response" should 
go, eliminating any direct architectural coupling of the receiver with 
the sender. Note that "response" here is quoted, because although that's 
the label assigned to this JMS Message header, it need not, strictly 
speaking, be used in that capacity.  Note that the JMS model is 
limiting, in that as spec'd, it only allows an obvious way to carry a 
*single* destination, so while this is a useful concrete example, it has 
limits that should not be applied to the general model.

I conclude that for the purposes of further decoupling eventing in SCA, 
while enhancing its capabilities, it is desirable to have the ability on 
the "producer" side to send a message with coupled with metadata that 
contains one or more addresses, where those addresses point to some 
other consumer on the component, or to a channel in the composite.

Note that the addresses could have any number of labels and intents, 
including "replyTo", "relatesTo", "buySellOrders", "followUp", 
"notifications", etc....  The general point is that the producer has the 
ability to send such destinations, not that the consumer of these events 
has to process them.

To fully exploit this additional capability, it is also essential to 
have producers which are "wired-by-impl".  In the example above, 
component D has to be able to get the destination from the incoming 
event and use apply said destination as needed when it sends events.

Abstract proposal:

On a producer add an optional element (zero to N occurrences):
<sendDestination destinationLabel="..." @channel=" (name of channel in 
composite)"? @consumer="(name of consumer on component)"/> *
(can either send the destination of a channel, or a consumer, but not 
both.  Note that perhaps not all bindings will allow both)

On a producer, add an optional attribute @wiredByImpl
(The above has a cascading effect in that implementations may need to be 
able to set the destination, and also therefore need to extract it from 
the incoming event.)

On a consumer add an optional attribute:
@receiveDestinations="destLabel1 destLabel2 destLabel3 ..."

This completes my action item to update the text of ASSEMBLY-249.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]