Re: [sca-assembly] Restating issue 249

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Four comments on this (based on perhaps a misunderstanding on my part):
1) I'm still confused about this. This really seems to be about defining 
message metadata (similar to JMSReplyTo). But I do understand that for 
some usecases you may want to configure what that response "endpoint" 
is, in the composite.
2) In the proposal, you are identifying a consumer inside a producer. 
That just *seems* wrong in terms of violating the pub-sub model 
(publishers are unaware of who the consumers are, if any).
3) But of more importance, this is just one pattern (one publish message 
with possibly one or more responses coming back). There are several 
patterns possible. For example, should I be able to configure "response 
destinations" and "fault destinations".
4) I should also note that we have removed bindings for 
consumers/producers and this "wireByImpl" for eventing introduced that 
back in.

Please do correct me if I got the proposal wrong.

-Anish
--


On 11/18/2010 4:55 PM, Eric Johnson wrote:
> 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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php