More comments inline.
Another general comment on the discussion...It seems a fundamental problems is the concept of eventing is too vague. A useful step would be clearly define what it is, which includes general agreement on why it is different, not different, or a specialized subset of service-based design. So far, none of the explanations put forth really seem convincing as to why it is different. So, I'm going to keep pushing on trying to solve this with existing concepts by working through concrete examples and see where we come out. It may turn out that eventing is something entirely new and isn't possible to model via service-based design as it is currently laid out in Assembly. This will take extra time but hopefully provide the benefit of having some specific examples and more precise definitions/concepts.
Jim
What I find frustrating in this discussion is the premise that we
don't need to do anything, followed by some hacking of how to make
it work. We either need to do something or we don't.
I haven't seen any proposal that says nothing needs to be done. The
disagreement is over whether new concepts are required or existing
ones suffice.
[<MartinC>] This is a contradiction. The current concepts are not adequate, and even you have bee proposing tweaks to them. I don't see how the above statement is a contradiction. You may disagree with me and believe new concepts are needed to handle your use cases. And, you may believe that my proposal "backdoors" new concepts. I'd like to understand specifically why new concepts are needed with concrete cases that put it in evidence. [<MartinC>] You keep saying nothing needs to be done, then talk about your proposal. I’m confused.
OK we have a confusion in terminology. I am saying something needs to be done. However, that something is potentially not defining new concepts *at the assembly level*. Rather, it is creating a new binding or set of bindings with associated configuration. In the end, we may wind up having to introduce new concepts but we should not start from that position. I'm sorry you are frustrated with having to go through this, but Oracle's proposal was developed outside of OASIS and it is new to many of the people with an interest in the Assembly TC. It also entails very significant changes to assembly so it is natural for it to be questioned. Ultimately, it may turn out new concepts are needed, but I would rather err on the side of caution at the outset, particularly given that we should have substantial user feedback before embarking on major changes to SCA. [<MartinC>] I actually haven’t been pushing a proposal as such, merely trying to get some acknowledgment that pub/sub does require some tweaks to the existing model.
How come we do pub/sub with the JMS binding then? I'm sure there are improvements that can be made to the JMS binding and potentially assembly, but what are they specifically? That is what I'm getting at.
Also, I've got to laugh about you guys not pushing a proposal. There was a concerted effort the other week from Oracle to include the eventing proposal as part of Assembly 1.1 :-) The current model requires references and services to be wired,
This is not accurate. It requires them to be configured with a
binding. That is different.
[<MartinC>] Im sorry, the current model requires a wire or a target to be specified, independent of what binding is used.
I'm not sure we are talking about the same thing. A reference can be configured using a binding without any wiring or targetting to a service. For example: [<MartinC>] To an external service, what about to an internal one.
It can be bound to an internal one the same way. In that case, it is not wired.
requires the
interfaces on each end to match (or at least a subset to match),
This is also not accurate. My proposal requires the *data* to match
(i.e. be the same type or a substitutable type), not the interfaces.
[<MartinC>] Im getting confused dipping in and out of the current 1.1. model and your on the fly proposal. Im trying to stay at the
current model and understand its deficiencies.
I'm not dipping anywhere :-) I'm using Assembly 1.1 concepts.
believe this is required of all approaches. I'll also note at the risk
of belaboring the point that this is how the JMS binding behaves. For
example, I can configure a reference with the JMS binding pointing to
a destination A and configure a service using the JMS binding that is
associated with the same destination. The reference and service can
have different interfaces as long as the data matches.
[<MartinC>] Not with the current 1.1 definitions and JMS binding you can't
Yes you can as long as a mapping is possible (and it is) :-) [<MartinC>] which mapping is this?
As long as the data matches and you can map to an operation on an interface or class in the case of Java, i.e.
public interface MyConsumer {
void onFoo(Foo foo); }
and then relies on a binding to support the 1-to-1 interaction. If
you take the need for a wire out of the equation and push
interaction semantics (1-m,m-1, m-n) down into a binding, you have
IMHO
invented a different type of wire, for which the current semantics
(such as interface matching) are no longer necessary - and for
which autowiring may become very problematic.
My proposal doesn't invent anything new here. This is exactly how a
reference behaves when bound to a service provider that is hosted
outside the domain.
[<MartinC>] Yes but we are within a domain not outside it... My point here is that it is similar to how an "external" service is configured, not that the consumer is hosted outside the domain. [<MartinC>] Similar but different…
But what is your point?
[<MartinC>] >In this context, interface matching is not done as
with a wire. Also, autowire has nothing to do with this use case as autowire is only used for wiring references to services (by the
definition of wiring, in the same domain), which is not being done here.
I don't think we need code snippets to explore these differences, as
we have to be
able to conceptualise at the SCDL level.
I'm sorry you disagree and would urge you to reconsider. I find
walking through concrete examples - code and SCDL - very useful since
it helps establish a common understanding and vocabulary. In my
experience it also helps in driving consistency at a conceptual level
and validates a design.
One of the use cases we have within Oracle is in the presentation,
that of a new employee.
Rather than build an HR business process that hard wires (pun
intended) the processes required throughout Oracle,
the HR system send out a new employee event. This is then captured
by whoever is listening (payroll, IT, directory updates,
security), of course the HR system doesn't know beforehand who and
how many other recipients there are. In addition each listener
may also be listening for other events from other producers in the
system, and typically there is an additional listener who
captures all events into a log. This type of scenario is hard to
model with SCDL as it stands, even though we tried.
I would like to walk through the difficulties using a combination of
SCDL and code. If you agree, I can post an example of what I was
thinking.
[<MartinC>] The trouble is you are commenting on our proposal by making your own proposal, which is fine, but unless you write up a
proposal in full it really is hard to follow this discussion, scl and or code snippets aside. That's really my main point here.
The point of my "proposal" was not to submit something for formal consideration this early but to use for illustration as my understanding is we are just beginning to consider eventing and much work needs to be done. In that light, isn't it better to start with a set of concrete use cases and examples that illustrate the main issues at stake. Putting these in code and SCDL give us a common vocabulary for discussion. Wouldn't this be a good way to move discussion forward working together rather than simply putting forward an alternative? [<MartinC>] I have provided a use case, show me some scdl…
Sure. Give me a few days (I am tied up at work) and I'll provide some SCDL and code.
Jim |