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.
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.
I'm also not sure I follow why the service side is more complex. Are there some examples you could point me to?
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?
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.
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? :-)
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.
Jim