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 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:
4CEB7423.6030402@oracle.com" type="cite">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.
4CEB7423.6030402@oracle.com" type="cite">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.
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".
4CEB7423.6030402@oracle.com" type="cite">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) "
4CEB7423.6030402@oracle.com" type="cite">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.
4CEB7423.6030402@oracle.com" type="cite">
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.
- Ancillary question - what kinds of destinations are you
allowed to send? Channels, clearly, but what about consumers
or services?
- 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.
4CEB7423.6030402@oracle.com" type="cite">
-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
|