OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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?

Jim


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]