From:
Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: 09 September 2009 22:23
To: Martin Chapman
Cc: Jim Marino; Scott Vorthmann; OASIS Assembly
Subject: Re: [sca-assembly] some of our concerns with the eventing
proposal
Martin Chapman wrote:
[full conversation below]
[<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.
I'm not sure how you've bound the syntax of services with the semantic you've
described, while explicitly not performing the same binding for events.
In my somewhat flippant interpretation of your statement, you've made events
magical entities.
>
-----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
---------------------------------------------------------------------
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