Re: [sca-assembly] NEW ISSUE: Need some notion of "callback" address inconjunction with eventing

[Peter Niblett <peter_niblett@uk.ibm.com>]

Eric

I won't claim to know about Rendezvous,
but the first three that you mention (JMS, WS-Addressing and AMQP) aren't
really "broadcasting" systems. They all support point-point messaging
semantics, and the purpose of their replyTo is to allow you to do request/reply
message exchange patterns, primarily over this point-point messaging mechanism.
This can either be the simple MEPs defined in WSDL 1.1,  or the more
complex ones like the ones that you list.   They have the characteristic
that a service requestor has sent a request to one (or in some cases multiple)
service providers and then expects to get one (or more) responses back.
These responses can either be simple acknowledgements that the request
has been executed, or - if it was a query style request - they contain
the requested data.

The "decoupled" nature of
events that Ashok refers to means that the Producer of the event has no
knowledge of what the Consumers are going to do with it (or even whether
there are any consumers), So the concept of a Reply to an event doesn't
make sense.  This was part of the difference between events and services
that made us introduce Producers/Consumers/Channels rather than simply
extend the one-way service interaction mechanisms that are there in SCA
1.1. You can see a list of these difference at lines178-196 of the 1.2.

I think there are two aspects to your
use cases

1. Richer Message Exchange patterns
for request / reply service interactions
2. More dynamic routing mechanisms including
the ability of a oneway message sender to choose at runtime where to send
a message.

By the way, I think the source port
in UDP is what is says it is, and indication of where the message came
from, not where the reply is to go to. I would agree that that is a piece
of metadata that is of use to some Eventing applications, since in some
cases what a Consumer does with an event may depend on what Producer it
came from.

Regards

Peter Niblett
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology
+44 1962 815055
+44 7825 657662 (mobile)




From:      
 Eric Johnson <eric@tibco.com>
To:      
 ashok.malhotra@oracle.com
Cc:      
 Martin Chapman <MARTIN.CHAPMAN@oracle.com>,
Anish Karmarkar <ANISH.KARMARKAR@oracle.com>, sca-assembly@lists.oasis-open.org
Date:      
 01/11/2010 21:34
Subject:    
   Re: [sca-assembly]
NEW ISSUE: Need some notion of "callback" address in conjunction
with eventing

---

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