Re: [ASSEMBLY-249]: Need some notion of "callback" address in conjunctionwith eventing

[Mike Edwards <mike_edwards@uk.ibm.com>]

Folks,

This message from Eric starts to get
into one of the things that Danny raised on he call earlier this week,
namely the
inability of SCA to model the various
messaging patterns describable in WSDL.

I DISAGREE that this is the case, and
I will describe how SCA can deal with these cases.

> * message out, maybe message back
> * message out, N messages back
> * message out *, message back

Currently, SCA can do ALL of these using references
& services, using Callbacks.

Where a service has both an interface AND a callback
interface, then it is saying:

- for any forward invocation of the service
-- there may be 0, 1 or many invocations of any one
of the operations in the callback
   interface (which can also be read as
"response messages")
- the invocation of an operation on the callback interface
can occur in response to one forward invocation
-- or to some sequence of multiple forward invocations

> * message out, message back to different component

- this is supported through an override of the callback
binding HOWEVER this is then rightly an aspect
of the configuration of the ASSEMBLY and not the result
of some individual implementation artifact
deciding on the wiring - ie there is no way that the
"client" component should itself be dictating
the target for the response - that MUST be part of
the composition/assembly.


Now, I think the real debate here is whether "replyTo"
has **ANY** place in the style of Event Processing
that the SCA spec tries to describe.

The real question that Eric & Danny need to address
is how an SCA event producer can make **any** assumption
that the receiving component actually produces any
kind of response message.  A subsidiary question is whether
the event producer can also make some assumption that
the receiving component will **only** send some message
back to the event producer and nowhere else.

I think that our current model of event processing
is simply more loosely coupled than this.  If an event
producer anticipates that some new events may be generated
as a result of some events that it produces, then
I would say that the component with the producer should
also have a consumer for that type (or types) of event.

It is then up to the assembler to decide to connect
both the producer and the consumer separately to appropriate
channels - similarly for any "receiving"
component's consumer & producer.

Any "correlation" needed between an initial
event and some future "response" event should be managed through
some aspect of the response event (eg a "relatesTo"
field).


My other reaction to this material is to say "if
you want a response, use services/references, not event processing"


As to the question of why the various protocols listed
below have "replyTo" - I say it is because those protocols have
to be able to deal with request/response message patterns
of the type listed above - the current SCA event processing
model AIN'T REQUEST/RESPONSE.  It is *much* more
loose coupled than that...




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:  mike_edwards@uk.ibm.com

Eric Johnson <eric@tibco.com> wrote on 01/11/2010
20:57:15:

