[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 Description: 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]