Re: [sca-assembly] TIBCO eventing proposal

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Thanks for sending this out. Even though pictures/examples are missing, 
I *think* I get the general idea. Few questions/comments about the 
details (not the overall design) that immediately came to mind:

1) Section 3.1 Exposing a Service as a Consumer says "The name of such 
an operation is understood to define an event type ..."
Can you elaborate on why the operation name has to define the event 
type? Perhaps I misunderstood what the doc says, but from an event 
processing perspective, I don't think you want to restrict which events 
are delivered to a method based on its method name. For example, an 
onMessage(...) method may (and typically does) processes any event that 
is delivered. The name onMessage has no relevance wrt which event types 
it wants to consume.

2) Section 3.2 Exposing a Reference as a Producer does not say anything 
about the cardinality of the reference. I assume it is 0..n.

3) WRT the minimum-novelty goal, I should point out that the W3C WSRA WG 
that is standardizing WS-Eventing and friends has found the need to 
separate the event type description from WSDL. See 
http://www.w3.org/2002/ws/ra/edcopies/wseventing.html#Advertising  There 
is also a plan (not sure if it is approved by the WG yet) for 
refactoring the event description part in a separate spec in the WG. 
Trying to fit/overlay event description into the WSDL portType/method 
model does have its problems.

4) In Section 7 Domain Channels, is your objection to the syntax or to 
the fact that a pub/subcriber deep down in a nested composite is 
"connected" to a domain-level channel, i.e. visibility issue?

5) WRT channelBinding.sca, is that really necessary given that 
binding.sca is magic anyway? Wouldn't binding.sca fit the bill?

Thanks!

-Anish
--

On 11/25/2009 5:13 PM, Scott Vorthmann wrote:
> Here is our proposal, in not a great deal of detail.  We'll have pictures and examples next week.  ;-)
> 
> Scott
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php