RE: [sca-assembly] some of our concerns with the eventing proposal

["Martin Chapman" <martin.chapman@oracle.com>]

> -----Original Message-----
> From: Jim Marino [mailto:jim.marino@gmail.com]
> Sent: 09 September 2009 14:56
> To: Martin Chapman
> Cc: 'Scott Vorthmann'; 'OASIS Assembly'
> Subject: Re: [sca-assembly] some of our concerns with the eventing proposal
> 
> Hi Martin,
> 
> I had one question below.
> 
> Thanks,
> Jim
> 
> On Sep 9, 2009, at 2:44 PM, Martin Chapman wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: Scott Vorthmann [mailto:scottv@tibco.com]
> >> Sent: 09 September 2009 08:47
> >> To: OASIS Assembly
> >> Subject: [sca-assembly] some of our concerns with the eventing
> >> proposal
> >>
> >>
> >> To inform the technical discussion we'll be having tomorrow, I'd like
> >> to shed some light on TIBCO's concerns with the existing proposal.
> >> The following is not exhaustive or terribly detailed, but is enough
> >> to
> >> begin discussion.
> >>
> >> 1. Eventing and publish-subscribe messaging are not the same thing.
> >> While it is useful for SCA to define a pub-sub alternative for the
> >> current wiring paradigm, that does not have to imply definition of
> >> new
> >> componentType concepts like consumer and producer.  We believe that
> >> pub/sub messaging can and should be fit into SCA without affecting
> >> the
> >> developer model.
> >
> > [<MartinC>] Would have to disagree here. I think the developer does
> > want to know if it is processing an event (i.e. can do what it
> > wants with it) vs servicing an explicit request from a client. So
> > some annotation or syntactic differentiation is required IMHO.
> >
> 
> Assuming a service is one-way and not bidirectional (in SCA terms),
> why would handling an event be any different than handling an
> invocation from a developer/implementation perspective? In other
> words, how would the difference between event data and invocation data
> manifest itself?

[<MartinC>] with an event, there is no  semantic contractual expectation on the side of the sender as to what the receiver will do
upon receipt - the operation name is meaningless for an event but carries some semantics for normal invocations.
e.g debitBankAccount(200) vs an event that says an Account has gone overdrawn.

> 
> Jim
> 
> ---------------------------------------------------------------------
> 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