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


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


Anish Karmarkar wrote:
[full conversation below]
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.

I wouldn't go so far as to say that the current model's x..n wirings is anything more than a poor-man's hack to approximate pub/sub (perhaps *this* is Martin's chocolate teapot). 

However, using a binding such as JMS with a x..1 binding comes a lot closer to pub/sub.  One-way IS pub/sub IF your transport has pub/sub qualities. 

Squeezing pub/sub out of a fundamentally point-to-point transport like HTTP is going to take a much larger miracle than the current proposal.


4AA7D348.4030505@oracle.com" type="cite">

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

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

S/MIME Cryptographic Signature



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