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
|