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


Jim Marino wrote:
> 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?
> 

One of the mismatches:
 From a pub-sub dev POV, as a publisher I don't want to be aware of all 
the subscribers and vice versa. In the current model (for Java POJO) 
what I get on the reference side is an array of references -- which 
breaks the model. I then also have to iterate over the array and do a 
"publish" for each member of the array. That makes no sense from a 
pub-sub POV. I want to one publish per event/message. One-way is not 
pub=sub.

-Anish
--
--


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