> [image removed] 
> 
> Re: [sca-assembly] NEW ISSUE: Need some notion of "callback"
address
> in conjunction with eventing
> 
> Eric Johnson 
> 
> to:
> 
> ashok.malhotra
> 
> 01/11/2010 21:38
> 
> Cc:
> 
> Martin Chapman, Anish Karmarkar, sca-assembly
> 
> Hi Ashok,
> 
> Just about every "broadcasting" eventing system that I can
think of 
> supports some notion of "reply-to"
> 
> JMS: JMSReplyTo
> SOAP WS: WS-Addressing ReplyTo (I admit this is a little bit of a
stretch)
> AMQP: reply-to (I think - I'm not very familiar with this)
> UDP: source port number
> PGM: (piggy-backing on UDP, it looks like)
> TIBCO's Rendevous: (yes - don't know the details)
> Email: "Reply-To"
> 
> ... : ??? (anyone know anything about Apple's Bonjour?)
> 
> Perhaps we could come up with a more complete list of this "broadcast"
> mechanisms, and what they support?
> 
> In any case, the notion of using services and references doesn't even
> come close to mapping on to various cases that you might relate to
> eventing.  Services and references are tightly tied to the 
> interoperability and known semantics of WSDL 1.1, whereas eventing
might 
> use a whole bunch of messaging patterns that you might not even be
able 
> to define in WSDL:
> 
> * message out, maybe message back
> * message out, N messages back
> * message out *, message back
> * message out, message back to different component
> 
> All of these might take advantage of a "reply to" capability
that has 
> little or nothing to do with the request/reply semantics associated
with 
> services and references.  Also, the message back might effectively
be 
> "any" - there might not be a specific "response"
message with a single 
> specific type.
> 
> This question does bring me back to one question that I've been raising
> for a while.  What bindings do we anticipate people using with
SCA 
> Eventing, and how do we think they're going to be used?  Absent
that 
> information, it strikes me as very difficult to address questions
like 
> this one.
> 
> As to whether we open this issue, since all the existing transports
I 
> mentioned above support the functionality, I think closing it with
no 
> action would be premature. Yet, I agree that we may need much discussion
> to establish what this "reply to" notion means, and maybe
we won't get 
> there.
> 
> -Eric.
> 
> On 11/1/10 10:20 AM, ashok malhotra wrote:
> >
> >  Maybe I'm missing something.  Events are all about
loosely connected 
> > entities,
> > If you want to use 'replyTo' why not use Services/References?
> > All the best, Ashok
> >
> > On 11/1/2010 8:53 AM, Martin Chapman wrote:
> >> I'm not arguing that it's not a good use case or trying to
belittle 
> >> JMS;-)
> >> I think the point is I don't see what an assembler can do
if a 
> >> component has one of these "reply-to" producers.
It cannot connect it 
> >> to any channel, and I can't think of anything else that the
assembler 
> >> might want to do.
> >>
> >> Martin.
> >>
> >>> -----Original Message-----
> >>> From: Eric Johnson [mailto:eric@tibco.com]
> >>> Sent: 29 October 2010 20:29
> >>> To: Martin Chapman
> >>> Cc: Anish Karmarkar; sca-assembly@lists.oasis-open.org
> >>> Subject: Re: [sca-assembly] NEW ISSUE: Need some notion
of "callback"
> >>> address in conjunction with eventing
> >>>
> >>> Hi Martin,
> >>>
> >>> On 10/29/10 7:02 AM, Martin Chapman wrote:
> >>>> Doesn't seem like something that needs addressing
at  the SCA 
> >>>> level. If
> >>> any producer can include a "reply-to" then
all consumer components 
> >>> need to
> >>> be prepared to do something with it i.e. it's implicit
that there 
> >>> may be
> >>> production of "response" events.
> >>>
> >>> My trite response is that if you simply disregard this
case, then 
> >>> anyone
> >>> who wants to do anything with JMS that naturally maps
onto the use of
> >>> the JMSReplyTo message header, either cannot do it with
SCA 
> >>> eventing, or
> >>> can only do it with vendor specific extensions.  Both
possibilities 
> >>> seem
> >>> wrong to me.  JMS has been around a lot longer than
SCA eventing, 
> >>> and if
> >>> we cannot model appropriately around one of its key features.....
> >>>
> >>> For a more substantive response, I can refer back to
the responses I
> >>> sent Mike - there are a number of what I think are reasonable
scenarios
> >>> where trying to wire this in the current model doesn't
work.
> >>>
> >>> Your point does make me wonder whether a consumer might
flag that as
> >>> part of an eventFilter that it may disallow reply-to
information, or
> >>> perhaps simply ignore it.
> >>>
> >>> I raised the issue because I think we've overlooked something
> >>> important,
> >>> however, I admit to not having all the answers, or having
thought
> >>> through all the implications.
> >>>
> >>> -Eric.
> >>>
> >>>> Martin.
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Eric Johnson [mailto:eric@tibco.com]
> >>>>> Sent: 29 October 2010 00:52
> >>>>> To: Anish Karmarkar
> >>>>> Cc: sca-assembly@lists.oasis-open.org
> >>>>> Subject: Re: [sca-assembly] NEW ISSUE: Need some
notion of "callback"
> >>>>> address in conjunction with eventing
> >>>>>
> >>>>> Hi Anish,
> >>>>>
> >>>>> On 10/28/10 4:41 PM, Anish Karmarkar wrote:
> >>>>>> I think this could be done by using event
message metadata (some 
> >>>>>> kind
> >>>>>> of reply-to header). I don't think there
is anything in the current
> >>>>>> model that prevents this (although there
is no effort to standardize
> >>>>>> event metadata). Are you suggesting standardization
of metadata with
> >>>>>> this issue?
> >>>>>> On the part about consumer tied to an unwired
producer, the consumer
> >>>>>> is allowed to react to an event (or not)
in any way it deems
> >>>>>> appropriate (application logic) including
invoking a one-way 
> >>>>>> operation
> >>>>>> on a service offered by the same component
that produced the 
> >>>>>> original
> >>>>>> event, OR raising its own event (the original
event may have enough
> >>>>>> information about the channel binding and
how to get to it). Why 
> >>>>>> do we
> >>>>>> need this tie-up? I can see this would be
interesting if there was
> >>>>>> some use of policy/binding injection on the
responding producer.
> >>>>> Sounds like you might be thinking about this
one differently than 
> >>>>> I.  My
> >>>>> notion is that if a consumer receives a message
with some sort of
> >>>>> "reply-to" address on it, then how
do we model that in SCA?  And how
> >>>>> does that carry down into the implementation
type?  Is this a 
> >>>>> notion of
> >>>>> an "unbound" producer that get the
information associated with the
> >>>>> message delivered to the consumer, or is it a
special "producer" 
> >>>>> object
> >>>>> that arrives with the message on the consumer
side?  I was 
> >>>>> thinking we'd
> >>>>> model this as an actual "producer"
on the component, but that 
> >>>>> somehow we
> >>>>> have to flag that the producer is used specifically
for sending to 
> >>>>> the
> >>>>> "reply-to" address received when a
message is consumed.
> >>>>>
> >>>>> I'm not sure of the best way to make this work,
I just raised the 
> >>>>> issue
> >>>>> because I noticed we couldn't really address
it with the current 
> >>>>> draft.
> >>>>>
> >>>>> -Eric.
> >>>>>
> >>>>>> We have disallowed bindings on producer/consumers
and wrt policy 
> >>>>>> -- I
> >>>>>> know we haven't really decided on policy
matching -- but this could
> >>>>>> complicate, the already complicated, eventing
policy issue further.
> >>>>>>
> >>>>>> -Anish
> >>>>>> -- 
> >>>>>>
> >>>>>> On 10/28/2010 4:11 PM, Eric Johnson wrote:
> >>>>>>> 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.
> >>>>>>>
> >>>>>>> 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.
> >>>>>>>
> >>>>>>> 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.
> >>>>>>>
> >>>>>>> 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.
> >>>>>>>
> >>>>>>> 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.
> >>>>>>>
> >>>>>>> ---------------------------------------------------------------------
> >>>>>>>
> >>>>>>> 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
> >>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> 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
> >>>
> >> ---------------------------------------------------------------------
> >> 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
>

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU