MJE> Why does the existence of recipients for a message matter?
EEJ> Based on our discussion last week, perhaps a consumer of an event need to be able to flag that it must be a design flaw if there are no producers for an event for the channel(s) that the consumer is consuming? Do we also need an "design intent" (as distinct from a policy intent) on a producer that flags that all messages produced should be consumed, or there's a flaw in the design (as an analogy, a Java method signature forces that all parameters are provided - what's the equivalent for an "eventing" system?)
MJE> For most components inside the SCA system, "binding.sca" is enough and most of the time does not need to be stated.
EEJ> Based on our discussions last week, this approach probably requires that we think about additional policy intents that we wish to introduce into the system. Perhaps "durability" fits the bill. That way, we can architecturally accommodate sporadic connectivity for WANs and mobile.
MJE> I may also legitimately request delivery of events within certain deadlines - again, HOW this is done and whether a given binding infrastructure can honour the request is a separate issue.
EEJ> This point is curious - this isn't quite a policy intent, because it involves a threshold value that an intent doesn't capture. How might we represent this as part of an architecture?
And from the minutes:
"Do we have portability?"
EEJ> I maintain the answer is "no", because the implementation details, and consequences thereof, of eventing are potentially so wildly divergent as compared to request/reply services, which have a known minimally acceptable baseline (SOAP over HTTP). As we discussed during the call, this might be covered by the right set of intents that *must* be supported by binding.sca.
-Eric.
On 1/24/12 3:14 PM, Mike Edwards wrote:
Eric,
Comments inline in red
Yours, Mike
Dr Mike Edwards Mail Point 137, Hursley Park STSM Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards United Kingdom Co-Chair OASIS SCA Assembly TC
Chair UK ISO SC38 mirror committee (Cloud & SOA)
PEPPOL eProcurement team member
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: OASIS SCA Assembly <sca-assembly@lists.oasis-open.org> Date: 10/01/2012 14:17 Subject: [sca-assembly] Questions to start on Assembly-247 Sent by: <sca-assembly@lists.oasis-open.org>
Happy New Year!
Now back to work.
The issue title: What are the requirements on an SCA Binding for eventing purposes?
http://www.osoa.org/jira/browse/ASSEMBLY-247
I was thinking of trying to come up with a broad outline of what the document should be, and then realized I'd start with just a list of questions. The problem, at the outset, strikes me as just a little too big to just come up with a proposal document, without some better direction.
As I was putting this together, I realized why I think this question is so important for "event" oriented systems. If we have no guarantee of any recipients, how do we determine when that absence is triggered by normal but infrequent expected behavior, by an operations failure, by a deployment failure, by a design failure, or is currently working as intended?
I suspect that the fundamental challenge for an SCA binding for eventing, and the requirements SCA puts on said binding, is to figure out how to answer that question.
<mje> Strange, but for me, the question you ask seems almost irrelevant in regard to a binding.
Why are bindings of any relevance to SCA?
- a binding defines specific concrete ways in which communication can occur.
- in most cases, the reason for specifying a binding is to deal with application components that
exist outside the SCA system - for most components inside the SCA system, "binding.sca"
is enough and most of the time does not need to be stated.
Why does the existence of recipients for a message matter?
- I think that this is mostly a design question, in the sense that the application creator must have
a view of the overall application design & whether a particular set of event messages must be
handled somewhere in order for the overall application to make sense.
- Where there are errors of one kind or another, I would hope that the runtime can report them
when they occur, although I can agree that some kinds of errors related to external components
might be tough to detect (eg the non-arrival of events from some external source - is that an error
or simply that there are no events of the type expected?)
</mje>
What characteristics does the binding have? Specifically:<mje>
- Capability
- How large an "event" can it support? (BEEP vs. JMS)
- What policies can it support?
- What policies can it never support?
- Efficiency:
- Does it use/support compression? (gzip, EXI, etc.)
- Is XOP supported to contain large binary objects?
- How quickly can a message be delivered? And the converse - how long before an application can reasonably assume failure due to a lack of "reply" events?
- Filtering:
- Where is filtering applied? Is it happening at the sender? Is it happening at the receiver? Is it being done by an intermediary choke point? Or some combination of the above?
- Does the filtering approach have consequences with respect to behavior and performance?
- Message Flow
- Is it a hub & spoke, UDP broadcast, or successive P2P connections?
- Does the binding care about crossing network subnet boundaries?
- How well does the eventing system work with wide-area networks (WAN)? Does the behavior change when crossing WAN boundaries?
- How does the system behave with sporadically connected clients (think phones, remote machines with dial-up connections)?
- To the extent that messages are persisted prior to delivery, where are they persisted? In the JVM of the sender? In a process on the same box as the sender? On a server box elsewhere? In a distributed-hash data cloud? What effect does that have on average reliability?
These are all good considerations for a binding, but I don't see them as particularly relevant for
the design of the application as represented in the SCA assembly - and in particular what an SCA
<binding.xxx> element would contain when dealing with producers, consumers & channels.
Capabilities: The SCA app simply states its requirements - I'm particularly thinking of Intents here -
and the binding chosen either can satisfy those requirements and everything is hunky-dory, or it can't,
in which case I hope that we get a nice honking error when we try to deploy. I note that this is how things
work for bindings on services & references - e.g. I can request the Confidentiality intent and if the binding
can't do encryption, then a deploy error should result.
Efficiency: If you care about these sorts of things in your application, then there needs to be some policy
representation of them, that a binding can either satisfy or not. I note that the 3 examples that you supply
could well apply to service invocations as much as emitted events.
Filtering: I'm not exactly sure why an app developer would care about where filtering is done, or why.
Can you envisage some _expression_ being applied to a producer or to a consumer that would capture
concerns such as these? I get the impression that I might care a lot as a runtime about these considerations
but it's not clear why the app itself cares.
Message Flow: Why does the application care? To what extent is it the concern of SCA to capture details
like the ones you list here, which to me appear to be qualities of a runtime.
I might legitimately ask for Reliable Delivery of event messages as part of the application configuration -
after that it becomes a runtime concern HOW this is done and the impacts on storage/performance etc that this may have.
I may also legitimately request delivery of events within certain deadlines - again, HOW this is done and
whether a given binding infrastructure can honour the request is a separate issue
</mje>
Does the binding allow connectivity with non-SCA sources?
<mje>
This has to be the principal reason for specifying the binding in the application configuration (ie in the SCA composition)
If it is simply a configuration of the SCA runtime, why does the app developer care?
</mje>
Must all messages sent have an event type?
<mje>
Good question.
We debated this before and my understanding is that it could be the case that
an event message has no "event type".
Why does this matter for a binding?
</mje>
The above probably works as a starting point for coming up with additional questions, and for figuring out which of those questions matter to the TC.
-Eric.
--------------------------------------------------------------------- To unsubscribe, e-mail: sca-assembly-unsubscribe@lists.oasis-open.org For additional commands, e-mail: sca-assembly-help@lists.oasis-open.org
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
