[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
> -----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. > > 2. SCA already provides a means to to define interface descriptions > for one-way MEPs. For example, abstract WSDL be used to define > interface contracts for one-way interfaces; that is, interfaces > containing exclusively in-only or out-only MEPs. Forcing developers > to use or define alternate descriptions for the set of inbound > messages, or completely forgoing those definitions, forces developers > to a different model for no apparent benefit. [<MartinC>] The trouble with wsdl is that it forces you to take sides. An in-only wsdl implies that it's the consumer that dictates the format of events, and to put them into a consumer specific collection will probably not make sense to any other consumer or producer for that matter. Also the operation names in WSDL doesn't make much sense either. Defining out-only wsdl, may be ok in a 1-1 relationship, but a consumer may not know who the producers are, and hence might not be able to identify the wsdl to use. Furthermore there is not much current industry support for out-only wsdl and they are not allowed in WS-I Basic Profiles. What we really need is a description language the is neutral to whether it is in or out. WS-Eventing seems to be going this way. > > 3. The proposed event definition language is entirely new ground from > a standardization perspective. Standards should follow state-of-the- > art, not lead it. In any case, the proposal should be cast as an > alternative interface type appropriate to services and references. [<MartinC>] State of the art seems to be heading away from in-only/out only interfaces- aside from in/out(any) which is about as useful as a chocolate teapot -into some neutral territory, and as long as we stick with XML schema we are not covering radically new ground, and can be supported with current tooling. > > Scott > > --------------------------------------------------------------------- > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]