On Sep 1, 2009, at 3:29 PM, Martin Chapman wrote:
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.
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.
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:
<reference name="foo"> </reference>
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) :-)
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>] >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?
Jim |