Re: [sca-assembly] Restating issue 249

[Eric Johnson <eric@tibco.com>]

Hi Anish,

At the risk of beating a dead horse:

On 11/29/10 11:55 PM, Anish Karmarkar wrote:
> On 11/23/2010 11:00 AM, Eric Johnson wrote:
[snip]
>> 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.

Well, no.  "callback" is just one possible use for a generic 
destination.  And I think that's a problem only if you actually intend 
to model the interaction pattern, which I've tried to avoid.

>
>>> 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?

This is just a question of terminology overload.  I can't think of a 
good term without baggage.  Channel is narrow in the sense that we each 
have independent views of what channel means in the context of SCA, and 
I wanted to step away from that, at least for a moment, in trying to 
discuss the use-cases.

>
>> 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".

Your cryptic reference to "at least in one kind of implementation" 
confuses me, because we've not actually talked about how producers 
manifest in any implementation.  In all the ways I can think about 
surfacing them, the business logic only sees a producer object, it 
doesn't see that events sent to that producer will be augmented with 
metadata that includes destination information associated at the 
composite level.

Your example about deployment utterly confuses me, so I'm sure we're 
thinking about this differently.

>
>>> 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 ...>*

That would be an alternate solution to the same question.  I 
specifically put in "destinationLabel", rather than altering the name of 
the element itself.

>
>
>>> 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.

Cool.

-Eric.