Hi Mike,
On 11/16/10 2:22 AM, Mike Edwards wrote:
OF003F5F3E.AE475A0F-ON802577DD.00377FBF-802577DD.00388D29@uk.ibm.com"
type="cite">
Eric,
This is something that I really
don't
understand:
>
> I
like the
notion of context, but I'm not looking to standardize a generic
notion
of context.
> Rather I'm looking to standardize a notion of
a particular
type of data that can be carried in context - specifically as it
relates
to how components are wired.
>
If you want to standardize some
particular
data that can be carried in "context", then I don't see how you
can avoid standardizing the notion of "context" itself, since
to refer
to the particular data, you have
to
be able to refer to it (for example, in configuration of a
component producer
/ consumer) and that necessarily implies describing it as
part of the context.
Maybe this is splitting hairs, but let me see if I can carry through
a concrete example.
Using the pattern from [1] that I proposed, on producer A, a
composite might specify, for a component:
<sendDestination label="replyTo" @channel="SomeLocalChannelName"
/>
The receiving component (of type implementation.java)
<consumer ... receiveDestinations="replyTo" ... >
<producer ... wiredByImp="true" ... > (Note that I changed
this from what I proposed before, because the naming is tricky, and
looking at the Java implementation code, "wired by implementation"
more accurately describes what's happening).
And the implementation of the Java code (which we've not dug into so
far, so I'm completely making this up):
class MyComponent ... {
@Producer
public Producer m_foo;
// here, I'm explicitly passing a context parameter, but this
equally well could be stored in a thread local
// variable, and the "DestinationMarkerInterface could be retrieved
via a call to a static method.
void consumeEvent(EventContext evtCtx, Event evt) {
DestinationMarkerInterface sendRepliesHere =
evtCtx.getSentDestination("replyTo");
// not sure how the event would be constructed...
SomeEventObject eventObj = ... ;
// and here, when sending the event, I'm using the destination
from the event being consumed.
m_foo.sendEvent(sendRepliesHere, eventObj);
SomeOtherEvent otherEvent = ...;
// and again sending to the destination from the consumed event.
m_foo.sendEvent(sendRepliesHere, otherEvent);
}
From the SCA Assembly perspective, yes there's metadata being sent
with the message, but that's already true, for all bindings. All
I'm asking the assembly model to do is tell the binding to carry
binding-specific destinations, in a binding-specific way, as part of
the metadata of the underlying message. In this case, the only
thing that's happening above is that the JMSReplyTo message header
will be sent with the event, set to the channel where a "replyTo"
should be sent. And further that the APIs exist to extract that
destination so that the implementation can use it.
This is *not* a generic context, wherein the assembler can indicate
any type of data to be carried for any particular purpose. This is
specifically, and *only* binding destination data that I'm talking
about. A generic "context" notion implies, as you note, the ability
to get and set a variety of data.
I also note that I only had to explicitly introduce the notion of
"context" in the Java implementation as a means to show what's going
on. If it was all done on the same thread, I could have done:
SomeOtherEvent otherEvent = ...
m_foo.sendEvent("replyTo", otherEvent);
... where I'm assuming (a) a mysterious thread-local, and (b) that
we're not switching threads, and then it is safe to collapse the
lookup of the destination carried with the received event with the
sending of the new event. In that case, there's no context visible.
In a BPEL implementation, (I don't even know what that would look
like), I assume that the underlying BPEL implementation could take
care of managing all the context information, so there would *not*
be any context object to refer to...
So while I agree that the generic notion of context is somehow in
play here, I'm specifically not asking for it in this case,
but rather wanting to carry destination information. Whether, for a
particular implementation type, that maps to a specific notion of a
"context" object in which you can look up lots of interesting
things, seems orthogonal to the issue.
OF003F5F3E.AE475A0F-ON802577DD.00377FBF-802577DD.00388D29@uk.ibm.com"
type="cite">
For me, I am happy to see the
spec describe:
a) the existence of event
metadata
b) have a free format of the
content
of the metadata
c) describe some specific fields
in
the metadata
d) provide mechanisms by which
producers
can set metadata and by which consumers can read metadata
e) allow for (assembly)
configuration
of both producers and consumers that uses metadata fields [1]
That is but one possible approach to resolving the issue, although I
think it makes it somewhat more difficult to accomplish the
equivalent of what
<sendDestination label="replyTo" @channel="SomeLocalChannelName"
/> accomplishes. Why? Because now I need to define a specific
type of thing that is a "DestinationType", and those DestinationType
values *must* be references to either consumers or channels within
the assembly.
From an implementation point of view, it still ends up being a
privileged type, at least if you want type-safety in Java, because I
still need a method like:
DestinationMarkerInterface sendRepliesHere =
ctx.getDestination("replyTo")
in addition to the other "get" methods I might have, like:
int getIntValue(QName)
String getStringValue(QName)
However, I don't really want to entertain this discussion too much,
because I've not heard discussion of any use cases for generic
context metadata that need to be model at the assembly level, where
you cannot simply roll that same data into the event in question.
OF003F5F3E.AE475A0F-ON802577DD.00377FBF-802577DD.00388D29@uk.ibm.com"
type="cite">
One problem I forsee is the
"communication
mechanism" by which a component can describe the metadata
it is making available for events
on
a given consumer (eg. "this producer produces events which have
the
following metadata attached, and
which
you the assembler can use to make composition decisions")
Right, that would be a problem, if I were asking for generic context
data. But I'm not.
OF003F5F3E.AE475A0F-ON802577DD.00377FBF-802577DD.00388D29@uk.ibm.com"
type="cite">
I also note that I think it is
the job
of component code to decide to read metadata from events it
consumes and
to attach metadata to events it
produces
- I don't think that this happens in any "automatic" way. This
addresses
the problem I expressed in a
previous
email - "how do I know that event X produced by this component
is
related
in any way to some previous event
A
consumed by this component?" - ie my answer is "you know
if the component
implementation tells you so..."
Hmmm. This strikes me as wanting to have it both ways. Either the
system is loosely coupled, and the implementation does what it wants
with the "replyTo" information I sent it, or it isn't, in which case
I know exactly what it is doing, and it isn't loosely coupled any
more. More concretely, the component I sent the message to could
take the destination I sent it, and put that destination on the
outgoing message (aha, an additional API, sendEvent(foo,
destinationMap)...), and let some other component figure out whether
or not to use the original reply destination as something to send
events to. When loosely coupled, I don't care if the component that
receives the event delegates to fifteen other components, or does
the work by itself. So your comment above sounds slightly closed -
you don't want tight coupling, so that's a problem, but the
unknowable loose-coupling is problematic too.
I'll reassert what I've said before - the ability of the *assembler*
to indicate destinations for follow-on messages from a specific
producer leads to a more loosely coupled system, as component
implementations no longer to be aware of certain wiring decisions.
-Eric.
[1]
http://lists.oasis-open.org/archives/sca-assembly/201011/msg00055.html
OF003F5F3E.AE475A0F-ON802577DD.00377FBF-802577DD.00388D29@uk.ibm.com"
type="cite">
[1]
Configuration using metadata
fields
could include consumer filters (we already have these) and also
producer "filters" (eg only
send an event to this channel if metadata X has a particular
value or is
within
some range of values)
OF003F5F3E.AE475A0F-ON802577DD.00377FBF-802577DD.00388D29@uk.ibm.com"
type="cite">
Yours, Mike
|
|
Dr
Mike Edwards
|
Mail Point
146, Hursley
Park
|
|
Technical
Strategist
|
Winchester,
Hants SO21
2JN
|
SCA
& Services
Standards
|
United
Kingdom
|
Co-Chair
OASIS SCA
Assembly TC
|
|
|
IBM
Software Group
|
|
|
Phone:
|
+44-1962
818014
|
|
|
Mobile:
|
+44-7802-467431
(274097)
|
|
|
e-mail:
|
mike_edwards@uk.ibm.com
|
|
|
|
|
From:
|
Eric Johnson
<eric@tibco.com>
|
To:
|
Peter
Niblett/UK/IBM@IBMGB
|
Cc:
|
OASIS Assembly
<sca-assembly@lists.oasis-open.org>
|
Date:
|
15/11/2010 21:43
|
Subject:
|
Re: [sca-assembly] Re:
[ASSEMBLY-249]:
Need some notion of "callback" address in conjunction
with eventing |
Hi Peter,
Referring to both my last email [1], and the one describing
multiple producers,
one consumer, and multiple destinations for results - for a
stock-trade
scenario [2], I think I have more feedback on this.
See below.
[1] http://lists.oasis-open.org/archives/sca-assembly/201011/msg00055.html
[2] http://lists.oasis-open.org/archives/sca-assembly/201011/msg00047.html
On 11/9/10 7:11 AM, Peter Niblett wrote:
Eric
I read through the dialog that you helpfully extracted below.
I got the point that you aren't necessarily talking about
replies, and
that what you want is to be able to set up some kind of routing
scheme
so that, in your example, when component B emits an event that
was in some
way related to an incoming event, the channel that is used to
forward the
outgoing event (channel Y or channel Z) depends on the source of
the incoming
event.
I thought at first that you wanted to have some kind of dynamic
assembly,
where the producer on component B is not wired explicitly to
anything,
but instead the component has the ability to determine the
destination
for that producer programmatically at runtime - a bit like JMS's
unidentified
MessageProducer, which has a send(destination, message) method.
This seems like the eventing equivalent of
"wiredByImpl".
I haven't raised an issue about that.... Yet. ;-)
Maybe someone else will beat me to it.
However you also say that you want the target(s) of B's producer
to be
determined by the assembler - " I fully
expect that the assembler decides the response destination, and
that may
be whatever the assembler chooses, and it might be the original
component,
or it might not. Notably, it might be to another channel."
So that means you don't want either the component that created
the original
message (A or D) or component B itself to determine the target
of the second
message. I would claim that you can do that with the current
model, provided
that the incoming event contains some "metadata" (i.e. header
data) that indicates the id of the originating component. We
could then
have two producers on B, which the assembler wires to Y and Z -
and the
logic inside B looks at the metadata in the incoming event and
decides
which of these two producers to send it out on. Alternatively,
similar
to what Mike suggested, you could have component B copy across
the originating
id metadata into the output message and have a single producer
wired to
both Y and Z with filters on Y and Z that look at this metadata.
Yes, thinking about this as metadata is quite useful. I note
that
JMS singles out a specific kind of metadata called "JMSReplyTo",
which is of course really just a convenient way of carrying a
"Destination"
object with the message.
What I think makes this metadata different is that it is
"destination"
metadata that carries binding specific details for how to get to
a particular
destination. So it isn't just any generic kind of metadata, it
is
specifically destination metadata that can be handed directly to
the binding
for the producer, and it can directly deliver it. It *isn't*
that
component B that you identify above looks at metadata on the
incoming message,
and decides which of N producers to send to, it is that the
incoming metadata
is just a single piece of data that it needs to pass along to
the producer
invocation.
In other words, B doesn't do the deciding about which
destination to send
to, rather it picks and choose (a) whether to use the
"destination"
information from the consumed event at all, and if it does it
simply passes
that along.
That scales better, because I won't have to change component B
just because
I introduced a new producer into the system.
As Mike says - this implies some coupling inside B of the
incoming
to the outgoing event. This is true for some kinds of component
- in particular
in the event processing world we have specialist component whose
job is
to perform some operation on the events that it receives and
then forward
on one or more output events (they may be the same as the
original or they
may be computed from them in some way). We call them "Event
Processing
Agents". However in general., SCA doesn't say anything about
how the events produced by a component related to events that it
consumes.
It is possible for them to be completely unrelated - e.g. a
component that
logs events that it receives on its consumer and at the same
time produces
timer tick events on its producer - though I would agree that
this would
be a strange design.
In practice the amount of wiring you would need to scale this
sort of thing
up can get out of hand, so in events and messaging we usually
employ a
notion we call Context. Each event/message has a set of context
properties
associated with it. These can be explicit attributes of the
event,
such as a customer id, or implicit ones (such as a security or
transaction
context). These contexts are then used to filter or route a
message (or
to determine exactly how a component processes it). .Setting the
value
of explicit context parameters is obviously the job of the
component's
logic. In the case of implicit context properties, it is
possible
for them to be set by the component implementation container
without the
application logic having to be involved - but that of course
depends on
the implementation type.
I like the notion of context, but I'm not looking to standardize
a generic
notion of context. Rather I'm looking to standardize a notion
of
a particular type of data that can be carried in context -
specifically
as it relates to how components are wired.
So I am wondering now whether this whole issue isn't really
saying that
we need to specify more metadata attributes in the event model,
which can
be read/written by the application logic (if it so desires) and
can be
referenced by filters in the assembly model.
No, not exactly. I think it means that we have to be able to
specify
at the assembly level that we wish for the bindings to carry
"destination"
type metatdata, so that the assembler can wire, and the bindings
have to
define how they do so.
-Eric.
Regards
Peter Niblett
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology
+44 1962 815055
+44 7825 657662 (mobile)
From: Mike
Edwards/UK/IBM@IBMGB
To: OASIS
Assembly <sca-assembly@lists.oasis-open.org>
Date: 09/11/2010
10:39
Subject: Re:
[sca-assembly] Re: [ASSEMBLY-249]: Need some notion of
"callback"
address in conjunction with eventing
Eric,
Comment #2.
So it sounds now as if you want the "replyTo" concept to be
something
that an assembler expresses in the configuration of a composite.
Please correct me if I've misunderstood that.
The problem I'm having is seeing just what that configuration
would look
like. I think it is likely to be necessary to draw out a couple
of
example composites that demonstrate the "replyTo" concept in
action. Can you do that?
For me, it seems as if the existing model supports everything
that is needed
for the assembler. But clearly you don't think so.
The best I can do is speculate as to what you really want to see
- but
at the moment I am struggling to come up with a formulation
that makes sense at an assembly level.
For example, let me assume a component with one consumer and one
producer
(simplest imaginable for the implied function here).
It seems as if you want to see the possibility of configuring
the component
producer so that:
a) the producer can send events to 2 (or more) channels
- the thinking here is that each of the channels represents some
specific
target or targets
b) each producer channel connection is given something like a
"producer
filter", so that events are only sent to that channel if some
condition
is met
c) the producer filter can be expressed in terms of some
metadata about
some incoming message (let me call the metadata "receivedFrom"
for the moment)
The bits I don't really understand are:
1. How it is known that a given event produced by a component is
relatedTo
a particular event previously received by that component
- this touches on the "tight coupling" that I've harped on about
2. Whether the metadata involved in this function requires
standardization
(this links back to my previous comments that so far we did not
standardize metadata - not that we should not but rather that we
chose
not to do so until now...)
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
From:
|
Eric
Johnson <eric@tibco.com>
|
To:
|
Mike
Edwards/UK/IBM@IBMGB
|
Cc:
|
OASIS Assembly <sca-assembly@lists.oasis-open.org>
|
Date:
|
09/11/2010 02:02
|
Subject:
|
Re: [sca-assembly] Re:
[ASSEMBLY-249]:
Need some notion of "callback" address in conjunction
with eventing |
Hi Mike,
I agree, an inline response might further complicate matters, so
let me
see if I can take your points, restate them, and see what we can
discuss,
and see what I can clarify.
MJE: The one important point with references is that the client
KNOWS the
number of responders
EEJ: Agreed. The scenarios I'm trying to address do not assume
that
knowledge.
MJE: To me, the EXPECTATION of a particular response implies
service-like
behavior.
EEJ: Agreed. What I'm getting at is the expectation of the
possibility
of some kind of "response", without knowing where the
"response",
if any, is coming from, and what form that "response" will take,
or even whether, strictly speaking, you'd call it a "response."
MJE: The "ReplyTo" notion indicates the expectation of a
particular
pattern of messages, which I think is actually modelled in SCA
using services/references
with one-way messages and callbacks.
EEJ: The word Danny used was "deconstructionist." This
is but one possible way to use "ReplyTo". As I mentioned
in my email, the mistake JMS makes, which WS-Addressing doesn't
make, is
to assume one particular metadata label for this construct. In
90%
of the use-cases, that single piece of additional metadata,
however employed,
can serve a valuable role, even if, strictly speaking, it isn't
a "reply"
channel.
MJE: Well, that is an important point - it may well be the case
that the
message business payload carries some identification that can
later be
used for "relatesTo" information in subsequent events that are
generated.
EEJ: The trouble is, if you always force that back upon the
application/business
logic, then the business logic may need to make decisions about
where to
send follow-on messages. However, if you let the incoming
message
dictate transport level details about where to send follow-on
events, then
the business logic doesn't need to care.
MJE: For this feature to be of any real use, then it is an
application-to-application
communication function. In other words, when a component
produces
an event and sends it out into the world, the component itself
MUST have
the unique ID for that event (either generated by the component
itself
OR by some API involved in the produce process). Equally, when
an
event is consumed by some other component, that component must
be able
to a) know that there is a unique ID for the event and b)
obtain
that ID
EEJ: I don't agree that this is necessarily an application to
application
communication function, at least not in the way that you
describe. Component
A sends an event via some channel X, which happened to arrive at
Component
B, with the request that subsequent "related" messages get sent
to channel Y, which might end up at Component C. Likewise
Component
D sends a message to channel X, and it again happens to land at
component
B. However D requested that "related" messages get sent
to channel Z, and that happens to land at Component E.
Presumably
both Component C & E know the subject of the events that
they receive
- they do not need to know the transport details that led them
to receive
those messages. That would be extra coupling!
MJE: One thing to note about this is that it makes *NO*
assumptions about
who receives any events with "relatesTo" metadata. This
may mean that "relatesTo" may be meaningless for some consumers
of an event, but I see no harm in that.
EEJ: Agreed!
MJE: The bit I don't buy is the notion that "replyTo" seems to
indicate a direct connection of some kind back to a single
component only
(A) for the events produced by B, C, D in response to an initial
event
from A. Why can't assemblers choose to direct those events
wherever
they please?
EEJ: I think they should be able to as well. Both you and
Peter,
if I remember correctly, seem to have been confused by my random
mutterings,
thinking I want "replyTo" to come back to the particular
component,
under the control of the component. In both cases, I'd say no.
I
fully expect that the assembler decides the response
destination, and that
may be whatever the assembler chooses, and it might be the
original component,
or it might not. Notably, it might be to another channel.
MJE: Ahem, I beg to differ on the interpretation here - far from
"loose
coupling", this "replyTo" notion is an introduction of much
tighter coupling between 2 components.
EEJ: I don't see a better, easy way to address the scenario I
put above,
where component B sends follow-up events based on decisions by
the assembler,
because of where events to component B originated. I don't see
how
you can do this with current services and references. I don't
see
how you can do it with current eventing.
You might be able to get something to work by injecting
properties
into a components A & D so that it can augment the business
data to
indicate where B is supposed to send follow-on messages, but
that further
requires that B knows that it has to pay attention to additional
business
data to route messages. So at best, the assembler can suggest
an
intention only indirectly, and it relies on a proper
implementation of
B to manage message routing. All of which is unnecessary, since
all
of the possible bindings could support it.
So yes, you are introducing an unnecessary tighter coupling if
you don't
support *something* additional here.
MJE: You will need to convince me on point #4 - I don't see
"tight
coupling elsewhere", neither do I see inefficiencies.
EEJ: To be fair, one further way to solve the scenario I
outlined above
would be for components C & E to listen to a known channel.
However,
I think this now implies, (a) decisions at a business logic
level, (b)
additional messages processed by both C & E. It is simply
less
flexible.
MJE: SCA can use the wire protocol features when they are
useful, but only
as a reflection of the composition goals that are already shown
in the
SCA assemblies.
EEJ: I agree. I don't want to consider this as specific to the
JMS
notion of JMSReplyTo. I want to solve something like the
scenarios
I've outlined above. What little research I did into this
suggests
the possibility of any possible "eventing" capable transport
of carrying a notion of "subsequent destinations". Call
those whatever you wish. JMS happens to (narrowly) call this a
"reply
to". But as near as I can tell, that is the 90-99% use case.
So I think we should be able to leverage this transport
capability
in SCA, but that means providing some means to model, in the
assembly,
some way to wire something that maps to this transport level
property.
Not supporting this notion feels like composing an eventing
system with
one hand tied behind your back.
Hopefully that brings some clarity to the points.
-Eric.
On 11/8/10 2:37 AM, Mike Edwards wrote:
Eric,
I'll try one further inline response, but I'm concerned this
will get very
messy.
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 04/11/2010 23:01:27:
> [image removed]
>
> Re: [sca-assembly] Re: [ASSEMBLY-249]: Need some notion
of
> "callback" address in conjunction with eventing
>
> Eric Johnson
>
> to:
>
> Mike Edwards
>
> 04/11/2010 23:06
>
> Cc:
>
> OASIS Assembly
>
> Hi Mike,
>
> It is possible we're vehemently agreeing on many points.
Which
> should make this an interesting discussion....
>
> On 11/4/10 9:11 AM, Mike Edwards wrote:
>
> 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.
>
> I agree, to the extent that you're talking about a single
consumer
> at the destination. Concretely mapping this to JMS (or
email),
all
> I know is that I send messages to a destination, and I
don't know
if
> I get a "message" back at all, whether I get five
"messages"
back,
> or just one, and I further don't know if those "messages"
will come
> from the same source.
>
> 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
>
> Yes, all true. The way I read it, you've assumed a
single
> "responder", whereas I have not.
SCA references provide for 0..n and 1..n multiplicity which
gives as many
responders
as you wish. The one important point with references is
that the
client KNOWS the
number of responders.
>
> I perceive an important semantic distinction between
"here's
a
> message", and "invoke particular operation", even if
they're called
> with the same data. Eventing systems move data, whereas
"services"
> systems perform actions based on parameters. I think
they align
> about as much as REST does with SOAP. You can accomplish
the
same
> ends with both, but with REST you think primarily about
resources,
> representations, and state, whereas with SOAP you think
about verbs
> and parameters. You can end up in radically different
places,
with
> radically different architectural implications. In my
head at
> least, that analogous distinction extends to
messaging/eventing vs.
> web-services/SOAP.
Well, yes and no.
To me, the EXPECTATION of a particular response implies
service-like behaviour.
Event style interactions can make no assumption at all about
there being
any
kind of response to a given emitted event, even where
multiple consumers
receive the event.
The "ReplyTo" notion indicates the expectation of a
particular
pattern of
messages, which I think is actually modelled in SCA using
services/references
with one-way messages and callbacks.
I harp on about this because some while ago we discussed the
whole question
of
why we could not model all of event processing using this
technique of
one-way
messages with callbacks... and we decided that event
processing was different
in a number of significant ways.
>
>
> > * 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.
>
> I agree completely.
>
>
> 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.
>
> Looking forward in your email, you through out a notion
of
> "relatesTo". That *exactly* what I'm trying to get
at with this issue.
>
> In certain circumstances, the "relatesTo" meta-data
exists
as part
> of the application-defined payload of a message, and
that's probably
> unavoidable. I don't want to aim to boil the ocean, as
it were.
Well, that is an important point - it may well be the case
that the message
business payload carries some identification that can later
be used for
"relatesTo" information in subsequent events that are
generated.
>
> I'd like however, if the binding can handle the
"relatesTo"
notion
> whenever it makes sense. That raises exactly the
question I'm
> trying to get at - how does the binding even *know* that
it is
> supposed to manufacture a unique identifier so that a
subsequently
> delivered message can be correlated via some notion of
"relatesTo"?
> When that subsequent message does arrive, how does the
binding layer
> even know to associate it with whatever state it might
have stored
> earlier? How did the first, second, or third consumer
know where
to
> send the "relatesTo" information?
Well, this is *not* a bindings question, first &
foremost. For
this feature
to be of any real use, then it is an
application-to-application communication
function. In other words, when a component produces an
event and
sends it
out into the world, the component itself MUST have the
unique ID for that
event (either generated by the component itself OR by some
API involved
in the produce process). Equally, when an event is consumed
by some
other
component, that component must be able to a) know that there
is a unique
ID
for the event and b) obtain that ID
There would then need to be a further step for the receiving
component
so that
when it produces some other event(s), that it can "label"
one
or more of those
events with a piece of "relatesTo" metadata, which can be
retrieved
by whichever
components receive that event.
One thing to note about this is that it makes *NO*
assumptions about who
receives any events with "relatesTo" metadata. This may
mean that "relatesTo"
may be meaningless for some consumers of an event, but I see
no harm in
that.
>
> How can the consuming binding of a message receive the
necessary
> information from the incoming message and stash it, such
that when
> the consumer then produces a message that relates to the
originally
> received message, it will work? The code calling the
producer
must
> either get at the "relatesTo" information, or tell the
producer
it's
> invoking to look up that previously saved state....
Now, I've used the dreaded word - "METADATA" - and I've used
it deliberately.
These pieces of information - eventID and relatesTo - I
regard as metadata.
We've made provision for there to be metadata related to
events, but so
far
we have not taken the step to standardize any metadata.
Do the functions outlined here represent metadata that we
should seek to
standardize? (And for the client APIs in language X, some
functions to
manipulate said metadata???)
>
> 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 don't think I've made either assumption. The only
assumption
I
> want to make is that an assembler can *choose* to do so
with event
> producers and consumers that declare that they have an
> implementation that leverages the notion of "relatesTo"
or "replyTo".
>
> 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.
> I can think of use-cases where that doesn't work. For
example,
> assume I have a component A that produces messages on
some global
> domain channel //foo. At some point, some set of
components
show up
> in the system, and start receiving messages on //foo, and
perhaps
> some of those components (call them B, C, D) start
sending
> "relatesTo" information about messages originally sent to
//foo.
>
> How can component A catch these "relatesTo" messages?
Option
(1) -
> listen to a predetermined channel //bar (or //foo?) where
those
> messages are expected to be sent. Fails if the assembler
doesn't
> wire producers on B, C, and D properly, and
unfortunately, this key
> bit of information *isn't* in the model. Option (2) - A
consumes
on
> the default domain channel "//". Problematic in that
hosting
> environment of A, if not A itself now sees far more
messages than
it
> needs to, in order to find the ones it does want. Option
(3)
- as
> part of the originally produced message, send an
indication of where
> the "relatesTo" messages ought to be sent. This last
approach works
> even if A, B, C, and D are deployed in different
composites and at
> different times.
Well, I'll start by saying that components don't turn up
randomly in the
system and if the assembler isn't in control then all kinds
of crazy things
may occur. Option (1) seems a reasonable approach. I'd
certainly
expect
the assembler a) to know that B, C, D actually produce these
types of event
and b) to know that those events need to be sent somewhere.
The fact that
A
consumes events of that type is a bit of a hint...
The bit I don't buy is the notion that "replyTo" seems to
indicate
a direct
connection of some kind back to a single component only (A)
for the events
produced by B, C, D in response to an initial event from A.
Why can't
assemblers choose to direct those events wherever they
please?
Oh, and by the way, are you saying that "direct connections"
from producers
to consumers (without involving some intermediate channel)
are a good thing
and should be (re)introduced into the model??
>
> 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.
>
> I absolutely agree that the actual choice of how to
handle
> "relatesTo" messages should be addressed by the
assembler.
I'm just
> noting that by not supporting the notion of "replyTo",
we've
taken away
> one option for loosely coupling.
Ahem, I beg to differ on the interpretation here - far from
"loose
coupling",
this "replyTo" notion is an introduction of much tighter
coupling
between 2
components.
>
> 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).
>
> Indeed yes, if we choose not to model these details, then
SCA users
> will need to force such correlation information into the
> application/"business" layer, rather than letting it be
handled at
> the binding layer. Or they'll choose a vendor
implementation
that
> extends SCA to enable some amount of correlation to be
done at the
> binding layer.
>
>
> My other reaction to this material is to say "if you want
a
> response, use services/references, not event processing"
>
> I understand that reaction. I can see how what I'm
saying feels
> like it falls into the category of "if all you have is a
hammer...".
> But I think what I've offered above makes what I'm
arguing for
> different in several ways:
>
> 1) Eventing is about moving data, not invoking
operations, which I
> see as a key semantic difference
> 2) I'm not assuming a single "responder", nor a single
message
back,
> nor a response that comes back even to where it started
from. We're
> talking about choreographed message exchanges, rather
than
> individual message exchanges. Trying to model this with
WSDL,
or
> even with two WSDLs, is an effort in futility. Even
worse, trying
> to pretend that WSDL captures these choreographies
obscures the fact
> that the actual message flows aren't doing the standard
request/
> reply exchanges that WSDL typically models.
> 3) By not supporting some model notion of
"relatesTo"/"replyTo",
> end-user applications will be forced to move such data
into event
> messages, mixing transport and business data
unnecessarily, rather
> than having the binding take care of it.
> 4) By not offering some way of indicating a "reply"
destination,
> that moves a tight coupling elsewhere in the system - in
the form
of
> assumed knowledge about where those events will be sent,
or assumed
> knowledge about the types of events will be sent, or
both. Or
you
> build in unnecessary inefficiencies.
You will need to convince me on point #4 - I don't see
"tight coupling
elsewhere", neither do I see inefficiencies.
>
>
> 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...
>
> As I point out in #4 above, I think the association of
request/reply
> with tight coupling is a mental trap of sorts. Just
because
I've
> indicated a reply to address, doesn't mean that I've
tightly coupled
> anything. Rather, I've provided a means for late
binding. The
> world of HTML over HTTP is anything but tightly coupled,
and it is
> built entirely on a request/response paradigm. Some uses
of
HTML
> over HTTP are tightly coupled, but that just demonstrates
that you
> can abuse any system. I think I can assemble some fairly
> interesting message choreographies that will leverage a
"replyTo"
> notion, but that in no way implies that the components
involved are
> tightly coupled.
A "relatesTo" notion, I can buy (see previous comments), but
"replyTo",
if it is taken to mean "any events generated as a 'response'
to this
event MUST be sent to this place" I can interpret in no
other way
than a
tight coupling between the original producer and the
receiving consumer.
"replyTo" seems less than useful in the event processing
model
we've built
for SCA. I don't see the need for it.
>
> I, for one, question why JMS singled out "JMSReplyTo" as
the only
> way to send a Destination to a recipient. It ought to
have been
> more open ended than it is. WS-Addressing doesn't repeat
this
> mistake. But generically, the ability of the event
producer
to
> indicate one or more interesting "Destinations" for
sending
follow-
> on messages seems like a way to further decouple systems,
as it
> saves the recipient of those messages from having to
pre-emptively
> "wire" to those destinations.
The problem with these low-level wire-protocol features is
that in reality
they haze together the notion of message transfer with the
notions of
application composition, which we so cleanly separate in
SCA. I don't
see
the need to force the wire-protocol composition features
onto SCA - SCA
is
already far richer in that space. SCA can use the wire
protocol features
when they are useful, but only as a reflection of the
composition goals
that
are already shown in the SCA assemblies.
>
> -Eric.
>
>
>
>
>
> 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.
> >
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
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
|