Re: [sca-assembly] Restating issue 249

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

On 11/23/2010 11:00 AM, Eric Johnson wrote:
>   Hi Anish,
>
> I realize that this is somewhat moot, unless we, for some reason,
> realize that we need to bring this up again, but as with the entire
> discussion around this point, either I'm writing down my thoughts
> poorly, or the myriad interpretations of the terms gets in the way of a
> simple and short description.

I suspect it is the later. With event processing or pub-sub, in my 
experience this happens a lot and I'm certainly guilty of having some 
preconceived notions of things based on past experience. As far as my 
POV goes, I'm interested in keeping the model simple (compromise being: 
we don't necessarily address every usecase now, as long as it is 
possible via extensions -- where exactly that compromise point lies will 
certainly be a matter of opinion/art).

> I could write up a long document that
> clarifies all the terms, but that makes the issue look suspiciously
> complex. Or I can use overloaded terminology, and express myself more
> concisely, and leave lots of misinterpretation. Seems like I've managed
> to accomplish neither!
>
> On 11/22/10 11:58 PM, Anish Karmarkar wrote:
>> 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.
> Well, OK, but then why wouldn't we open this issue to try to address
> that? I stayed away from calling this a generic definition of message
> metadata, because that's a much more complicated question. Technically,
> the issue is specifically about defining the values and labels of the
> message metadata specifically for use communications
> endpoints/destinations/topics/subjects.
>

I understand. But with that we introduce a notion of a "callback" to a 
event message. And that does bring in a lot of other issues.

>> 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).
>
> Specifically, in the proposal for the issue (as opposed to the issue
> itself) as *one* possible implementation, the configuration of the
> producer might point at a consumer. Alternately, it could point at a
> channel. That's because I think it has utility, but as you note, that's
> part of the proposal, not part of the issue itself. I wouldn't have been
> surprised to see the TC argue for taking that out, had we gotten there.
>
> This is one of those places where the terms get in the way. Generically
> referring to a "destination" relies to heavily on a JMS-specific
> world-view. Calling it a "channel" is a too-narrow view of the possible
> useful options. Calling it an "endpoint" makes it seem like it might
> exclude "channels/topics" I couldn't figure out a good all-inclusive
> term for what to call this notion of a communications target. URI comes
> close (see mailto:, jms:), although that's heavily associated with the
> "services" world-view, and with specific bindings.
>

Curious as to why you think 'channel' is too narrow? Is it because it 
does not include a JMS Queue?

> But I take issue with the complaint that in the pub-sub model, producers
> never know who the consumers are, because I wasn't suggesting that they
> should. The issue specifically calls out that the /assembler/ does the
> wiring. So the configuration of the producer in the composite might
> point at consumer, but that doesn't strike me as the same thing as
> having the producer itself "know".
>

But when the assembler sets it, it would be injected into the producer 
(at least in one kind of implementation) and therefore very visible to 
the producer. Furthermore, think about a deployable composite. It would 
get deployed to the domain. The assembler when she created the composite 
may think that she did the Right Thing wrt identifying the consumers of 
a producer's message and their settings, but in the domain, other 
composites may come and go and therefore additional consumers may come 
into the system which may not be "taken care of".

>> 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".
>
> Right, I specifically called that out in the issue, and the proposal to
> resolve the issue. See:
>
> <sendDestination destinationLabel="..." @channel=" (name of channel in
> composite)"? @consumer="(name of consumer on component)"/> *
>
> See that little "*" at the end? Easy enough to miss. Although I did say
> "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) "
>

Actually, I did notice the '*', which would allow for multiple 
<sendDestination>s. What I was trying to say was that this is just one 
pattern, other patterns exists which may require:

<replyDestination ...>*
<faultDestination ...>*


>> 4) I should also note that we have removed bindings for
>> consumers/producers and this "wireByImpl" for eventing introduced that
>> back in.
>
> As I mentioned in the call "wired-by-impl" is perhaps a misnomer -
> routed by impl is more accurate? The issue indicates that the data has
> to be carried by the binding, but doesn't indicate that the binding is
> on the producer/consumer. I'm afraid you read more into this.
>

Ok, got it.

>>
>> Please do correct me if I got the proposal wrong.
>
> Despite trying to capture this over several weeks, it still appears I'm
> expressing the problem in a way that leads to misunderstandings.
>
> I do see that this issue does break into several parts:
>
>     * Sending destination as part of an event payload - I argue, and
>       think I've convinced a number of people - that being able to do
>       this /increases/ the possible ways to decouple an event oriented
>       system. However, this leaves open two problems - no standardized
>       way to use that destination at the consumer, and no model
>       validation in that if a consumer declares "I expect sellOrders
>       destination", and nobody wired to the channel provides it,
>       modeling the information gives us a way to catch the /assembly/
>       problem.
>           o Ancillary question - what kinds of destinations are you
>             allowed to send? Channels, clearly, but what about consumers
>             or services?
>           o Ancillary question - perhaps we need the same kind of
>             pattern with services ("send reply to", "send fault to",
>             "send sell order to") - where currently, we effectively
>             require a doubling of the network traffic and points of
>             failure by forcing the originating component to get a reply
>             and then send another message....)
>     * If we send destination information with events, should the
>       consumer declare what kinds of destination information it expects
>       to receive?
>     * If we send destination information with events, do we actually
>       need to include in the assembly model "producers" which are
>       "routed-by-impl"? Or is sending an event to a received destination
>       entirely a component implementation problem - one that does not
>       expose any "producer" at the edge of a component?
>     * If we send destination information, is there some way for a
>       component to pass through said destination information to outgoing
>       messages, so that it can delegate possible usage of those
>       destinations to some other component in the system?
>
>
> In any case, I mention the above in case anyone has an interest in
> capturing or restating this issue. I don't wish to consume the TC's time
> by re-raising a slightly restated issues, or subsets of the issue,
> unless we're clearly going to make progress. I'm happy to continue
> discussing this issue privately with anyone else, on the off chance that
> we can address the use-cases that I've pointed out (and that I've not
> seen recast in a different way), hopefully in a way that makes more
> sense to more people!
>
> Particularly if you voted "no", but seem some relevance to any part of
> the above, please don't hesitate to drop me an email.
>
> -Eric.
>
>>
>> -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
>>
>> ---------------------------------------------------------------------
>> 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