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:
OF96678465.356354E5-ON802577CF.003267F6-802577CF.0043B941@uk.ibm.com"
type="cite">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
|