Minutes
Opening
Roll - quorate with 20 of 30 voting members present
Resolution: Minutes of 2009-09-08 approved w/o
In the minutes of 2009-09-15 the resolution to issue 174 were incorrectly described in the resolution as issue 172
Resolution: minutes of 2009-09-15 approved with the correction above w/o
Action Items
Action: id=2009-09-15-1 status=done Booz to offer alternative wording for Assembly-165
Administrivia
Doodle poll opened for available eventing call times
<Mike Edwards>
Doodle poll for alternative days & times for Event Processing discussion:
Three LOA requests, Chapman, Malhotra and Kand, approved w/o
Test Assertions and Test Cases
Public review will complete on Oct 17, please make comments on the public review list
Issues with proposals
This proposal was intended to deal with comments received
Edwards reviews his proposal
Nash:
suggests reverting to the current language concerning multiplicity ref resolution ti Issue-136
<Mike Edwards>
to read "@multiplicity attribute is set to the value of the @multiplicity attribute of the <reference/> in the composite"
<Simon Nash>
need to step away from the phone for a few mins...
Booz presents his proposal in the Jira
Edwards walks through his proposal
<Mike Edwards>
Change the composite reference wording to:
<Mike Edwards>
Replace the final sentence of the paragraph describing the <callback/> subelement of a composite reference (line 1511/1512)
Callback binding elements attached to the composite reference override any callback binding elements defined
on any of the promoted component references. If the callback element is not present on the composite service,
any callback binding elements that are declared on all the promoted references are used. If the callback element is not present
at all, the behaviour is runtime implementation dependent.
Motion: m:Edwards resolve Assembly-181 with the proposal in Jira modified by Replace the final sentence of the paragraph describing
the <callback/> subelement of a composite reference (line 1511/1512)
Callback binding elements attached to the composite reference override any callback binding elements defined
on any of the promoted component references. If the callback element is not present on the composite service,
any callback binding elements that are declared on all the promoted references are used. If the callback element is not present
at all, the behaviour is runtime implementation dependent.
Resolution: m:Edwards s:Nash Resolve Assembly-181 with the proposal in Jira modified by replacing the final sentence of the paragraph
describing the <callback/> subelement of a composite reference (line 1511/1512) w/o
Callback binding elements attached to the composite reference override any callback binding elements defined
on any of the promoted component references. If the callback element is not present on the composite service,
any callback binding elements that are declared on all the promoted references are used. If the callback element is not present
at all, the behaviour is runtime implementation dependent.
JIRA seems to be wedged at the moment
Other proposals
Edwards:
Suggests that folks look at proposals for 139 and 157 for next call
AOB
Meeting of 2009-09-22 reconvenes
Additional roll is called
Discussion of Approach to additnal work on Eventing and its potential impact to SCA 1.1
<EricW>
General comment - using existing (tweaked) model to BUILD an event mechanism is a developers view of SCA...
<EricW>
... an Assembler would prefer a "artifact" that embodies an event handling mechanism
<EricW>
... it's really a case of what abstraction we want to provide
<Scott>
oops, killed too many hands
Chapman:
Events may be one to many so it is a different think than a simple one-way message
<Sanjay>
Sabin, not sure i follow your point. how does op name help for correlating multiple invocations?
<Scott>
I think he means correlate in a different sense, Sanjay
<Scott>
as in "I can consume this collection of events"
<Mike Edwards>
Sanjay - I think what I heard both Scott and Sabin say is that Operation_Name == Event_Type when WSDL is used in this context
<Scott>
that collection is the correlation he means
<Jim>
FWIW I think Scott's point about not impacting the developer is very important
<Sanjay>
Can we preserve the developer's view when filters are required?
<Martin C>
i guess if the app code recieves a message, does he care whether it passed a filter or not?
<Sanjay>
the interface developer will have to care about the ability of allowing a filter, right?
<Sanjay>
I am referring to filter based on type. The filer based on data values can be handled with current interface technology.
<Sanjay>
well I guess 'filter based on type' is called 'subscribe' in the current proposal.
<Martin C>
the point is the current model doesnt allow for a message on a service to be filtered out - the current semantics are it must
be delivered - with policy intents to say how hard they must try
<Sanjay>
oh no ..hopefully you are not suggesting to use a policy of 'do not try hard'
<Martin C>
i think its called at least once;)
<Martin C>
thats the easiest to implement i think
<Martin C>
or is at most once = "dont try to hard"
<Sanjay>
well with a filter blocking a message type, the equivalent policy may be 'not even once'
<Sanjay>
so i guess the programmer might not care, but the interface designer will have to distinguish between whether the component
is offering a service or is subscribing to events
<Martin C>
thats our view
<Martin C>
and the "wires" and matching rules are very different e.g. you dont have to have any matching on a pub/sub wire
<Martin C>
someone can send even if no one is interested
<Sanjay>
what I am struggling with in my mind is - is the filter a configuration of the component or the channel?
<Martin C>
IFF we are to use wsdl and wires, then i think we do need annotations in scdl to distinguish between refs/services and producers/consumers
<Martin C>
sanjay its both, its a components config onto a channel
<Mike Edwards>
Sanjay - in my opinion, a Filter could be applied in 3 places (logically)
<Mike Edwards>
1) in the Channel (this channel only transmits messages X, Y, Z)
<Mike Edwards>
2) On the Consumer in the Assembly layer (the Assembler only want X, Y to reach THIS consumer)
<Mike Edwards>
3) In the consumer (the developer says, I only want to receive X)
<Sanjay>
Thanks Mike. But in all the three cases, there is no impact on the component design, development or deployment, right?
<Mike Edwards>
there is for case 3)
<Sanjay>
And what we want to capture via produce/subscribe/filters metadata is essentially configuration of the channel/broker!
<Mike Edwards>
the developer needs to mark his component in some way
<Martin C>
or your relationship to the channel/broker
<Sanjay>
which currently may be done by invoking publish/subscribe API, and more importantly, what is the main reason for combinging
this channel-relationship info in the composite ddefinition?
<Martin C>
so you can take it out the vode
<Mike Edwards>
One question I would like to ask Scott & Sabin is whether there would literally be 1 event type per operation in the consumer
implementation - ie there would be no equivalent of "getMessage( Foo )" where Foo could be any one of a large set of event
types
<Sanjay>
what's with all oracle folks going on vacation?
Next session on eventing will be in two weeks
<Sanjay>
riding the Deathstar?
AOB
Schreiber diagnostics output
[Delete this section before publishing the minutes]
final validation: Title not specified, default title 'OASIS SCA-Assembly TC...' was assumed
final validation: Chair not specified, default chair was assumed
statistics: Schreiber found 113 input lines
edits: Schreiber found the following text-edit commands:
edits: Line 4: s/1./Agenda: 1.
edits: Line 35: s/discription/description
edits: Line 67: s/Agenda/Agenda:
edits: Line 81: s/"component"/"artifact"/
command-scribe: Line 2: Bob Freund is recognized
command-scribe: Line 2: Bob Freund's nick Bob has been selected
edits-command-processing: In command on line 4 search text '1.' was not found.
edit-substitute: command on line 35 succeeded, changed line 34 from 'discription' to 'description'
edit-delete: Line 35 was deleted
citation-detection-scribed: Line 56: Check for possible unrecognized nick 'ASSEMBLY 167'
edit-substitute: command on line 67 succeeded, changed line 64 from 'Agenda' to 'Agenda:'
command-scribe: Line 66: Bob Freund is recognized
command-scribe: Line 66: Bob Freund's nick Bob has been selected
edit-delete: Line 67 was deleted
edit-substitute: command on line 81 succeeded, changed line 80 from '"component"' to '"artifact"'
edit-delete: Line 81 was deleted
command-autoroll/oasis: Line 160: Attempting to fetch roll from http://www.oasis-open.org/apps/org/workgroup/sca-assembly/event.php?event_id=16110
command-autoroll/oasis: Line 160: Successfully fetched roll from http://www.oasis-open.org/apps/org/workgroup/sca-assembly/event.php?event_id=16110
system: Transformer: SAXON 9.1.0.7
[End of Schreiber diagnostic output]