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




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