From: Jim Marino [mailto:jim.marino@gmail.com]
Sent: 31 August 2009 11:45
To: Martin Chapman
Cc: 'OASIS Assembly'
Subject: Re: [sca-assembly] Pointer to SCA event processing presentation
Hi Martin,
I have specific comments inline. As a general comment, I am
afraid without concrete examples, we are going to wind up talking past each
other. I propose that we include actual examples when appropriate to
illustrate our points so that we can be as clear as possible. Otherwise, we are
going to remain at a very abstract conceptual level that will create confusion
and lead to differing interpretations.
On Aug 28, 2009, at 6:13 PM, Martin Chapman wrote:
Jim, didn't mean to imply not
to carry on the email discussion, so here are some responses.
Martin.
<snip/>
Based on this example, I've included some comments with
respect to
the
slide from the deck mentioned above:
1. No decoupling
I think the above example is fairly decoupled. It requires a
reference
to be bound (but not wired), which I think is the correct
behavior
given that allowing 0..n would require code to check for
null
pointers
making it complex. If there was no consumer, the binding
would
swallow/
ignore the event.
[<MartinC>] Since I think a reference can only be either a normal (sca
1.1) reference or a reference to an eventing channel (but not
both) does it real make sense to overload the semantics. I agree there is a lot
of syntactic similarities, but since the semantics
are very different between the two modes of interactions is it wise to use the
same syntax. Also, I think references/publisher is
the easy side of the equation, the service is more complex imho. For bindings
we need to be able to also indicate the underlying
technology binding, so that we can configure binding.eventing.jms or
binding.eventing.mq, this is a change to the current binding
model.
There are a number of things I think we need to work through
here...
First, I'm not sure I follow what you mean be
"normal" reference or a reference to an "eventing channel".
In my mental picture, a channel is an implementation detail of the
binding. Consequently, references on deployed components are never connected to
a "channel" and are in on of three states. These states
are: wired (to another service); or bound; or not wired or bound. The
fact that invoking a reference may deliver data over a channel is an
implementation detail of the binding. From the perspective of the component
implementation, it only "knows about" the reference. This is
consistent with the JMS binding, particularly the use of topics.
[<MartinC>] My point was that you are proposing syntactic additions,
but those additions are mutually exclusive to the current model
In your proposal, why does the concept of a channel need to
be surfaced to the component implementation? If JMS does capture the semantics
of messaging, I don't see why this is a requirement since the JMS binding does
not surface the concept of topics to component implementations. Having
consistency at this level greatly simplifies the SCA programming model.
[<MartinC>] You examples had channels as well! Channels are
a way to partitions traffic, so some concept of them are needed, even if it’s
a binding configuration. The current jms biding is about supporting
client/server interaction not a pub/sub model, so it no surprise topics do get
surfaced.
I'm also not sure I follow why the service side is more
complex. Are there some examples you could point me to?
[<MartinC>] If I have 12 producers each producing 20 (or
so) events of different types, what is the service interface? What happens when
I add a new producer that produces events of a previously unknown type?
I don't think I agree with you that the need to
"configure the underlying technology binding" implies bindings cannot
be used. I may be missing the point of what you are saying but today bindings
allow configuration that affect the underlying transport technology. To start
with, I wonder how many users will need to specifying different eventing
"transports" on a component configuration. It seems like doing
so will result in very complex and unwieldy applications with multiple eventing
transports which don't interoperate. My impression is that in the majority of
cases, one eventing transport would be configured in a domain. However, I guess
there could be a need for multiple transports. Why not follow the current
approach we have with binding.sca and binding.jms? In this case, the following
bindings would be defined:
1. binding.eventing - a generic eventing binding. The actual
transport is vendor specific. This is similar to the way binding.sca works as
well as binding.jms, which does not define a specific transport technology.
2. binding.eventing.foo, binding.eventing.bar,
binding.eventing.baz, etc. where "foo", "bar", and
"baz" defined specific transport technologies.
This would not define any new concepts at the assembly
level.
2. Requires interfaces for typing
I'm not sure I follow this. My understanding is that for
strongly
typed languages such as Java, some interface is required. If
an
interface is not required, how is an event sent in Java?
Even other
language, some shared type system or type mapping is
required.
[<MartinC>] The issue here is whether the recipient barfs if it gets
something it didn't quite expect.
In RMI, if you don't get your parameters matching you get a system failure -
this is strong typing.
In JMS you have to unpack and decipher the onMessage contents, and its up to
you if you barf or not. Its more loosely typed as you
can tolerate different data.
Sorry, I'm not following you here either. The original
assertion as I interpreted it was that eventing cannot be constrained by the
need for typing via an interface. I think you are saying that eventing requires
loosely coupled contracts. If the requirement is the latter, then I would say
just make sure the contract for the event consumer is loosely coupled and the
databinding technology used for events that cross process- or
language-boundaries supports such features.
Many messaging and intermediary systems have the requirement
for recipients to receive messages they don't completely understand. These
systems have been successfully incorporated into SCA using existing concepts. I
don't see why eventing is any different.
What would potentially help is a concrete example. Do you
have one you are thinking about in this context that shows how assembly cannot
accommodate eventing?
[<MartinC>] of course the typing issue can be solved by
using xml:any( or java.Object,) but it doesn’t really help the app
programmer who then has to unpack the any and do work.
3. Interface/operations have processing semantics, events
don't
I'm not sure I agree with the assumption that interfaces
have
processing semantics. How does MyChannel.onEvent() imply
processing
semantics?
[<MartinC>] At one level, send(msg) receive(msg) everything is the
same, but as you go up into the application level code there are
two modes of thinking: send this message to whoever verses interact with
a service provide to do something, the later has a service
contract at the destination.
Can you provide me an example of an event consumer written
in Java or some other programming language? Otherwise, I don't think we will be
able to follow each other.
One thing that would help is if someone could provide a
Java code example that did not imply processing semantics so
a
comparison can be mode.
[
[<MartinC>] The point is that there is no semantic contract between a
producer and a consumer, but there is between client invoking
a service. That's what we mean by implied processing here - semantic contract.
In my example, what is the implied semantic contact? I don't
see any. Note I could pass Object or String as the event type.
[<MartinC>] in general in pub/sub, jms etc when
someone sends a message the producer doesn’t know what any recipient will
do with the message – one recipient could ignore it, another could give
me a bonus, another could log it etc. That’s what is meant by semantic contract.
Note that the MyChannel example was strongly
typed, but the following could also be defined:
public interface MyUntypedChannel {
void
event(Object event);
}
4. Doesn't allow addition of producers/consumers dynamically
I think the proposal above addresses this concern. It would
be up to
the binding infrastructure to handle this. Note that I think
there
may
be an incorrect assumption related to references/wires as
well. Wires
can be updated dynamically.
[<MartinC>] Your proposal does address this but see comment above about
syntax vs semantics.
5. No ability to set filters
This would be handled in the binding configuration. In the
example, I
used an attribute but it could also be modeled as an element
for
complex expressions. I'm hoping the filter language will be
left open
as opposed to inventing one.
[<MartinC>] Again this is a syntax vs semantics issue. Filters only apply
to eventing (I hope at least) so lets separate out
concerns.
In my view, filters only apply to events (although there is
a concept of filters in JMS as well) - that's why it is an attribute or element
specific to the proposed event binding.
6. Various issues crop up because of the model mismatch. For
example,
sca:reference(0..n) is mapped to an array in Java
This would be addressed by using a bound required (1..1)
reference.
[<MartinC>] Ok there are
restrictions if you use a reference for eventing. By the time you have
enumerated all the restrictions and
additions it gets very confusing.
Can you provide the "top-10" restrictions, or
maybe just five? :-)
[<MartinC>] I can do 4;)
1. The reference has to be 1..1
2. the reference cannot be wired
3. what is the interface
4. what are the interface matching rules
Also, note that 0..n does not have to map to an array in
Java, it can
also map to certain collection types. Are there other issues
along
these lines?
[<MartinC>] Yes, another
issue is that application programmers want to send one event, not go through
sending it to multiple
places.
In the approach I am proposing, developers don't send the
event to multiple places. Rather, it would work exactly as the JMS binding
works when configured using topics (pub-sub). From my previous example, the
single reference invocation:
channel1.onEvent(event1);
could potentially be received by multiple listeners. From
the client perspective, the receivers are decoupled via the eventing binding in
the same way they are with the JMS binding - it has no knowledge of what is at
the other end, if anything.
|