← Prev in month
← Prev in thread
Next in thread →
Next in month →
Re: [sca-assembly] [ASSEMBLY-249] Need some notion of "callback"address in conjunction with eventing
Hi Mike,
More good questions!
On 10/29/10 2:41 AM, Mike Edwards wrote:
Folks,
Some questions inline for
clarification
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great
Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email:
Eric Johnson <> wrote on
29/10/2010
00:11:47:
> [sca-assembly] NEW ISSUE: Need some notion of "callback"
address in
> conjunction with eventing
>
> Eric Johnson
>
> to:
>
> OASIS SCA Assembly
>
> 29/10/2010 00:16
>
> Title: Need some notion of "callback" address in
conjunction
with eventing
>
> Target: Assembly 1.2 WD 01
>
> Description:
> For some uses of eventing, the point of using an event
driven system
is
> to decouple a collection of asynchronous interactions.
>
> For example component A sends a message to component B,
and A directs
B
> to send a response to component C.
First question here is why this type of
behaviour
is not simply achieved in
SCA by using the composition itself? That is,
I can create a composition
of components A, B, C where a producer of A
sends
messages to a consumer
of B and a producer of B sends messages to a
consumer
of C.
Possibility #1 - we adopt something like the "autowire" notion I
filed. Explicit wiring would be counterproductive, if not
impossible.
Possibility #2 - Components A, B, and C produce messages to send to
D, in some situations D may send feedback information back to a
reply-to address. Since there are multiple components "producing"
messages, the only way I see to simulate this in the current model
would be to establish three different consumers on D, one for each
of A, B, and C. Of course, now we've actually coupled the shape of
the solution, when a pub-sub environment should let me decouple
them.
Possibility #3 - Components A, B, and C produce messages to send to
all of D, E, and F. If D, E, and F might choose to send back any
sort of response to the "producing" components, we're back to a
combinatorial wiring explosion, rather than simply modeling
something like a JMS Topic as the binding for the channel.
Second question relates to the nature of the
contract
here. How does
component A even know that component B will
produce
a "response" following
the receipt of some message from A? Decoupling
actually
implies this - that
component A can have no expectations of what
component
B will do when
receiving a given message. It may be known to
the assembler, but decoupling
implies that it is not known to the component
writer...
This is definitely an important question. I don't have a clear-cut
answer. My instinctual reaction suggests that this question should
be at least partially out-of-scope to SCA itself. Modeling
semantics around complex interactions is beyond what SCA needs to
do. But we probably have to capture some simple ones.
One answer is actually quite simple. The contract is partially
implied by the message payload, and the presence of a "reply-to"
address on the consumed message. If the producer of the message
doesn't send a "reply-to", that's OK, but if they do, then there's
probably semantics related to the payload that deserves some kind of
"response."
Another possible answer relates to a point that I think TIBCO
(mostly me, really) have been remiss in following-up on. There
doesn't seem to be a particular reason why you couldn't actually use
a WSDL like contract to describe some of these interactions - it is
just that the communication is done via events, rather than via HTTP
request/reply.
I get the feeling here that you're really
trying to
describe a service
style interaction based on asynchronous one-way
messages.
No problem with
that, but why not use services & references
for
that?
#1) Nature of implied a-synchronicity
#2) "Reply" messages could be zero to many, as in: order-received,
order-processed, order-packaged, order-shipped, order-in-transit,
order-appears-to-have-arrived. Further, it is possible that the
"reply-to" destination is not a queue, but a topic, in JMS terms.
>
> JMS, for example, includes the JMSReplyTo property. This
allows
for
> asynchronous communications, and allows for the sender to
dictate
where
> the response should go, eliminating any direct
architectural coupling
of
> the receiver with the sender.
Why should the sending component be the one to
make
these decisions rather
than the assembler who is composing some set of
components
into a coherent
application?
I think we're actually saying the same thing here, but I apparently
expressed it poorly. The declaration of the component in the
composite, and the producer identified therein strikes me as the
likely place to identify the "reply-to" consumer destination. I
think that's the file that the "assembler" you refer to
creates/edits. So I conclude (correctly?) that we agree.
>
> For the purposes of eventing in SCA, it is desirable on
the "producer"
> side to send a message with a "reply" address pointing to
some other
> consumer (or channel) on the component, or in the
composite.
>
> Likewise, on the consumer side, it may be useful to tie
that consumer
to
> an "unwired" producer, where that producer never gets
wired
to anything
> but rather sends to the destination received by the
consumer.
I simply don't understand the last sentence
"sends
to the destination
received by the consumer" - can you explain
further
please?
I also note in the description here that there
seems
to be an assumption
of direct connections from consumers to
producers
- or have I misunderstood?
The current model is essentially a pub/sub
mediated
kind of model, where the
channels act as multiplexers connecting a group
of
producers to some group
of consumers - there is no implication of a
1-to-1
connection.
I'm not against 1-to-1 connections, but it is
necessary
to make them part of
the model first.
I have not been assuming that there's any sort of one-to-one
relationship.
What we may be missing is some sort of notion of whether an event is
sent to a Topic or to a Queue. There's not necessarily a single
consumer, but there may be a single responder....
What you may be pointing out is that I lifted up a rock, and there
are a bunch of bugs crawling around underneath. Hmmm.
>
> Abstract proposal:
>
> In the case of a producer expecting a "reply", change the
"producer" on
> a component so that it includes something like a
"@replyTo"
attribute.
This seems to make big assumptions about how
the target
component will
behave - the target may have 0 producers, 1
producer,
multiple producers
and may produce 0, 1, or many events in
response to
a given message.
What should happen in the case of 0 events or
of multiple
events being
produced by the receiving component?
More sophisticated components may produce
events only
in response to
multiple events that may arrive from different
producers.
How should
such events be treated?
Perhaps these are different questions, or perhaps they are different
parts of the same one. Maybe one of those many components
delivering messages to a channel might include a "reply-to" address,
and that "reply-to" might not be back to itself?
-Eric.
>
> In the case of a producer sending a "reply", change the
producer to have
> a "inReplyTo" attribute that names a particular consumer
on the same
> component (@target attribute & @replyTo attribute not
allowed)
>
> -Eric.
>
← Prev in month
← Prev in thread
Next in thread →
Next in month →