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