sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-assembly] NEW ISSUE: Need some notion of "callback" address inconjunction with eventing
- From: Peter Niblett <peter_niblett@uk.ibm.com>
- To: Danny van der Rijn <dannyv@tibco.com>
- Date: Tue, 9 Nov 2010 15:23:17 +0000
Danny
I wasn't trying to say anything profound.
It was just that when the JMS spec was being written - all those years
ago now - my recollection is that we started with the request/reply mechanisms
in the point/point domain (i.e. replyTo, temporary queues and the Queue
Requestor) and then for symmetry added their analogues to the pub/sub
domain. However that might just be my perception coming from a point/point
background.
My main point though, is that when describing
the difference between events and messaging, I think it is helpful to say
that an event relates to something that has happened in the past, and therefore
it isn't something that you reply to. I agree (as in the other thread with
Eric) that there might be other events that occur as a (partial) consequence
of the original event, or that are related to it in some other way (e.g.
two symptoms of a common underlying occurrence) but they aren't really
replies to it.
Regards
Peter Niblett
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology
+44 1962 815055
+44 7825 657662 (mobile)
From:
Danny van der Rijn
<dannyv@tibco.com>
To:
Peter Niblett/UK/IBM@IBMGB
Cc:
Eric Johnson <eric@tibco.com>,
Anish Karmarkar <ANISH.KARMARKAR@oracle.com>, ashok.malhotra@oracle.com,
Martin Chapman <MARTIN.CHAPMAN@oracle.com>, sca-assembly@lists.oasis-open.org
Date:
02/11/2010 16:40
Subject:
Re: [sca-assembly]
NEW ISSUE: Need some notion of "callback" address in conjunction
with eventing
I have to apologize to Eric for somewhat hijacking his
issue. We should probably focus on what Peter describes as aspect
1) and leave aspect 2) to (possibly) a different issue. Although
it may be useful to deal with the 2nd issue first, if people want it separate.
I think I heard Anish mention today that we already have that capability,
which surprises me.
But back to the first aspect. Peter, your statement that "the
purpose of their replyTo is to allow you to do request/reply message exchange
patterns" is IMO a bit deconstructionist. Can
you point to specs in the statements that say as much? While there
are certainly use cases where these mechanisms are used point-to-point,
there are others where they are not.
Danny
On 11/2/2010 5:19 AM, Peter Niblett wrote:
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
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]