[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]