Minutes
Opening
Roll call 15/18 = 83% Quorate
Resolution: Minutes of 2011-01-18 approved w/o
Action Items
Action: id=2010-09-22-8 status=pending owner="EricJ" produce new proposal for ASSEMBLY-227
Action: id=2011-01-04-1 status=done Johnson in absentia to create a proposal for the resolution of Assembly-239
EricJ:
Proposal for ASSEMBLY-239 completed & waiting for comments
PeterN:
Have provided comments - need wider debate
Action: id=2011-01-04-2 status=pending Edwards to write a new proposal for the resolution of Assembly-246 along the lines contained
in wsra
MikeE:
Waiting for new draft - now available
Action: id=2011-01-18-1 status=done Edwards to take the appropriate steps with TC-Admin to accomplish the progression and review of
CSD07
MikeE:
OASIS Admin has ack'd
MartinC:
Robin is ctahcing up for Mary - Also some questions regarding ref's
Action: id=2011-01-18-2 status=done Johnson to propose more concretely what the different roles of global vs local channels might
be
Administrivia
EricW:
Volunteers to help out here - needs some guidance
LOA request from Bob Freund
Cannot grant from today - need 1 weeks notice
No objections - LOA approved from 2011-02-01 tru 2011-02-22
OASIS Admin working on this (see above)
AnishK describes work done - notes that 1.2 needs bringing in line with 1.1 (CSD07)
MartinC:
All issues/comments/notes resolved/removed?
AnishK:
One remains - related to text added at F2F - some questions regarding what should have been added
...Will raise new issue in JIRA
Open Issues 1.1
Open Issues 1.2
Assembly-250
E-mail from several TC members
EricJ:
Disconnect between different views of how channels used
<anish>
aren't we moving away from the main issue at hand, which is whether there is a need for auto-wire. I understand that there
are some related issues, but the current discussion is about getting rid (or problems wrt) global channels -- which is a very
different issue.
<MartinC>
what issue are we talking about, this isnt about autowire
<MartinC>
why are components at a domain level connected to a global channel different from coponents in a composite connected to a
local channel
<MartinC>
ihmo there is no difference
EricJ gives detailed argument about differences between global and local channel usage
PeterN:
Noted some minor issues (connection to non-existant channels, "/" in names. etc)
...agreed that some items not fully thought through
...most importantly notion of "topic"
...can(will) use global channels to connect to external JMS
...also for attachment of policy
PeterN:
Private channel (proper name no local) not intended to connect to external JMS
MikeE:
Not how things currently defined - can be used to external JMS
AnishK:
Never viewed private channels that way - always as local
...whether channel is bound to external JMS doesn't limit other eternal producer/consumers
AnishK:
Autowire can't be reliably determined
MartinC:
Channels all have same semantics - only about visibility
...no difference between global/local channels as far as capabilities - only visibility
...e.g. child can't access parent channels
...Don't see how the current discussion relates to autowire
<Peter Niblett>
Line 2815 says..
Channels within a composite used as an implementation are private to the components within that composite. These private
channels can only be the targets for producers existing within the same composite as the channel. Private channels can only
be sources for consumers existing withing the same composite as the channel. An SCA runtime MAY support the use of private
channels
MikeE:
Seems current proposal is heading in a different direction than currently defined
<Peter Niblett>
It seems very strange to have these sentences and yet also allow these channels to be bound to external JMS topics
<Peter Niblett>
The intent clearly is to keep the comms private to the composite
...that is separate debate - currently only about visibility of channels
<anish>
peter, i read that in the context of SCA -- it is not available to the components outside the composite -- in that sense it
is private to the composite. The fact that there are channel bindings imply that any channel can be bound to an existing pub-sub
system
<anish>
peter, if this causes confusion, i think we should change the wordings to replace private with local -- I take back what I
said on the call -- the spec, obviously, does use the word 'private'
DannyV:
Agreed this isn't autowire - but decided that these issues need addressing before others make sense
...seems that view of channel varies dependig on top-down vs bottom-up design
...this should not be the case - should look same no matter how desgin is done.
<MartinC>
sounds like a new issue that needs to be raised: change concept of global channel
EricJ:
Not really trying to go in a new direction - pointing out that lots of things are fully defined
<Peter Niblett>
anish, I'm arguing that we used the word "private" for a reason.. it is to allow the event flow to be encapsulated within
the composite. It's counterintuitive to have something that does that, but which also allows events to flow in and out in
a completely unmodelled fashion. Suppose I have two composites with two different private channels.. if I bind them to the
same JMS destination then events will flow between them. Even if they are bound to different JMS destinations events might
flow betweeh them, because who knows what kind of JMS hook up is going on behind the scenes. It seems to me that binding to
externally visible JMS destinations is an important concept, but needs to be kept separate from this private channel idea
AshokM:
Not making any progress on this - we need to move forward.
<Peter Niblett>
I am happy with binding global channels to JMS topics (argument is that these JMS things are outside the assembly and therefore
global to it). Are there some use cases that this fails to support?
...same points being made again and again
MartinC:
Agree need to restict to issues being discussed - if there are broader issues then address separately
AnishK:
Can see that autowire simplifies some things but fraught with problems
<MartinC>
peter, we (oracle) dont want events encapulated within a composite otherwise the sce runtime will have to police these private
channels and not allow messages to escape
<anish>
peter, i don't have a problem with the model you are proposing, but what we have now, we allow bindings on global as well
as local channels
<anish>
if we want to change that we should talk about it
<Peter Niblett>
that's why the spec says private channels are RFC 2119 OPTIONAL
<MartinC>
i think we are forgetting what the spec says
<Mike Edwards>
I think bindings on Global channels are fine and I don't see a problem with them
<anish>
mikeE, i believe peter does not like bindings on local channels
<Mike Edwards>
I would prefer local channels to use bindings (if any) which are non-specific - ie like <binding.jms/> which simply says "use
JMS for the protocol, but with "private" locally created resources like Queues or Topics that are left to the runtime to allocate
<Mike Edwards>
- we have that situation for use of jms in services / references
<anish>
i don't have a problem with that. the issue is once you use JMS, you cannot necessarily guarantee that noone else outside
of SCA is participating -- which I'm ok with, but peter seems to think that this is a bad idea
<Mike Edwards>
true, unless you secure the JMS resources in some way
<Mike Edwards>
same is true of almost any other protocol that you might use
<Mike Edwards>
it is up to the SCA runtime to determine the level of assurance that it will provide
<anish>
+1 to that. I'm of the opinion that we can only talk about what happens in the SCA domain/components/composites
<anish>
if the deployer/system does any bridging, all bets are off wrt what events are produced, by whom and who sees them
<Mike Edwards>
I agree with one exception - if there are Filters expressed then they should be honoured by however the Channel is implemented
by the SCA runtime
<Mike Edwards>
which ain't really an exception - its a demand on the SCA runtime implementation
<Mike Edwards>
I think that if the assembly says that only certain Event types pass, that should really be the case...
<anish>
i agree -- that would be part of the SCA contract
<anish>
wrt sca components
AOB
Martin - do you have the roll please?
Schreiber diagnostics output
[Delete this section before publishing the minutes]
final validation: Date not specified, the date '2011-01-25' was assumed
final validation: Title not specified, default title 'Oasis SCA-Assembly Teleconference...' was assumed
final validation: Chair not specified, default chair was assumed
statistics: Schreiber found 115 input lines
edits: Schreiber found the following text-edit commands:
edits: Line 3: s/1./agenda: 1.
edits: Line 31: s/bojections/objections/
edits: Line 92: s/work/word/
edit-substitute: command on line 3 succeeded, changed line 1 from '1.' to 'agenda: 1.'
command-scribe: Line 2: Scribe 'Eric Wells' is recognized by use of the nick 'EricW'
command-scribe: Line 2: EricW's nick 'EricW' has been selected
edit-delete: Line 3 was deleted
edit-substitute: command on line 31 succeeded, changed line 30 from 'bojections' to 'objections'
edit-delete: Line 31 was deleted
citation-detection-scribed: Line 34: Check for possible unrecognized nick '1.2 Assembly spec draft'
citation-detection-scribed: Line 44: Check for possible unrecognized nick 'ASSEMBLY-250'
citation-detection-scribed: Line 49: Check for possible unrecognized nick 'Latest discussion'
edit-substitute: command on line 92 succeeded, changed line 90 from 'work' to 'word'
edit-delete: Line 92 was deleted
citation-detection-scribed: Line 137: Check for possible unrecognized nick 'COB 9'
system: Transformer: SAXON 9.2.1.2
[End of Schreiber diagnostic output]