Raw chat log of Dec 1st AM F2F meeting

Title: Raw chat log of Dec 1st AM F2F meeting

khanderao: Do we have a call today?

khanderao: I mean on chat and telecon too ? in addition to F2F?

Graham Charters: I was wondering the same. :-S

Graham Charters: I'm guessing not. I'm gonna drop.

khanderao: If the call is there it will be 1 hr from now I guess

Mike Edwards: We will start the call for the F2F in a couple of minutes

Mike Edwards: Tuesday 

09:00 TIBCO Event Processing Proposal 

10:00 Discussion of TIBCO Proposal 

12:00 Lunch 

13:00 Assembly Specification V1.1 completion 

consideration of remaining issues and work items 

17:00 Finish 

19:00 Team Dinner 

Wednesday 

09:00 OSOA Event Processing spec document 

10:00 Discussion of OSOA spec 

12:00 Lunch 

13:00 Discussion of potential combined Event Processing proposal 

- agree on major features of the proposal 

17:00 Finish 

Thursday 

09:00 Discussion of significant areas of flexibility required in the Event Processing model 

11:00 Assembly Specification V1.1 - slot for any follow up discussions and actions 

12:00 Lunch 

13:00 Discussion of linking SCA Event Processing with existing event processing 

systems such as JMS 

16:00 Build Plan for work on Event Processing specification 

- create and allocate work items/issues 

17:00 Wrap up and Finish

Martin C: Change start time for wednesday and thursday to 8am pacific

Mike Edwards: Minutes from Previous Meeting

Mike Edwards: http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/35262/SCA%20Assembly%20minutes%202009-11-17.html

Martin C: Meeting is quorate (13/25 - 52% at present)

Sanjay: Minutes approved unan

Sanjay: Next item: TIBCO Event Processing Proposal

Sanjay: http://lists.oasis-open.org/archives/sca-assembly/200912/msg00004.html

Sanjay: Scott describes the TIBCO proposal ...

Sanjay: Eventing related metadata can be handled as mapping of Component in a composite to the ComponentType presented by the implementation

Mike Edwards: folks on the phone - please use the queue if you would like to ask a question or make a comment

Sanjay: Java methods with void return, or one-way WSDL operations is one way of developers implementing event producers/consumers

Sanjay: Alternative of generic event dispatch methods should also be allowed

anonymous morphed into EricW

Sanjay: Anish: One of the reasons behind the osoa design was - to indtroduce a decoupling between event producers/consumers whereby there is no assumption on the event producer about the consumption of the events, its semantics, etc

Sanjay: Martin: We have seen a need to extend BPEL to support events (as opposed to linking partnerLinks)

Sanjay: TIBCO proposal uses interface element and its extensibility to model event types, filters

Sanjay: Differences of eventing specific binding types

Sanjay: ... not all service/reference bindings may be applicable for eventing

Sanjay: ... configuration of eventing binding may also be different from service/reference bindings

Sanjay: Peter: Would not want to have binding configuration determine the semantics of the logical model

Sanjay: ... e.g. filters in the bindings

Sanjay: Anish: Does the application code for an event producer know about the connection with the consumer?

Sanjay: MikeE: It is far simpler for programmer to have a eventing proxy to code against

Sanjay: Discussion on cardinality

Sanjay: Does cardinality of event producer matter in the developer model or the assembler model?

Sanjay: Optimization of the producer to turn off the event creation if nobody is listening may be a use case, but we are not supporting that

Sanjay: General consensus that producer cardinality does not make sense in the developer model - details to be sorted out

Peter Niblett: ..so long as you are permitted to connect a producer to more than one channel

Sanjay: Discussion on bindings for eventing

Sanjay: Anish: Could we adopt a model similar to service/reference bindings - within a composite, only services are allowed to have bindings?

Sanjay: Scott: Specifying filters may get tricky

Sanjay: Anish: How about bindings are limited to channels - and channels mediate if different bindings are used by producer and consumer

Sanjay: Discussion on Filters

Sanjay: Peter: Developer of a consumer knows about the filters to be applied

Sanjay: ... which is completely independent of the binding

Sanjay: ... place where filters are specified in the composition should provide the flexibility to the developer to use messaging for applying filters

anonymous morphed into Pradeep

Sanjay: Scott: Application of filters could be optimized and pushed upstream (to the producers) in the eventing world

Sanjay: Point of discussion: Whether consumer developer could trust that filters will always be applied

Sanjay: Next section from TIBCO proposal: Domain Channels

Peter Niblett: I would like to congratulate TIBCO on the quality of the audio in the room. I can hear every word and it feels as if I am really in the meeting - it's an order of magnitude better than other remote meetings that I have attended

Dave Booz: yes, +1 from me as well

Sanjay: Meeting resumes

Sanjay: Similarities between OSOA and TIBCO models

Sanjay: - producers, consumers, channel model elements are similar

Sanjay: Differences -

Sanjay: a> Use of interface extension point as opposed to list of event type names

Sanjay: b> osoa requires explicit modeling of producer/consumers, tibco model supports mapping of service/reference to consumer/producer

Sanjay: c> Channel transparency - use of domain channel deep in the composite with // convention

Sanjay: d> Binding types - generic vs specific (producerBinding, consumerBinding, channelBinding)

Sanjay: e> Filters - as interface/binding metadata or as an explicit construct?

Peter Niblett: +1 to Anish, that's an important question, and I think we do need the canonical filter

Sanjay: AgreeCment: Filtering can be expressed by a component developer as well as assembler

Sanjay: ... you could apply filters on the body (syntax to be discussed) and also on bindings

Sanjay: Not resolved: Are component type defined filters a hint or a requirement?

Sanjay: Wiring rules in TIBCO proposal - the channel and producer/consumer would have methods with matching name and signature - portType name is ignored

Sanjay: these rules do not impose restriction on producer to not produce other events than what is declared

Peter Niblett: For the record, the way we ended up in OSOA at the end of the discussion on producer type declarations were

Peter Niblett: 1 A producer SHOULD only produce event types it has declared

Peter Niblett: 2.An SCA Runtime MAY reject events of a type from a producer which does not declare that

it produces events of that type

Peter Niblett: we noted that a) When the event types produced and consumed are explicitly declared, it may be possible

to avoid the need for runtime event filters on the consumers, providing an optimized path

for the handling of the events.

Peter Niblett: b) Because the channel, producer and consumer declarations can include a list of event

types, it is possible to report an error when a producer or a consumer is connected to a channel, where there is no chance that the produced events will be accepted by the

channel or the consumer will ever get any event.

anish: i think the issue is the mismatch between event processing and interfaces. With TIBCO proposal, we'll have to create parallel bindings for eventing, so binding.wsEventing, binding.jmsEventing etc. If we use WSRA's EDL (and the mapping requirements), then we can reuse the existing binding

jeff.mischkinsky: (Autoreply) lunch/dinner/snack -- yum, yum